Users and access¶
Users¶
Manage the people in your studio from Settings → Resources → Users & Groups. The table shows each user's avatar, name, email, and role. You can:
- Add a user with the New button (name, email, password, role),
- Change a role inline in the Role column,
- Select multiple rows to bulk-change roles or bulk-delete,
- Delete a single user with the trash icon on hover.
The default demo@fxquinox.dev account ships so you can sign in the first time.
Replace or remove it before any real use.
User deletion is permanent
Deleting a user removes their account record. Task assignments and time logs referencing that user are preserved but become unowned. There is no soft-delete.
Roles¶
Every user holds exactly one role. Roles are enforced server-side; the UI hides privileged actions, but the API is the enforcement boundary.
| Role | Access |
|---|---|
| Admin | Full access: can read and write all schema, pipeline config, users, automations, and webhooks. All other access below. |
| Supervisor | Can view all users' tasks and timesheets (team timesheet view). |
| Coordinator | Same cross-user access as Supervisor. |
| Artist | Can read schema; can create/update records they are assigned to or author; cannot view others' timesheets. |
| Webhook Service | Intended for service accounts behind integrations; same permissions as Artist for data access. |
The three privileged roles (Admin, Supervisor, Coordinator) can access the
team timesheet view at /timesheets. Schema writes (statuses, steps, schemas,
fields, etc.) are Admin-only.
Role gates on transitions
Workflow transitions can optionally be gated by role — for example, only an Admin or Supervisor may move a task to Final. This is configured in Settings → Workflow → Transitions.
Registration¶
New users can self-register via POST /auth/register (the endpoint is public
for bootstrapping). For a locked-down studio install, block this route at the
reverse proxy and create accounts exclusively through Settings.
API keys¶
For scripts and integrations, issue API keys instead of sharing passwords.
Keys are prefixed fxq_ and work as bearer tokens alongside JWTs. In Settings:
- Select a user to issue the key under.
- Give the key a name (for your reference).
- Copy the full
fxq_…token on creation — it is shown once and stored only as a SHA-256 hash.
Use API keys with the Python SDK or any HTTP client that
sets Authorization: Bearer fxq_….
Everything goes through the API
The web UI, the SDK, and your own scripts all authenticate through the same API. There is no privileged back door — access rules apply uniformly to every client.