Permissions
Every action in QUBIQ declares the permission it requires, and the check runs server-side before any work happens. There is no path where authentication alone is sufficient.
| Action | Permission it needs |
|---|---|
| Create a connection | Create connections |
| Acknowledge an alarm | Acknowledge alarms |
| Run a pipeline once | Run pipelines |
| Clear the system log | Clear system logs |
| Change who can do what | Manage permissions |
The complete list of permissions and what each one gates is in the permissions reference.
Permission categories
| Category | Covers |
|---|---|
| Pipelines | View, create, edit, delete, execute, start/stop, export, import |
| Connections | View, create, edit, delete |
| Namespace | View, node CRUD, tag management, protocol binding, bulk import, export, refresh, optimization |
| Projects | View, create, edit, delete, manage lifecycle |
| Alarms | View, acknowledge, manage definitions |
| Users | Manage, create, edit, delete, change role |
| System | Settings, services, logs, sandbox, backup, auth settings |
| Audit | View, manage |
| Designer & library | Designer authoring, file library |
| AI | Use the assistant, manage its settings |
| Runtime auth | Manage LiveView identity sources |
The design principle: view ≠ change ≠ administer
The permission set is deliberately granular in specific places:
| Read | Change | Administer |
|---|---|---|
| View the namespace | Edit tags and folders | Bind a tag to a protocol |
| View connections | Edit connections | Create connections / Delete connections |
| View alarms | Acknowledge alarms | Manage alarms |
| View the audit journal | — | Manage the audit journal |
| View system logs | — | Clear system logs |
| View execution logs | — | Clear execution logs |
Two of these are worth calling out:
- Bind a tag to a protocol is separate from editing tags. Reading and shaping the model is a different level of trust from pointing it at live equipment.
- Clearing logs is separate from reading them. Log destruction is a security-relevant act.
Customising the matrix
The matrix is the API Permission Management card at the bottom of
Settings → Security Policy. The server requires Manage permissions to read or change it, and
the interface shows the card to the super admin only.
Every permission can be granted to or revoked from any role. The four roles are labels; what they mean is data.
Anyone holding it can grant themselves anything. Keep it on the super admin only, and treat changes to it as security events — they appear in the audit journal.
Designing least-privilege roles
Start from the narrowest role that could work and add only what is blocked.
Contract integrator, commissioning phase
Start from: editor
Add: View the status panel
Leave off: Manage users · Manage permissions · Manage backups · Manage the audit journal
Maintenance technician
Start from: viewer
Add: Acknowledge alarms (already on by default)
Add: View execution logs
Production supervisor
Start from: viewer
Add: Manage alarms (so they can tune limits for their line)
Integration service account
Do not use a platform account. Use an API key with the narrowest scopes.
Checking permissions in the interface
The interface hides actions a user cannot perform, which is good usability. It is not the control — the server rejects the call regardless.
Never build a workflow whose safety depends on a button being hidden.
Auditing permission changes
Permission and role changes are recorded in the audit journal with actor, timestamp and before/after state. Review them at:
- Every access review
- After any contractor leaves
- Any time someone reports being able to do something they should not
Common questions
Can I create a fifth role? The four role labels are fixed; their permission sets are fully editable. In practice, editing the matrix covers what a custom role would.
Can permissions be scoped per project? Platform permissions are gateway-wide. Runtime access is per project, through the project's access policy and runtime roles — that is where per-project scoping belongs. → LiveView authentication
Why can an editor delete a project but not manage its lifecycle? Delete projects is destructive but bounded to something the editor created. Manage projects covers disable/enable/trash/restore/purge, which affects a running system and belongs with administration.