Roles + permissions
AfriAnnotate's authorisation model has two layers:
- Organisation role — set when the user joins your org. Determines the default permissions across all projects in that org.
- Per-project role — optional override. A user added explicitly to a project gets the role assigned there, regardless of their org-level role.
In addition, there are two platform-level flags orthogonal to org membership:
is_staff— gives access to Platform Settings, the Users page, the platform audit log, and the email-template editor.is_superuser— the same, plus Django-admin access. Set on the first user of a fresh platform; rarely granted afterwards.
Neither flag is a role in an organisation. The people who run the platform reach an organisation's projects, data, members and settings only while one of its owners has let them in: see Letting platform support in.
Org roles, top to bottom​
| Role | Short | What they can do |
|---|---|---|
| Owner | OW | Manages the organisation end-to-end. Full access to every project, every workspace, every member. One Owner per org. The first user to create the org becomes the Owner. |
| Administrator | AD | Full access except changing the Owner. Invites + removes members, creates + archives projects, configures org settings. |
| Manager | MA | Creates projects. Manages members within projects they own or are added to. Cannot see other Managers' private projects. Reaches the Organization area (Overview, Members read-only, Workspaces, Analytics, Resources) but not Settings, Quality, Review, Payouts, Policies or Activity. |
| Reviewer | RE | Reviews annotated tasks. Sees only projects they're added to. Can accept / reject / re-assign annotations. Can also annotate by default — project owners can switch that off per project (Project → Settings → Annotation, the annotation-roles setting). |
| Annotator | AN | Labels tasks. Sees only projects they're added to. Default role for users joining via invite link. |
| Guest | GU | Org member with no project access. Cannot open, annotate, review or manage projects. Use it to keep someone in the org (records, billing, pending onboarding) without giving them work. |
Permissions matrix​
| Action | Owner | Admin | Manager | Reviewer | Annotator | Guest |
|---|---|---|---|---|---|---|
| Create projects | ✓ | ✓ | ✓ | — | — | — |
| Archive / delete own projects | ✓ | ✓ | ✓ | — | — | — |
| Archive / delete any project | ✓ | ✓ | — | — | — | — |
| Invite users to the org | ✓ | ✓ | ✓ (from a project's Members settings, unless the org policy restricts invites) | — | — | — |
| See the org's member list | ✓ | ✓ | ✓ (read-only) | — | — | — |
| Remove users from the org | ✓ | ✓ | — | — | — | — |
| Change member roles | ✓ | ✓ (except Owner) | — | — | — | — |
| See all projects in the org | ✓ | ✓ | — (only theirs) | — (only assigned) | — (only assigned) | — (only assigned) |
| Edit labeling config | ✓ | ✓ | ✓ (own) | — | — | — |
| Import + delete tasks | ✓ | ✓ | ✓ (own) | — | — | — |
| Submit annotations | ✓ | ✓ | ✓ (own) | ✓ (default; per-project toggle) | ✓ | — |
| Review annotations | ✓ | ✓ | ✓ (own) | ✓ | — | — |
| Export annotations | ✓ | ✓ | ✓ (own) | — | — | — |
| View projects | ✓ | ✓ | ✓ | ✓ (assigned) | ✓ (assigned) | — |
| Edit organisation settings | ✓ | ✓ | — | — | — | — |
| Open Platform Settings | staff only | staff only | staff only | staff only | staff only | staff only |
| Mark users email-verified | staff only | staff only | staff only | staff only | staff only | staff only |
The "own" qualifier on Manager rows means projects they created or were explicitly added to.
Per-project overrides​
A user's org role applies by default to every project in that org. Override on a per-project basis by adding them with a specific role:
- An org-level Admin added to project X as Annotator can still see every project in the org (admin) but on project X is treated as an annotator (no reviewer queue, no settings).
- An org-level Annotator is invisible to projects they aren't explicitly added to. They have to be added to each project they should see.
To manage per-project roles: Project → Settings → Members → + Add member.
Platform-level flags​
is_staff and is_superuser are managed from Platform → Users:
- Click the user's row → modal opens.
- Platform role section near the bottom:
- Grant staff / Revoke staff — Owners + Admins of any org can be staff regardless of org role. Staff see Platform Settings, the Users page, the audit log.
- Grant superuser — only the existing superuser can grant this. Use sparingly.
The first user on a fresh platform is auto-granted both flags. Use the + Create User form on the Users page to assign roles to new users at creation time.
Audit + accountability​
Every role change audit-logs with:
- The actor (who made the change)
- The target (whose role changed)
- The previous + new role
- Timestamp
View at Platform → Audit log (staff-only). Filter by action type
to see only role-related events (member.role_change,
user.staff_grant, user.staff_revoke).
Common gotchas​
Manager can't see another Manager's project. Working as designed — Managers see only their own projects + ones they're explicitly added to. Use Admins for cross-project oversight.
Annotator on the mobile app sees the same projects as on web. Yes — same account, same org, same per-project memberships. The mobile UI hides operator surfaces (project create, members, platform settings) but the underlying access rules are identical.
Transferring ownership.
The Owner (or platform staff) can hand the org to another active
member from Organization → Settings → Danger Zone → Transfer
ownership, or with POST /api/organizations/<id>/transfer. The new
owner gets the Owner role; the previous Owner becomes an Admin. The
transfer is audit-logged as org.transfer. Owner is never granted
by a plain role change — see Members.
What's next​
- Members + invites → — the day-to-day operations for adding / removing / promoting users
- Workspaces → — group projects + cascade membership
- Security model → — the full auth + authorisation architecture