Delegated Administration
In the admin: Roles › a role › Permissions (totalbase schema) · Members › Managed by
Applications need their own back office: a branch manager who invites their staff, a supervisor who reads their team's activity, an office that manages document templates. TotalBase's own screens for Users, Roles, Files, Templates and Logs can be opened to people who aren't administrators, scoped by their roles, without a second permission system.
How it works
TotalBase's own tables are resources too: users, roles, users_roles, files, templates, logs and others. A non-administrator gets an area in the portal by holding READ on its table:
| Area | Appears when the user's roles hold |
|---|---|
| Users | READ on users |
| Roles | READ on roles |
| Files | READ on files |
| Templates | READ on templates |
| Logs | READ on logs |
Everything else follows from the same grants. Each screen offers only the actions the user's roles allow, shows only the columns they may read, and lists only the rows their row filters let through. The screens use the Data API, so payload checks, auditing and the update before-and-after rule apply exactly as for any other table.
Database, the SQL Console, DataViews, Dashboards and Workflows design, Settings, and other users' tokens and sessions stay administrator-only.
Example: Acme's branch managers
Acme wants each branch's dispatcher to manage that branch's staff: see who works there, deactivate people when they leave, and give or take away the Technician role. Give the Dispatcher role:
| Table | Action | Row filter | Fields |
|---|---|---|---|
users | READ | { "branch": { "_eq": "$USER.branch" } } | id, name, email, active, avatar_url, branch, last_login_at |
users | CREATE | { "branch": { "_eq": "$USER.branch" } } | email, name, branch |
users | UPDATE | { "branch": { "_eq": "$USER.branch" } } | name, active |
roles | READ | id, name, description, icon, color | |
users_roles | READ, CREATE, DELETE | user, role |
Then, on the Technician role's Members section, set Managed by: Dispatcher. Dispatchers can now assign and remove the Technician role, and no other role.
Dispatchers can invite new staff into their own branch too. The invitation form shows the columns the CREATE grant allows (here Branch, in Additional data); they are set on the new account before the row filter is checked, so an invitation into another branch, or with none, is refused and creates nothing.
What can never be delegated
Some rules hold whatever the grants say:
- Permissions are administrator-only. Writing grants, object access, capabilities, role managers, settings, auth providers and secrets is reserved to administrators, through any path.
- Administrative roles are never assigned through delegation. No one is given Administrators, or any role with admin access, except by an administrator.
- Administrators' accounts are changed only by administrators.
- Account security is administrator-only: email addresses, email verification, unlocking, and whether an account can sign in. A delegated manager can rename, deactivate and reactivate users, and invite new ones, but can't change someone's email. Otherwise they could change it to their own and reset the password.
- Secrets are never readable: password hashes, token hashes, file storage paths and the SQL stored in audit entries.
Managing roles
A non-administrator with the right grants on roles can create roles. A role they create is theirs: they may rename it, delete it, and assign it to people. It starts with no permissions, and only an administrator can give it any.
| On a role | A delegated user may |
|---|---|
| create one | with CREATE on roles |
| rename or delete one | only roles they created |
| assign or remove members | roles they created, or roles one of their roles manages |
| edit permissions or access | never |
Invitations and resets
Inviting people and sending password resets aren't plain row writes, so they have their own endpoints under /app/api/users/*, authorized by the same grants: inviting needs CREATE on users (with each column it sets, its row filter checked on the new account), a reset needs UPDATE on that user's row. A delegated user's links always go by email to the account's own address. Only an administrator can receive a link to pass on.
Logs
A user's own activity is a grant: READ on logs where principal = $USER.id, which Apply default permissions gives. A supervisor can be granted a wider filter to read their team's entries. The SQL stored with an entry is never readable through this path.