Users & Roles

Platform users are the people who build and administer the system: engineers, integrators, administrators. They are distinct from runtime users, who operate LiveView screens.

→ LiveView authentication for runtime identity.

The four roles

Role	Intended for
superadmin	Full control, including permission and audit configuration
admin	Day-to-day administration, without the security-control permissions
editor	Engineers who build pipelines, connections, namespace and projects
viewer	Read-only access, plus alarm acknowledgement

A role is a default set of permissions, not a hard-coded capability. The mapping is editable — see Permissions.

Default permissions by role

superadmin

Everything. This is the only role that holds, by default:

Permission	Why it is reserved
Manage Permissions	Changes who can call what — the meta-control
Manage Audit	Audit-storage configuration is itself a security control
Manage Auth Settings	Authentication policy
Manage AI Settings	Exposes billable API keys and the assistant kill switch
Manage Backup & Restore	A backup can move the whole configuration off the machine
Manage LiveView Auth	Binds projects to runtime identity sources
Manage System Services	Start and stop services
Manage Script Sandbox	Installs Python packages that run with worker authority
Manage Designer, Manage File Library	Authoring surfaces
Manage Symbol Library 1.0.8	Imports, edits and deletes the global SVG symbols every project draws from
Access Settings, Change User Role	Administration
Clear Execution Logs, Clear System Logs, View All Executions, Delete All Executions	Log destruction
Progressive Loading	Global runtime tuning

admin

Everything except the list above. Note the deliberate asymmetry: admins can read the audit journal (needs View Audit Log) but cannot configure it (needs Manage Audit).

editor

Build permissions, no administration:

Area	Permissions
Pipelines	View Pipelines, Create Pipeline, Edit Pipeline, Delete Pipeline, Execute Pipeline, Start/Stop Pipeline, Export Pipeline, Import Pipeline, Configure Shared Variables
Connections	View Connections, Create Connection, Edit Connection, Delete Connection
Namespace	View Namespace, Create Namespace Node, Edit Namespace Node, Delete Namespace Node, Manage Namespace, Bind Protocol, Import Namespace, Export Namespace, Refresh Namespace
Projects	View Projects, Create Project, Edit Project, Delete Project
Alarms	View Alarms, Acknowledge Alarms, Manage Alarms
Diagnostics	View Execution Logs, Clear Execution Logs, View System Logs, Clear System Logs, View Status Panel
AI	Use AI Assistant

viewer

Read-only, plus acknowledgement:

View Pipelines · View Connections · View Execution Logs · View System Logs · View Status Panel · View Namespace · Refresh Namespace · View Projects · View Alarms · Acknowledge Alarms

Why a viewer can acknowledge

Acknowledging an alarm is an operator's core duty and changes no configuration. A role that can see alarms but not acknowledge them produces a permanently red banner nobody can clear.

Managing users

Users are managed in the User Management card under Settings → Security Policy.

Action	Permission
List users	Manage Users
Create	Create User
Activate / deactivate	Edit User
Change role	Change User Role
Delete	Delete User
Upload / delete avatar	authenticated

Note that Create User, Edit User, Delete User and Change User Role are separate. A helpdesk role that can deactivate a leaver but cannot grant anyone a role is expressible.

Your own account

Your profile and password are under the user menu — any authenticated user can update their own display name, email, avatar and password.

Passwords

A password change ends every other session New in 1.0.4

Changing a password revokes every token issued before the change, on every device. This is a property of the account, not of the browser that made the change: it applies to a self-service change, an administrative one, and a console reset alike.

Existing sessions survive the upgrade — an account that has never changed its password since revokes nothing.

A lost administrator password

There is no vendor master password and no unlock code. An administrator password is recovered at the server console: New in 1.0.4

qubiq admin reset-password --user jhalloran

It prints a temporary password once, and the account must replace it before it can do anything else. Only admin and superadmin accounts can be reset this way — letting a console foothold reset a named engineer's or operator's account would be a different and less defensible power.

