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 the audit journal	Audit-storage configuration is itself a security control
Manage sign-in settings	Authentication policy
Manage AI settings	Exposes billable API keys and the assistant kill switch
Manage backups	A backup can move the whole configuration off the machine
Manage LiveView sign-in	Binds projects to runtime identity sources
Manage services	Start and stop services
Manage the script sandbox	Installs Python packages that run with worker authority
Manage the Designer, Manage the library	Authoring surfaces
Access settings, Change a user's role	Administration
Clear execution logs, Clear system logs, View all users' executions, Delete all users' executions	Log destruction
Configure namespace optimisation	Global runtime tuning

admin

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

editor

Build permissions, no administration:

Area	Permissions
Pipelines	View pipelines, Create pipelines, Edit pipelines, Delete pipelines, Run pipelines, Start and stop pipelines, Export pipelines, Import pipelines, Configure variable storage
Connections	View connections, Create connections, Edit connections, Delete connections
Namespace	View the namespace, Create tags and folders, Edit tags and folders, Delete tags and folders, Manage tags, Bind a tag to a protocol, Bulk import tags, Export the namespace, Refresh the namespace
Projects	View projects, Create projects, Edit projects, Delete projects
Alarms	View alarms, Acknowledge alarms, Manage alarms
Diagnostics	View execution logs, Clear execution logs, View system logs, Clear system logs, View the status panel
AI	Use the AI assistant

viewer

Read-only, plus acknowledgement:

View pipelines · View connections · View execution logs · View system logs · View the status panel · View the namespace · Refresh the 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 Settings → Users.

Action	Permission
List users	Manage users
Create	Create users
Activate / deactivate	Edit users
Change role	Change a user's role
Delete	Delete users
Upload / delete avatar	authenticated

Note that Create users, Edit users, Delete users and Change a user's 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 the audit journal — 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

Sessions are cookie-backed and refresh silently while you work. Login protection is configurable:

Variable	Meaning
LOGIN_MAX_ATTEMPTS	Failures before lockout
LOGIN_WINDOW	Window in which failures are counted
LOGIN_LOCKOUT	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