Roles

The Roles root of the Users page, the role list with its reach strips, and the role panel where a role's name, description and permission switches are set, including the two fixed roles.

The Roles root holds one node per role. A role is a named set of permission switches; users bind to it, and editing it changes every user who holds it at once. The station ships six roles. Two are fixed: Not signed in (the role in force before anyone signs in) and Admin (full access). Four are ordinary editable, deletable suggestions: Viewer, Operator, Maintainer and Developer.

Like the Users root, this root and its children belong to an administrator on this circuit (Manage local users). Anyone else sees the root without children and, behind it, the notice that says to sign in as an administrator. On a station with no users yet the notice reads instead: "Roles are already seeded, but changing one takes an administrator, and this station has none yet. Set up local users first: the primary administrator is the first one."

The role list

Opening the root shows the card ROLES, with the line "Each role reaches these areas, at the depth its strip shows. Editing a role changes every user who holds it, and editing the first one changes what any screen may do before someone signs in." and one row per role, in a fixed order:

Every row trails its compact reach strip, six pips in the same order everywhere, so the roles read as a ladder rather than a list of names. With no editable roles left, the card says "Not signed in and Admin are the only roles on this station. New role builds one for the work the bench actually does."

Clicking a row opens that role's node. In the column, each role node trails the same compact strip; the Not signed in node wears the walking-person glyph among the keys.

The factory roles

The ladder is a suggestion, not a contract: Viewer, Operator, Maintainer and Developer can be renamed, edited and deleted. The seed runs once, on a station whose roles table is empty; a deleted seed does not come back. Not signed in is permissive by design, so a fresh station works fully with nobody signed in and tightening it is a deliberate act.

The role panel

A role's panel saves as you work: the name and the description when the field is left, a switch the moment it is flipped. While the runtime is stopped the panel is inert under a "Runtime stopped" note. While a role another screen has just deleted is selected, the panel says "That role is no longer on this station. Pick another in the column."

Head, name and description

The head names the role and, for the fixed pair, what it is. Admin carries the chip Full access · locked. Not signed in carries a chip that reads how open the station stands to anyone who has not signed in, followed by one sentence:

Under the name field the fixed roles carry a note: "The Admin role is fixed. It always has full access and can manage local users." and "Not signed in is the role in effect when nobody is signed in. Its permissions are editable; the role itself cannot be renamed, deleted or assigned to a user." The description's hint reads "Shown under the role's name. Update it when you change what the role can do."

Below the fields the card reads the role's reach live: the summary, the words follows the switches below, and the labeled strip. It re-forms on every flip, before the write comes back. It never edits: the System area mixes independent switches, so a pip cannot map back to one of them.

Permissions

The PERMISSIONS card opens with one of three leads:

• Admin: "The Admin role always has full access, so its switches are fixed. It is the role that can manage users, and the station keeps one."
• Not signed in: "Each switch applies as soon as you change it, to every screen where nobody has signed in."
• Every other role: "Each switch applies as soon as you change it, to this role and to every user holding it."

Then one group per area, headed by the area's glyph, its name and a counter, " of ": Dashboard (3), Connector (3), Process (4), Histories (3), Logic (3), Validation (1) and System (5). Each row is a label, a description and a switch. The full catalog, with every label and description exactly as it reads, is on the Permissions page.

A switch is locked, and cannot be flipped, in four cases:

Flipping a switch on also turns on what it requires (Operate dashboards turns on View dashboards; Manage process turns on Edit recipes & evaluations, Run procedures and Look at models). Flipping a switch off also turns off everything that required it (View connector off takes Calibrate tags and Configure connector with it). The rules are listed on the Permissions page. Every flip writes the whole role at once and the feed reports ": on for ''." or ": off for ''."; a write the station refuses puts the switches back to what it actually holds and reports "Could not save the role: ".

The station also normalizes what it stores: a non-Admin role never keeps Manage local users, and every stored mask carries its prerequisites, so a role is always self-consistent.

In force for, or Held by

The last card differs between the walk-up role and every other:

• On Not signed in, IN FORCE FOR reads "Every screen where nobody has signed in, this station's own and any device viewing it. Nobody is given this role; it is what applies until someone signs in, and signing in swaps it for that user's own role." and "Because the station depends on it being here, this role stays: its permissions are yours to set, its name and its existence are not."
• On every other role, HELD BY lists the display names of the users holding it, with "Every switch you change here changes what all of them may do." With nobody on it, it reads "No user holds this role yet. Assign it on a user's own page, under Users."

Creating and deleting a role

New role in the column footer creates a role that starts at the floor: View dashboards on, everything else off, empty description. Add reach deliberately; note that a blank role does not hold View events, which every factory role has. Delete role on the detail bar asks "Delete the role ''? This cannot be undone." and is refused, greyed with the reason, while the runtime is stopped, on either fixed role (" is a fixed role: the station depends on it being here."), and while any user still holds it ("This role is held by users. Move them to another role first.").

How a change reaches everyone

The roles live in one service the whole station reads. A flipped switch reaches every user holding the role on every connection at once: the station window, every browser, every signed-in operator. A screen re-checks the role at every press, so an operator whose role just lost a permission has the command refused on the next press even if the screen was already drawn. A user whose role is deleted from under them falls to the floor. A dashboard whose Visible to checklist named the deleted role treats that entry as inert, so the dashboard never becomes unreachable.

What the panel does not do

• It does not assign users. That is the Role picker on each user's page under Users.
• It does not change Admin: not its switches, not its name, not its existence.
• It does not rename or delete Not signed in, and it does not offer it in any user's Role picker.
• It refuses every write while the runtime is stopped: name, description, switches, creation and deletion all answer "Runtime stopped".
• It cannot grant Manage local users to any role but Admin, and it cannot revoke View dashboards from any role.