# 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.

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-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-signed-in). |
| 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](users-local-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](users-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 {#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 {#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](users-local-users#the-primary-administrator) 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.

## New… and the column footer {#new-and-the-column-footer}

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}

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 '{name}'? This cannot be undone." and "Delete the role '{name}'? 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 ("{Name} 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 {#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](users-permissions#the-reach-strip) page.

## What the page does not do {#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](account-subscription#free-mode-and-the-runtime-countdown)) this page is not
  drawn at all: every screen except [Account](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](account) page, not here. Whether the station is reachable from the network at all
  is the [Remote access](settings-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 {#in-this-section}

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