# 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, 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](#who-may-manage). See
[Users](users-local-users#the-primary-administrator) 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.

## 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), 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}

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: 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 ("{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."). |

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