Roles and permissions

AiQu has three access levels. This page is the authoritative list of what each one can reach.

These docs are not gated

Every page here is readable by anyone, whatever their account. The badges at the top of a page say who it is written for, not who is allowed to read it

• knowing what the level above you can do is half of knowing what to ask for.

The three levels

Level	Scope	Typically
User	Their own jobs and files inside one tenant	Everyone
Tenant admin	Everything inside one tenant	One or two per tenant
Superadmin	Every tenant, and the installation itself	The platform operator

A tenant admin is an ordinary user with the tenant-admin flag, so they keep their own jobs, tokens and files. A superadmin is not a member of any tenant and has to enter one to act inside it.

Navigation by level

Section	User	Tenant admin	Superadmin
Overview, Jobs, Files, Tokens, System, Documentation	✓	✓	in-tenant only
Nodes, Queues, Storage, Projects, Users, Settings, Tenant Tokens		✓	in-tenant only
Tenants, global Nodes, global Queues, System Settings			✓

A superadmin who is not inside a tenant sees only the four superadmin entries. The ordinary pages come back once they enter a tenant.

Where a user’s permissions come from

This is the part that causes the most confusion, so it is worth being blunt: almost nothing is granted to a user directly.

Capability	Granted by
Submitting jobs at all	User group - add jobs
Which queues are visible	User group
Which storage buckets are visible	User group, or a project
Max GPUs per job, max total GPUs	User group
Opening public ports	User group
Opening private ports	User group, and the relay not being in no-DNS mode
Adding Docker registries	User group
Having to name a project on every job	User group - require project
CPU and RAM selectors in the job form	Tenant feature flag - job advanced view
Buying tokens	Tenant feature flag - user token purchase
Token balance	Tenant admin, a project, or a recurring task

So “this user cannot do X” is nearly always a group question, and the answer lives on Users and groups.

The two-sided rules

Two capabilities need agreement from two places, and satisfying only one looks exactly like a bug:

Mounting a bucket needs the user’s group to grant the bucket and the selected queue to be linked to its storage. See Storage.

Opening a private port needs the group’s private-port permission and the job’s relay not to be in no-DNS mode. See System settings.

What nobody can do

• See another tenant’s jobs, users, storage or nodes - except a superadmin, by entering that tenant
• Recover a container’s filesystem after the job ended
• Add ports to a job after it was created
• Extend a job that has already expired
• Go into token overdraft