[devin-ai-integration]

• In merge queue
• Prioritize

Summary

Adds a Permissions by role section to access-control/rbac.mdx. It shows, for each resource, what each system-managed role except Owner can do with it (Manage / Read / no access). Owner can do everything, so it isn't a column. Rows use the resource's display name; the type keys stay listed on the custom roles page. The rows are grouped by area: projects, pipelines, credentials, platform, access, and organization/billing.

The tables come from packages/shared-go/authz/catalog/catalog.go (registrations), which lists the supported actions for each type, and presets.go (the *Statements functions), which defines each role's grants, in ravionhq/flightcontrol:

• Every role except Billing reads all types except authorizationPolicy and billing.
• Billing gets only billing (read, update) and organization (read).
• In every row, each role either has all of the type's actions or only read, so a Manage / Read / dash cell is exact.
• Footnotes: reading a credential returns its metadata only, and organization:delete is limited to human members (HumanOnly).

Link to Devin session: https://app.devin.ai/sessions/3013353de14f4cf6b47a4f41b64de9fe
Open in Devin Desktop: https://app.devin.ai/desktop/session/3013353de14f4cf6b47a4f41b64de9fe?variant=devin
Requested by: @mabadir

Confidence Score: 4/5

The PR appears safe to merge, with two non-blocking documentation inconsistencies to clean up.

Findings

1.  Deletion guidance conflicts ▶
2.  Service-account example contradicts limits ▶

Fix with agent prompt

### Issue 1
access-control/rbac.mdx:58-61
The new tables list no `delete` action for `pipelineRun`, `pipelineApproval`, or `moduleDeployment`, but the Operator summary above explicitly says it can delete runs, approvals, and deployments. Readers get two different answers about the same permission. Align the summary with these action lists.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

### Issue 2
access-control/rbac.mdx:100
The new example says a service account can hold a role that allows organization deletion. The Service accounts section below says it cannot hold any such role. Readers may think this assignment is allowed. Remove that example or clarify the distinction between a role's permissions and whether a service account can receive it.

```suggestion
Reading a credential or a secret default value returns its metadata, never the secret value. Only members can delete the organization. A service account can't hold Owner or any role that allows organization deletion.
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

Adds six grouped permissions tables with resource keys, supported actions, and access for each system-managed role.

• The RBAC guide shows what each role can do for every resource.

_{Reviews (1) · Last reviewed commit: "Add permissions-by-role table to RBAC pa..." · Reviewed by Greptile}

CI Status

2 passed, 0 failed, 3 pending (use git with action=pr_checks for full details)
Pending: check, Mintlify Validation (ravion-b90c0359) - link-rot, Mintlify Deployment

[devin-ai-integration]

I'll fix CI failures and address comments from users with write access. I'll skip comments containing "(aside)".

• Disable automatic comment, CI, and merge conflict monitoring

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
Ravion	🟢 Ready	View Preview	Oct 24, 2026, 3:43 PM

[flybayer]

@devin-ai-integration remove owner column since it can always do anything

[devin-ai-integration]

Done in b8aaeca. I removed the Owner column from every permissions table and added a line to the intro saying Owner can do everything.

[flybayer]

@devin-ai-integration Still need improved. I think the actions, like, it doesn't really make sense. I think it can just be probably just removed. And then the name is like Rough, I don't know that we need the key. Either just have the name or just the key, whatever you think is best

[devin-ai-integration]

Done in 40a331d. I removed the Actions column and the type keys, so each row now has just the resource name and the role columns. I kept the names because they're easier to scan. The type keys are still listed on the custom roles page for anyone writing rules, and the intro links there. Manage now just means full access.

[flybayer]

In billings table

[flybayer]

Add org add the add the billing role into the org

[devin-ai-integration]

Done in the latest commit. I took this to mean the Billing column should only appear in the organization and billing table, since Billing has no access anywhere else. I removed it from the other tables and added a line to the intro explaining why. If you meant something else, such as merging the Billing row into the Organization row, tell me and I'll change it.

[flybayer]

No, I want the billing role to be a column there

[devin-ai-integration]

Got it. I restored the Billing column in every table in f6fa174, so each table again has Platform Admin, Operator, Manager, Read only and Billing. The intro line about Billing appearing only in the last table is gone.

[flybayer]

I'm not seeing that updated in the Metlify preview environment. I'm expecting to see a billing column in the organization and billing section. and we can remove read only column from all tables

[devin-ai-integration]

Thanks for the screenshot. The Billing column was there, but the table was too wide and scrolled sideways, which hid it. In fd05f62 I removed the Read only column from every table, so all five columns fit and Billing is visible, including in Organization and billing. The intro now says Read only can read everything except roles and billing.

[flybayer]

okly have billing column in table where it has any permission

[devin-ai-integration]

Done in 5e8c2e5. The Billing column now appears only in the Organization and billing table, and the intro says why.