Roles & Permissions
Rhesis controls what each member can do through roles, assigned at the organization level and, optionally, overridden per project.
Roles & Permissions is an Enterprise Edition feature. Community installations use a simpler model: the organization owner can do anything, and any project member can act within their project.
Community vs. Enterprise
| Capability | Community | Enterprise |
|---|---|---|
| Organization owner has full control | Yes | Yes |
| Any project member can perform any action within their project | Yes | Only if their role grants it |
| Built-in graded roles (Owner, Admin, Member, Viewer, None) | No | Yes |
| Custom roles with hand-picked permissions | No | Yes |
| Per-project role override (different access per project) | No | Yes |
| API token permission scoping | No | Yes |
Built-in roles
| Role | Level | Access |
|---|---|---|
| Owner | 100 | Full control, including billing, deletion, and ownership transfer |
| Admin | 80 | Manage members, roles, projects, and org settings. Cannot delete the org |
| Member | 60 | Create, edit, and run evaluations across their projects. Manage own API tokens |
| Viewer | 40 | Read-only access. Can browse and export but not change anything |
| None | 0 | No access. Used to explicitly revoke a member while keeping them in the org |
Built-in roles are fixed and cannot be edited or deleted.
Organization roles vs. project roles
A project-level role can only add to what your organization role already grants — it can never take access away. This mirrors how GitLab and Google Cloud IAM handle nested scopes: a narrower scope (project) can elevate access above a broader scope (organization), but it never restricts what the broader scope already grants. If you have both an organization role and an explicit role on a specific project, the higher-level role always wins for that project.
- No organization role at all: the explicit project role (if any) is the whole answer — there’s no broader role to compare it against.
- Org Admin or Owner: implicit access to every project already. An explicit project role only matters if it’s higher, in which case it elevates further for that one project.
- Org Member or Viewer: must be added to a project (given a project role, or added as a plain member) before they get any access there. Once added, the higher of their org role and any explicit project role applies.
Examples
- A contractor with no organization role is added to one project only, with a Member role on that project. They have no access to any other project — there’s no org role to fall back on.
- An org Viewer is granted an explicit Owner role on a single project. They keep Viewer access everywhere else and gain full Owner access on that one project (elevation).
- An org Owner is also explicitly assigned a lower Admin role on one project (for example, from a default project setup). Their access on that project stays at Owner level — the lower project role does not restrict them.
- An org Admin never needs to be added to a project explicitly. Admin and Owner get implicit access to every project.
Custom roles
Owners can create custom roles with a hand-picked set of permissions (role:manage is Owner-only by default, Admin is excluded).
- A role’s permissions and level can never exceed the creator’s own access.
- New capabilities added in future releases do not automatically appear in existing custom roles. An admin must add them explicitly (fail-closed by design).
- Deleting a custom role reassigns org-level holders to None and clears project-level holders back to their org role.
Managing roles in the UI
- Go to Organization Settings, Roles tab.
- Review the Built-in Roles card (read-only “Details” view) and the Custom Roles table.
- Click “New role”: name it, add a description, optionally copy permissions from a built-in template, then set access per area (Test Resources, Observability, Infrastructure, Administration) using the View / Edit / Manage graded control. A live “This role can” summary shows the effective permissions.
- Assign roles from the Team page (role column or member drawer for org roles), from a project’s Members tab (project-level roles), or inline during the invite flow.
Manage roles via API
| Endpoint | Purpose |
|---|---|
GET /rbac/roles | List built-in and custom roles |
GET /rbac/roles/{role_id} | Read one role and its permissions |
POST /rbac/roles | Create a custom role |
PUT /rbac/roles/{role_id} | Update a custom role |
DELETE /rbac/roles/{role_id} | Delete a custom role |
GET /rbac/organization-members | List org-level role assignments |
PUT /rbac/organization-members/{user_id}/role | Assign or change a user’s org role |
DELETE /rbac/organization-members/{user_id} | Remove a user’s org role |
GET /rbac/projects/{project_id}/members | List a project’s role assignments |
PUT /rbac/projects/{project_id}/members/{user_id}/role | Assign or change a user’s project role |
Revoking access
Assign the None role at the org tier to revoke a member while keeping them in the organization. None is not a valid project-tier assignment (the API returns a 422 error), since it has no meaning there.
Because project roles can elevate but never restrict, setting a member’s org role to None does not by itself remove any higher explicit role they still hold on individual projects — that project role now outranks None and still applies there. To fully revoke someone, also remove or downgrade their project-level role assignments.
Notes
- Role changes can take up to 45 seconds to propagate (permission cache TTL). Not a bug.
- Create and edit controls may appear a moment after the page renders while permissions are still loading. Not a bug.
- The org’s last remaining Owner cannot be demoted or removed.