Roles & Permissions

A role is a named set of permissions you give to members, on all projects or on the ones you choose. Owners do not need roles: they can already do everything.

A new install has no roles. Create the first one before you invite anyone who is not an owner, or they arrive with No access. An upgraded install starts with the roles its project members already used: see Upgrade to 0.25.

Create a role

1. Go to Settings → Roles and click New role.
2. Enter a Name. To start from an existing role, pick it under Copy permissions from.
3. Click Create role. Rustrak opens the new role.
4. Go through the tabs (Workspace, Settings, Issues, Monitoring, Releases, Alerts, Project) and tick what the role allows. Each tab counts what is on.
5. Under General, add a Description. It shows wherever someone assigns the role.
6. Click Save.

The grid only offers permissions you hold. Then give the role to someone.

Saving a change reaches everyone holding the role at once, along with their API tokens. Delete role only works on a role nobody holds and no pending invitation names; otherwise Rustrak answers 409.

How permissions add up

Each permission is a resource and an action, like Issues and events with Edit. Someone’s access is the sum of every role they hold. There are no deny rules, so a second role can only add.

Where a permission applies depends on its kind:

• Project permissions apply on the role’s Scope: all projects, including ones created later, or the projects chosen.
• Workspace and settings permissions have no project to apply to. They count as soon as the role is held, even if its scope is one project. A role with Users and View given on Storefront lets its holder list the whole team.

Two rules save you some ticking. Edit, Create or Delete on a resource implies View on it, except for API tokens. And any permission on a project shows that project: there is no separate permission to see it.

The dashboard follows the same permissions: settings pages and buttons that you cannot use are hidden or read-only. The server enforces them either way, for the dashboard, the API and the MCP server.

Who can change what

Nobody hands out more than they hold. You can only write a permission into a role if you hold it, and in the case of a project permission, on every project. Editing an existing role also needs every permission it has now, so nobody strips one they could not give back. You cannot change your own roles.

Only owners make or change owners.

Who can create a project

Creating a project takes Projects with Create and at least one project permission somewhere. With only the first, the server refuses with Creating a project also requires a project permission, because the creator could never see the result.

Creating one does not make you its admin. If your roles reach only some projects, those roles and your custom permissions extend to the new project. A Viewer who creates a project is a Viewer on it. If your roles reach all projects, nothing needs extending.

All permissions

The API calls an action read, create, update or delete; the dashboard shows View, Create, Edit and Delete. A permission is written resource:action, like issues:update, in API errors and in role and token requests.

Workspace

Everyone can see and revoke their own tokens without any of these.

Settings

Project

GET /api/access/catalog returns this list, and GET /api/access/me what the caller holds.