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, and reports "Primary administrator created." in the action feed. Creating the user signs nobody in: the Signed in now root still trails Nobody, the Users branch lists no one, and the panel shows the notice quoted under Who may manage. See Users for what makes this user special.

The next step is signing in as Administrator, on the user chip in the title bar or under Signed in now. It has no PIN, so one tap on its name in the sign-in dialog signs in. From the chip, the page stays on the Users root, which now lists Administrator marked and scrolled into view; pressing its row opens that user's panel, where you name it and give it a PIN. From Signed in now, the page stays on that root, and Administrator is opened from the Users branch.

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), and lands on the Users root: the Users branch opens in the tree, and the list on the page marks the new row and scrolls it into view. The user is not opened; its row opens its panel. 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 the floor permission, View dashboards, and Send reports to Ganter, and an empty description, and lands on the Roles root: the Roles branch opens in the tree, and the list on the page marks the new row and scrolls it into view. The role is not opened; its row opens its panel. 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.	While neither branch has a row under it; the tooltip then gives the reason ("Expand all: no row in this column has anything under it yet."). With the footer drawn that does not happen here, because the fixed roles Not signed in and Admin always stand under Roles.	Same footer rule.

Creating never opens what it made. A created row is marked on the page that lists it, the Users root or the Roles root, and stays marked until you pick something else in the column; pressing the row opens its panel. 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: its recovery key is what resets a forgotten admin PIN, from the sign-in screen, without anyone signed in.").
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.").

Right-clicking a row of the tree selects it and opens its verbs at the cursor, the same ones the footer and the bar carry: the Users root offers New user, the Roles root New role, a user row Remove user and a role row Delete role. The last two ask for the same confirmation as on the bar, and are greyed with the same reasons as in the table above whenever the bar would refuse them. Signed in now opens no menu, and an identity without Manage local users gets none on any row.

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, in the station's window or in any browser: 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 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.