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 Connection |
| Acknowledge an alarm | Acknowledge Alarms |
| Run a pipeline once | Execute Pipeline |
| 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
The API Permission Management card groups the permissions under these headings:
| Group | Covers |
|---|---|
| Pipeline Operations | View, create, edit, delete, execute, start/stop, export, import; shared-variable storage |
| Connection Operations | View, create, edit, delete |
| Monitoring & Logs | Execution and system logs (read, clear), every project's executions, the status panel |
| User Management | Manage, create, edit, delete, change role |
| System Settings | Settings access, permissions, log configuration, auth settings |
| Services | Start, stop and restart services |
| Scripting | The script sandbox |
| Namespace | View, node CRUD, tag management, protocol binding, import, export, refresh, progressive loading |
| Project | View, create, edit, delete, manage lifecycle |
| Designer | Designer authoring, file library, symbol library 1.0.8 |
| Alarms | View, acknowledge, manage definitions |
| Audit | View, manage |
| Backup | Backup and restore |
| Identity & Access | LiveView identity sources |
| AI | Use the assistant, manage its settings, author specialists |
The design principle: view ≠ change ≠ administer
The permission set is deliberately granular in specific places:
| Read | Change | Administer |
|---|---|---|
| View Namespace | Edit Namespace Node | Bind Protocol |
| View Connections | Edit Connection | Create Connection / Delete Connection |
| View Alarms | Acknowledge Alarms | Manage Alarms |
| View Audit Log | — | Manage Audit |
| View System Logs | — | Clear System Logs |
| View Execution Logs | — | Clear Execution Logs |
Two of these are worth calling out:
- Bind 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 Status Panel
Leave off: Manage Users · Manage Permissions · Manage Backup & Restore · Manage Audit
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 Project is destructive but bounded to something the editor created. Manage Project covers disable/enable/trash/restore/purge, which affects a running system and belongs with administration.