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 lives in Settings → Permissions and requires Manage permissions to view or change.
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.