Item permissions
Decide who can see a page or document, change a tag's value, and act on a category's alarms.
A project role says what someone can do across a whole project. Some things also carry permissions of their own, so access can be decided for one item at a time — this page, that tag, those alarms.
| Item | What its own permissions decide |
|---|---|
| Pages | Who can see and open them |
| Documents | Who can see and open them |
| Tags | Who can change the value |
| Alarm categories | Who can see and act on the alarms in it |
Everything else in a project is governed by the project role alone.
Setting them
Open the item’s list — Pages, Documents, Tags or Alarm categories — and choose Permissions from the row’s menu.
The dialog lists everyone the project is shared with: individual users () and user groups (), with one control per row and a search box for long lists. Giving a group access gives it to everyone in that group. Nothing is written until you press Save.
Setting them is an Admin action, and the same for every item type: a project’s Admins decide who gets access. A Manager can create and edit the items themselves, but not hand out access to them, so the option doesn’t appear.
Pages and documents
Each page, document and folder has a Can view switch per user and group. Turning it on lets that person open the item; leaving it off means they never see it in the first place — it isn’t listed, and a link to it won’t open.
Two rules make this practical in a real project:
- Anyone who can edit pages and documents sees all of them. Managers and Admins are not restricted by these switches; the switches decide what everyone else sees.
- A grant on a folder covers everything inside it, however deeply nested. Grant someone the “Plant room” folder and they get every page in it, including ones added later.
Where a person or group already has access from a folder above, their row shows the switch on and locked, marked Granted by a parent folder. That grant belongs to the folder, so it can only be changed there — open the folder’s own permissions and turn it off, and the rows below become editable again.
Granting a single page deep inside a structure also reveals the folders leading to it, so the person can navigate there. Those folders show only the path to what they’ve been granted, not their other contents.
Tags
A tag’s permissions decide who may change its value. Each user and group is set to one of three choices:
- Inherit — the default. Nothing is said about this person here, so their project role decides.
- Allow — this person may change the value.
- Forbid — this person may not change the value, whatever their role.
Forbid is the one that carries weight. It’s how you protect a handful of sensitive setpoints without rearranging anyone’s role: leave the project as it is, and forbid the people who shouldn’t touch that particular tag.
Changing a live value still depends on the project role as well — a tag permission narrows what the role allows, it doesn’t replace it.
Alarm categories
Every alarm belongs to an alarm category, and the category is where alarm access is decided. An individual alarm has no permissions of its own, so set them on the category it belongs to.
Each user and group gets one level per category:
| Level | Can do |
|---|---|
| None | Cannot see these alarms at all |
| Viewer | See the alarms |
| Operator | See, acknowledge and snooze; a comment is required when acknowledging |
| Operator+ | The same, without the comment requirement |
Alarm categories start closed: a category nobody has been given a level on shows its alarms to nobody, whatever their project role. So a new category needs levels set on it before its alarms appear in the Alarm Manager, in events, or in notifications.
This is what makes categories worth organizing around: a wide audience can be Viewer on everything while only the team responsible for a system is Operator on its category.