Modify RBAC and GAC definitions#445
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughWalkthroughThis pull request updates documentation to clarify role-based access control concepts. The changes redefine how RBAC and GAC are explained, emphasizing that RBAC is the default and GAC enables custom roles built from permission schemes. Additionally, permission scheme combination behavior is clarified as union-only. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
docs/roles-and-permissions/permission-schemes.md (1)
84-90: Clarify “More permissive wins” to avoid redundancy/vagueness.Right now the bullets say both:
- “More permissive wins” and
- “Scheme combination is union-only — you cannot subtract permissions…”
That’s probably accurate, but it’s not clear what “more permissive” refers to (conditional vs unconditional? same permission appearing from multiple schemes?).
Consider tightening the wording so it explicitly matches the intended rule (e.g., unconditional/conditional for the same permission) and avoids repeating “union-only”.♻️ Proposed rewording
- - **More permissive wins.** If schemes grant the same permission, it's still granted. Scheme combination is union-only — you cannot subtract permissions by adding another scheme. + - **More permissive wins.** For the same permission, the effective grant uses the more permissive outcome (e.g., unconditional beats conditional). Scheme combination is union-only — adding a scheme cannot remove permissions.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/roles-and-permissions/permission-schemes.md` around lines 84 - 90, The two bullets "More permissive wins" and "Scheme combination is union-only — you cannot subtract permissions…" are redundant and ambiguous about what "more permissive" means; update the text so it explicitly states that when the same permission appears in multiple schemes an unconditional grant (e.g., workitem:delete) overrides any conditional grant (e.g., workitem:delete+creator), and clarify that combination is a union of permissions across schemes (you cannot revoke a permission by adding another scheme) — replace the two bullets with a single concise rule that mentions "unconditional vs conditional" and "union-only" to remove ambiguity.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/roles-and-permissions/overview.md`:
- Line 95: Remove the extra space inside the closing bold/strong emphasis
markers in the sentence "Can Bob edit work items? **" so the emphasis wraps
correctly (change "**Can Bob edit work items? **" to "**Can Bob edit work
items?**"); update the text in overview.md where that phrase appears to
eliminate the trailing space inside the **...** markers to satisfy MD037.
---
Nitpick comments:
In `@docs/roles-and-permissions/permission-schemes.md`:
- Around line 84-90: The two bullets "More permissive wins" and "Scheme
combination is union-only — you cannot subtract permissions…" are redundant and
ambiguous about what "more permissive" means; update the text so it explicitly
states that when the same permission appears in multiple schemes an
unconditional grant (e.g., workitem:delete) overrides any conditional grant
(e.g., workitem:delete+creator), and clarify that combination is a union of
permissions across schemes (you cannot revoke a permission by adding another
scheme) — replace the two bullets with a single concise rule that mentions
"unconditional vs conditional" and "union-only" to remove ambiguity.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 47c4d9d3-4ce2-4869-8808-6b2e412dc974
📒 Files selected for processing (2)
docs/roles-and-permissions/overview.mddocs/roles-and-permissions/permission-schemes.md
| A few worked examples make this concrete. | ||
|
|
||
| **Can Bob edit work items** Bob has the Contributor role on the project. The system finds no per-resource grant on the issue, walks up to the project, finds Bob's Contributor role, sees that Contributor includes `workitem:edit`, and allows the edit. | ||
| **Can Bob edit work items? ** Bob has the Contributor role on the project. The system walks up to the project, finds Bob's Contributor role, sees that Contributor includes `workitem:edit`, and allows the edit. |
There was a problem hiding this comment.
Fix markdown emphasis spacing (MD037).
Line 95 has a trailing space inside the emphasis markers (**... ? **). This triggers markdownlint’s “no-space-in-emphasis” rule and can lead to inconsistent rendering.
🛠️ Proposed fix
-**Can Bob edit work items? ** Bob has the Contributor role on the project. The system walks up to the project, finds Bob's Contributor role, sees that Contributor includes `workitem:edit`, and allows the edit.
+**Can Bob edit work items?** Bob has the Contributor role on the project. The system walks up to the project, finds Bob's Contributor role, sees that Contributor includes `workitem:edit`, and allows the edit.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| **Can Bob edit work items? ** Bob has the Contributor role on the project. The system walks up to the project, finds Bob's Contributor role, sees that Contributor includes `workitem:edit`, and allows the edit. | |
| **Can Bob edit work items?** Bob has the Contributor role on the project. The system walks up to the project, finds Bob's Contributor role, sees that Contributor includes `workitem:edit`, and allows the edit. |
🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 95-95: Spaces inside emphasis markers
(MD037, no-space-in-emphasis)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/roles-and-permissions/overview.md` at line 95, Remove the extra space
inside the closing bold/strong emphasis markers in the sentence "Can Bob edit
work items? **" so the emphasis wraps correctly (change "**Can Bob edit work
items? **" to "**Can Bob edit work items?**"); update the text in overview.md
where that phrase appears to eliminate the trailing space inside the **...**
markers to satisfy MD037.
Description
Type of Change
Screenshots and Media (if applicable)
Test Scenarios
References
Summary by CodeRabbit