That reset cannot be prevented (whoever ran it already holds the data directory, and therefore every credential in the system), so it is made visible instead: a warn system-log row, an entry in the audit journal, and a security notice at GET /api/security/notices — View Audit Log — that stays for seven days and cannot be dismissed by anybody, including whoever performed the reset.

→ Console recovery

A password that must be changed

An account handed a password by somebody else owes a change before it can use the system. The rule is enforced by the server, not asked of the browser — the temporary password is read off a console and typed in, and anything that can sign in can call the API directly.

While a change is owed, exactly three endpoints stay reachable: change password, sign out, and read your own profile. Everything else answers 403 with the code PASSWORD_CHANGE_REQUIRED, which is distinct from a 401 on purpose: the account is signed in, and sending it back to the login screen it just came from would be a loop.

Sessions Changed in 1.0.8

Sessions are cookie-backed and renew themselves in the background while you work. How long they last is set in the Authentication Settings card under Settings → Security Policy, which needs Manage Auth Settings:

Field	Default	Meaning
Access Token TTL (hours)	1	Lifetime of the short credential sent with every request. Renewed automatically before it expires.
Refresh Token TTL (hours)	168 (7 days)	Signed out after this long with no activity.
Maximum Session Length (hours)	0 (no limit)	Sign in again after this long, however active the session. Must be 0 or at least the access-token TTL.

The access-token default dropped from 24 hours to 1 in 1.0.8

An installation that never saved this field moves to the new default on upgrade; one that saved a value keeps it. Nothing changes for the person at the screen — the browser now renews the access token shortly before it expires, which it did not do before. A tab that only received live data over its WebSocket used to go dark when the 24-hour cookie lapsed.

A session is a server-side record

Every sign-in now creates a session on the server, and the refresh token belongs to it:

• Rotation is real. Each renewal issues a new refresh token and retires the old one.
• A replayed token ends the session. If a refresh token that has already been rotated away is presented again — the signature of a stolen copy — the whole session is revoked. A 60-second grace absorbs two tabs renewing at the same moment.
• Sign out ends the session on the server, not just in the browser.
• A password change ends it — the refresh token no longer outlives one.

Restarts and signing everyone out

Below the token fields, the same card carries two controls:

Control	Default	What it does
Keep sessions across restarts	Off	Off: every full platform restart signs everyone out, Studio and LiveView. On: sign-ins survive restarts until they expire — what an unattended control-room display needs after an update or a power cut. Takes effect at the next restart. Also settable with QUBIQ_KEEP_SESSIONS, which locks the switch.
Sign out all	—	Ends every Studio and LiveView session now, including yours. Unattended screens return to their sign-in page, and API scripts using a bearer token must sign in again. Data collection is not affected.

Sign out all is the explicit way to end the sessions that Keep sessions across restarts otherwise lets survive — after a suspected credential leak, or when a contractor's shared panel account was used on a machine you no longer control.

Login protection

Login protection is set in the Security Hardening card under Settings → Security Policy, or with the matching environment variable — which then locks the field:

Field	Variable	Default	Meaning
Max attempts	LOGIN_MAX_ATTEMPTS	10	Failures before lockout
Window	LOGIN_WINDOW	15 minutes	Window in which failures are counted
Lockout	LOGIN_LOCKOUT	15 minutes	How long a locked account stays locked

Login attempts — successful and failed — are recorded in the audit journal with the client IP, which is why TRUSTED_PROXIES matters behind a reverse proxy.

Deactivating versus deleting

	Deactivate	Delete
Access	Revoked immediately	Revoked
Audit history	Attribution preserved	Historical records remain, referencing an absent user
Reversible	Yes	No

Deactivate leavers. Deletion is for accounts created in error. Audit records outlive the account, and an attributable name is worth more than a tidy user list.

Practical guidance

• Create the super admin at first-run setup, then work as an admin or editor day to day.
• Never share accounts. Attribution is the entire value of the audit journal.
• Give integrators editor, not admin — building does not require administering.
• Review the user list at every commissioning milestone and after every contractor leaves.
• Where the built-in roles do not fit, edit the permission matrix rather than over-granting a role.

Next

→ Permissions