Permissions catalog
Reference for BugBrain's RBAC permission model — the area:action permission keys, the areas and actions in the catalog, and the five seed role templates (Owner, Admin, QA Engineer, Developer, Viewer).
BugBrain uses permission-based RBAC inside a workspace. A role holds a set of permission keys, and endpoints, pages, and buttons are gated against them. This page is the catalog reference. For managing roles, see Team & roles.
The area:action model#
Each permission is a string key of the form area:action:
- Area — a part of the product, e.g.
test-cases,issues,billing. - Action — what you can do there. The action vocabulary is:
| Action | Meaning |
|---|---|
view | See the area and its data. |
create | Add new items. |
edit | Change existing items. |
delete | Remove items. |
execute | Run things (e.g. run test cases, start scans). |
manage | Administer the area (connect, configure, assign). |
load | Launch load tests (separate from execute so a role can send single API requests without authorizing heavy load runs). |
So test-cases:edit means "edit test cases" and integrations:manage means "manage integrations".
Areas and their actions#
The catalog is grouped for the role editor. Each area offers only the actions listed.
Testing#
| Area | Key prefix | Actions |
|---|---|---|
| Test runs | test-runs | view, create, execute, delete |
| Test cases | test-cases | view, create, edit, delete, execute |
| Test plans | test-plans | view, create, edit, delete, execute |
| Test suites | suites | view, create, edit, delete |
| CSV import | csv-import | create |
| API testing | api-testing | view, create, edit, delete, execute, load |
| AI testing | ai-testing | view, create, edit, delete, execute |
Quality#
| Area | Key prefix | Actions |
|---|---|---|
| Issues | issues | view, edit |
| Accessibility | accessibility | view, execute |
| Compliance | compliance | view, edit, execute |
| Reports | reports | view, create, edit, delete |
Workspace#
| Area | Key prefix | Actions |
|---|---|---|
| Projects | projects | view, create, edit |
| Integrations | integrations | view, manage |
| PR automation | pr-automation | view, manage |
| Agent configuration | agent-config | manage |
Administration#
| Area | Key prefix | Actions |
|---|---|---|
| Members | members | view, manage |
| Roles | roles | manage |
| Billing | billing | view, manage |
| Workspace settings | org-settings | manage |
| API keys | api-keys | manage |
| Webhooks | webhooks | manage |
The app is the source of truth
This table reflects the current catalog. New areas and actions are added over time — the role editor in-app always shows the complete, current set.
How grants resolve#
- A role grants only the keys it explicitly holds. An empty grant list means the role can do nothing. (This is deliberately the inverse of API-key scopes, where an empty list means full access.)
- Locked Owner and Admin roles always resolve to every key in the catalog. Their permissions are computed in code, never stored — so any permission added in a future release is automatically granted to them, in every workspace, with no backfill.
- A few Owner-only operations (workspace deletion, ownership transfer) are hard checks, not catalog keys, and stay with the Owner role regardless of permissions.
Seed role templates#
Every workspace starts with five role templates:
| Role | Editable? | What it can do |
|---|---|---|
| Owner | Locked | Everything, including owner-only operations (workspace deletion, ownership transfer). |
| Admin | Locked | Everything except owner-only operations. |
| QA Engineer | Editable | View everything; create, edit, and run all testing and quality work. No deletes or workspace administration. |
| Developer | Editable | View everything; trigger runs and update issues. |
| Viewer | Editable | Read-only across the workspace. |
The three editable templates do not automatically receive permissions added in future releases — extending them is a deliberate choice. You can also build custom roles from any subset of the catalog.
Related#
Frequently asked questions
How are permissions named?
Every permission is an "area:action" key — the area is a part of the product (like test-cases or billing) and the action is what you can do there (view, create, edit, delete, execute, manage, or load). For example, "test-cases:edit".
What does an empty permission set mean for a role?
Nothing. A role grants only the keys it explicitly holds — an empty grant list means the role can do nothing. This is the opposite of API-key scopes, where empty means full access.
Do Owner and Admin need every key assigned?
No. The locked Owner and Admin system roles always resolve to every permission in the catalog, computed in code rather than stored — so new permissions added in future releases are automatically granted to them with no backfill.
What roles come built in?
Five seed templates — Owner and Admin (locked, full access) plus QA Engineer, Developer, and Viewer (editable). You can also create custom roles from the permission catalog.