Users

The Users page, where the station decides who is signed in on each screen, which local users exist, and which role decides what each of them may do.

View as Markdown

The Users page is the station's local access control. It is the last entry of the rail's work group (View, Process, Logic, Connector, Users) and it answers three questions in one column: who is signed in on this screen, which local users the station has, and which roles stand behind them. Roles are always in force: not being signed in is itself an identity, the Not signed in role, so there is no lock screen and no enforcement switch to turn on. A fresh station opens fully usable with nobody signed in; governance is the deliberate act of taking permissions away from that role and signing in to get them back.

The page opens for every identity. What it lets you change depends on one permission, Manage local users, which only the Admin role holds. Without it the page still shows who is signed in and offers the way in and out; the users and the roles themselves stay behind a notice.

The column: Station access

The column is titled Station access and carries three roots. Both branches arrive closed; open the one you came for, or use the footer's expand and collapse commands.

Root	What trails it	What it opens
Signed in now	The name signed in on this screen, or Nobody.	The identity panel: who is signed in here, what this screen can do now, and the Sign in, Switch user and Sign out verbs. See Signed in now.
Users	The user count (only for an administrator).	The roster, one child node per local user; each child trails the role it holds. See Users.
Roles	The role count (only for an administrator).	The roles, one child node per role, in the panel's order: Not signed in, Admin, then the editable roles; each child trails its compact reach strip. See Roles.

The children of Users and Roles exist only for a circuit whose identity holds Manage local users. For anyone else the two roots stay in the column, without a count and without children, and the panel behind each says why it is empty. That keeps the page reading the same before and after an administrator signs in.

The page opens on Signed in now. On a station that has no local users yet it opens on the Users root instead, because the only thing to do there is the first-use setup.

Who may manage

Managing users and roles takes an administrator signed in on this circuit: the station's own window checks the station session, and a browser checks the user signed in on that connection. A remote viewer never inherits the administrator sitting at the bench. Without the permission, opening the Users root, the Roles root or a leaf behind them shows the same notice:

Sign in as an administrator (under Signed in now, or on the user chip in the title bar) to manage the users and roles on this station, including what the Not signed in role may do.

The notice lists nothing: no user and no role is visible behind it. The permission is re-read on every render, so an administrator signing out on this screen takes the roster off the column at once, and a leaf still selected behind it stops answering.

First use

A station with no local users has no administrator to sign in as, so creating the first one is open to whoever is at the bench. The Users root shows a single card, USERS, with the explanation and one accent button, Set up local users. Pressing it creates the primary administrator, named Administrator, on the Admin role, with no PIN, reports "Primary administrator created." in the action feed and opens that user's page, where you name it and give it a PIN. See Users for what makes this user special.

While the roster is empty, the Roles root says the same thing from its side: the roles are already seeded, but changing one takes an administrator, and the way to get one is the primary administrator under Users.

The column footer holds the page's commands in the corner every column keeps them in. It is drawn only for an administrator; anyone else sees no footer at all.

Command	What it does	Greyed when (situation)	Not drawn when (role)
New…	Opens a menu with New user and New role.	Never while this page is drawn (see below).	The identity lacks Manage local users.
New user (menu item)	Creates a user named New user on the Operator role (if that seed still exists; otherwise the first role that is neither Not signed in nor Admin; Admin only when nothing else is left), opens the Users branch and selects it. The feed names the role the user landed on: "Added user 'New user' in the Operator role." On a station where Admin is the only role left to hand out, it says so instead: "Added user 'New user' in the Admin role, the only role left on this station. That is full access, managing users included."	Never while this page is drawn.	Same.
New role (menu item)	Creates a role named New role with only the floor permission, View dashboards, and an empty description, opens the Roles branch and selects it. The feed says "Added role 'New role'."	Never while this page is drawn.	Same.
Expand all / Collapse all	Opens or closes both branches. Collapsing leaves the three roots.	Never.	Same footer rule.

A created row lands on its own page in the column. There is no window to fill in first: the station holds the row from the moment it exists, and everything else about it is set in the panel, which saves as you work.

The detail bar

The detail bar carries one verb, in the danger cluster on the right, and only when a user or a role is selected by an administrator: Remove user or Delete role. Both ask for confirmation ("Remove ''? This cannot be undone." and "Delete the role ''? This cannot be undone."), report the result in the action feed, and return the selection to the branch root. When the verb is refused it stays on the bar, greyed, with the reason as its tooltip:

Verb	Greyed when
Remove user	The user is no longer on the station; the user is the primary administrator ("The primary administrator stays: it holds the offline recovery key that resets a forgotten admin PIN.").
Delete role	The role is no longer on the station; the role is fixed (" is a fixed role: the station depends on it being here."); users still hold it ("This role is held by users. Move them to another role first.").

Nothing on this page changes in silence. Every write, and every refusal, is reported in the action feed, because who may operate the station is not a thing to change quietly.

The reach ruler

Every role on this page is drawn as a strip of six pips, one per station area, in the same order wherever the strip appears: Dashboard, Connector, Process, Histories, Logic, System. The legend that reads the strip sits once at the foot of the detail column, whichever node is open: THE REACH RULER, with four rungs, No access, View, Operate and Manage. How far a pip fills is how deep the role reaches into that area. The exact rule behind each pip is on the Permissions page.

What the page does not do

It never stops the runtime. Access control gates the screens only; acquisition, recording, the logic sweep, alarms and the embedded server run whether or not anyone is signed in.
While the runtime is stopped (the free-mode limit, see Subscription) this page is not drawn at all: every screen except Account is replaced by the paused notice. Signing in and out stays available, because the user chip belongs to the title bar rather than to this page, and everything here comes back exactly as it was once the runtime is restarted.
It is local machine control, not security. PINs are 4 to 6 digits, and the configuration database can be read out of band by anyone with the files.
It does not offer per-user permissions: a user holds exactly one role, and a one-off set of permissions means a new role.
The tree has no right-click menu; the verbs live in the footer and on the detail bar.
The station's online Ganter account, its subscription and its license seat live on the Account page, not here. Whether the station is reachable from the network at all is the Remote access setting; who may use it from there is the Remote access (LAN) permission on this page.
The published demonstration keeps this page off its rail: its roster holds one sealed administrator nobody can sign in as.

In this section

Page	What it covers
Signed in now	The identity in force on this screen, its reach, and the way in and out.
Users	The roster, the user panel (name, role, PIN), the primary administrator and the admin PIN recovery.
Roles	The role list, the role panel with its permission switches, and the two fixed roles.
Permissions	The complete switch catalog, the implication rules, and what each permission gates across the app.
Signing in	The user chip, the sign-in dialog and PIN pad, browsers and remote access, and what a sign-in changes.