Permissions Reference
MINT's RBAC has three pieces:
- 18 permissions in 5 resource families
- 3 system roles (Admin / Member / Viewer) plus admin-defined custom roles
- Project membership and experiment collaborators layered around visibility
The authoritative list lives at api/permissions.py; this page mirrors it.
Permission catalog
projects.* (5)
| Permission | What it grants |
|---|---|
projects.view | Read project metadata and member list |
projects.create | Create new projects |
projects.edit | Edit project metadata, change settings |
projects.delete | Delete a project |
projects.manage_members | Add / remove members and change project roles |
experiments.* (4)
| Permission | What it grants |
|---|---|
experiments.view | Read experiments inside accessible projects |
experiments.create | Create new experiments |
experiments.edit | Edit experiment metadata, design data, status |
experiments.delete | Delete an experiment |
plugins.* (4)
| Permission | What it grants |
|---|---|
plugins.view | See installed plugins and their metadata |
plugins.use | Invoke plugin routes (run analyses, fill design forms, etc.) |
plugins.configure | Change plugin settings, manage per-plugin user roles |
plugins.install | Install / uninstall / upgrade plugins (gates the marketplace approval action) |
users.* (3)
| Permission | What it grants |
|---|---|
users.view | List users |
users.invite | Send invitations to new users |
users.manage | Disable / re-enable users; assign system roles |
platform.* (2)
| Permission | What it grants |
|---|---|
platform.configure | Modify admin settings (SMTP, marketplace registry, observability, auth) |
platform.view_logs | View structured logs and the admin status dashboard |
System roles → permissions
The platform ships three system roles. Their permission sets come directly from api/permissions.py:
- Admin — every permission (all 18)
- Member — every permission EXCEPT
users.manage,platform.configure,plugins.install - Viewer — only the four
*.viewpermissions:projects.view,experiments.view,plugins.view,users.view
Tabular form:
| Admin | Member | Viewer | |
|---|---|---|---|
projects.view | ✓ | ✓ | ✓ |
projects.create | ✓ | ✓ | |
projects.edit | ✓ | ✓ | |
projects.delete | ✓ | ✓ | |
projects.manage_members | ✓ | ✓ | |
experiments.view | ✓ | ✓ | ✓ |
experiments.create | ✓ | ✓ | |
experiments.edit | ✓ | ✓ | |
experiments.delete | ✓ | ✓ | |
plugins.view | ✓ | ✓ | ✓ |
plugins.use | ✓ | ✓ | |
plugins.configure | ✓ | ✓ | |
plugins.install | ✓ | ||
users.view | ✓ | ✓ | ✓ |
users.invite | ✓ | ✓ | |
users.manage | ✓ | ||
platform.configure | ✓ | ||
platform.view_logs | ✓ | ✓ |
Custom roles
Admins can build custom roles by composing any subset of the 18 permissions above. Custom roles appear alongside the built-in three when assigning a user's system role.
Common custom-role recipes:
| Role | Permissions |
|---|---|
| Read-only auditor | All *.view permissions only |
| Plugin operator | plugins.view, plugins.use, plugins.configure (no install) |
| Plugin admin | The Plugin operator set plus plugins.install |
| Project lead | All projects.* plus all experiments.* |
The role-design rationale (why exactly these 18 permissions) is in decisions/2026-04-10-rbac-roles-design.md.
Project membership
Route-level write access is checked against the user's system role. Project membership is stored separately and is used for project membership lists and restricted experiment visibility. Each project also has a creator / lead; only the creator, lead, or an Admin can update/delete the project or manage members, and the route still requires the matching system permission.
| Relationship | Current effect |
|---|---|
| Project creator / lead | May administer the project when their system role has the required permission |
Project member editor | Stored membership label; contributes to restricted experiment visibility |
Project member viewer | Stored membership label; contributes to restricted experiment visibility |
access.experimentVisibilityMode controls how broad experiment visibility is. In open mode, users with experiments.view can list experiments broadly. In restricted mode, non-admin visibility is limited to experiments the user created, collaborates on, or can access through project membership.
Experiment collaborator overrides
Collaborators stored on an experiment grant a third tier of access for that experiment only. The collaborators field on Experiment records (user_id, role) pairs:
| Collaborator role | Effect |
|---|---|
| collaborator | Can read this experiment even if not a project member |
| owner | Can manage collaborators and delete the experiment; MINT keeps at least one owner |
Collaborator entries survive even if the user is later removed from the project — useful for cross-team work where a colleague needs to see one experiment without joining the whole project.
Plugin-internal roles
Plugins can register their own role enum via UserPluginRole. These are scoped to the plugin: they don't grant any platform permissions and don't appear in this matrix. A plugin's role affects only what that plugin's own UI lets the user do. Set them under Admin → Plugins → <plugin> → Users. See Plugin Development → Tutorials → Plugin roles for how plugins use them.
Next
→ Members & roles — how to assign roles in the UI → Authentication — how users prove who they are