Roles, categories and the grid between them

Access control in a Niagara station is a chain, and you cannot reason about any one link without the others.

• Every component belongs to at least one category.
• Every slot has a permission level — operator or admin.
• A role holds a permissions map: for each category, what rights it grants at each level.
• A user is assigned one or more roles, and their permissions are the union of them.

Rights themselves are three: read, write, and invoke an action. They apply to component slots, folders, files and histories alike.

A new station arrives with two basic categories: User (category 1) and Admin (category 2). Everything lands in User except three services — the user service, the category service and the program service — and the entire file space, which go to Admin.

Categories can also be inherited from a parent rather than explicitly assigned, and the two mechanisms can be mixed. What cannot happen is a component in no category at all.

Beyond that, how you group is a modelling decision: by equipment type — lighting, door access, HVAC — or by geography, floor by floor. Which one is right depends entirely on how the roles will be drawn, so decide the roles first.

This is the part that is genuinely unintuitive. The operator/admin distinction is not a property of the user or the role — it is a config flag on the slot. If a slot's Operator flag is set, the slot is at operator level. If it is cleared, the slot is at admin level.

Most slots default to admin level. The notable exception is the out slot, which is normally operator level — which is exactly why an operator can watch a value without being able to touch the logic that produces it.

Admin level carries more than write access to values: it lets a user see and change the slot flags themselves on the slot sheet. Granting admin rights broadly hands out the ability to reconfigure the permission model.

Editing a role opens a grid with one row per category and columns for the operator and admin levels. Rights are written in a shorthand worth reading fluently: lower case for operator level, upper case for admin. r is operator read, rw operator read and write, rR adds admin read, and rwRW is full rights at both levels.

A super user sidesteps all of it — every permission, every category, every object — and can create further super users. Ordinary users cannot grant what they do not hold, so a non-super user cannot promote anybody to super user.

The second is users who cannot change their own password, and the fix is specific. The user service has its own permission scheme, unlike every other component:

So: leave the Authenticator slot at operator level, which is its default, and give every non-super-user role operator-level write on the category holding the user service. By default the new station wizard puts that service in the Admin category, which is why the permission people want is in a place they do not think to look.

Giving somebody access to a point buried six levels deep would be useless if they could not see the folders above it. The station handles this: it automatically grants operator-level read on every ancestor of a component a user can reach, so the nav tree is navigable.

It does so periodically rather than instantly, which is why a freshly granted permission sometimes appears not to work. The category service has an Update action that forces it.

The whole file space defaults to the Admin category, and file permissions behave mostly at operator level.

• Operator read to view a file; operator write to edit one.
• Operator read on a folder to list it and copy children out; operator write to create or delete children.
• A few views want admin-level write — the nav file editor among them.
• Operators typically need operator-level read on the standard folders: nav, px, images, html.

Some rules are not yours to set. System module files are automatically restricted to operator-level read. Non-super users are denied everything outside the station home directory. A Supervisor's provisioning folder needs admin-level read to be visible at all. And the station's own config.bog and its backup are not accessible in the file space to anybody, super user included.