Skip to Content

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

CapabilityCommunityEnterprise
Organization owner has full controlYesYes
Any project member can perform any action within their projectYesOnly if their role grants it
Built-in graded roles (Owner, Admin, Member, Viewer, None)NoYes
Custom roles with hand-picked permissionsNoYes
Per-project role override (different access per project)NoYes
API token permission scopingNoYes

Built-in roles

RoleLevelAccess
Owner100Full control, including billing, deletion, and ownership transfer
Admin80Manage members, roles, projects, and org settings. Cannot delete the org
Member60Create, edit, and run evaluations across their projects. Manage own API tokens
Viewer40Read-only access. Can browse and export but not change anything
None0No 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

  1. Go to Organization Settings, Roles tab.
  2. Review the Built-in Roles card (read-only “Details” view) and the Custom Roles table.
  3. 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.
  4. 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

EndpointPurpose
GET /rbac/rolesList built-in and custom roles
GET /rbac/roles/{role_id}Read one role and its permissions
POST /rbac/rolesCreate a custom role
PUT /rbac/roles/{role_id}Update a custom role
DELETE /rbac/roles/{role_id}Delete a custom role
GET /rbac/organization-membersList org-level role assignments
PUT /rbac/organization-members/{user_id}/roleAssign or change a user’s org role
DELETE /rbac/organization-members/{user_id}Remove a user’s org role
GET /rbac/projects/{project_id}/membersList a project’s role assignments
PUT /rbac/projects/{project_id}/members/{user_id}/roleAssign or change a user’s project role
create_custom_role.sh
curl -X POST "https://api.example.com/rbac/roles" -H "Authorization: Bearer $RHESIS_API_KEY" -H "Content-Type: application/json" -d '{
    "name": "qa-lead",
    "display_name": "QA Lead",
    "description": "Full access to test resources, read-only elsewhere",
    "scope": "organization",
    "permission_names": ["test_set:read", "test_set:create", "test_set:update", "test_run:read"]
}'

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.