Skip to content

Modify RBAC and GAC definitions#445

Closed
danciaclara wants to merge 2 commits intomasterfrom
modify-gac
Closed

Modify RBAC and GAC definitions#445
danciaclara wants to merge 2 commits intomasterfrom
modify-gac

Conversation

@danciaclara
Copy link
Copy Markdown
Collaborator

@danciaclara danciaclara commented Apr 27, 2026

Description

Type of Change

  • Bug fix (non-breaking change which fixes an issue)
  • Feature (non-breaking change which adds functionality)
  • Improvement (change that would cause existing functionality to not work as expected)
  • Code refactoring
  • Performance improvements
  • Documentation update

Screenshots and Media (if applicable)

Test Scenarios

References

Summary by CodeRabbit

  • Documentation
    • Clarified the essential differences between RBAC and GAC, emphasizing RBAC as the default system and GAC's capability to enable custom roles built from permission schemes.
    • Updated the "How permissions combine" section to explicitly explain that permission schemes use union-only combination, meaning additional schemes cannot remove existing permissions.

@vercel
Copy link
Copy Markdown

vercel Bot commented Apr 27, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
docs Ready Ready Preview, Comment Apr 27, 2026 4:30pm

Request Review

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Apr 27, 2026

📝 Walkthrough

Walkthrough

This 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

Cohort / File(s) Summary
RBAC and GAC Overview
docs/roles-and-permissions/overview.md
Rewrote introductory section heading and content to clarify that RBAC is default and GAC enables custom roles from permission schemes. Updated worked example phrasing.
Permission Scheme Combination
docs/roles-and-permissions/permission-schemes.md
Clarified "More permissive wins" behavior to explicitly state permission scheme combination is union-only, removing references to internal override mechanisms.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Poem

🐰 With words we hop through clarity's gate,
Explaining roles and who to state,
RBAC's default, GAC's dance so bright,
Permission schemes combine just right,
No subtraction in this flow,

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately describes the main changes in the pull request, which modify and clarify the definitions and explanations of RBAC (Role-Based Access Control) and GAC (Group Access Control) across two documentation files.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch modify-gac

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

📥 Commits

Reviewing files that changed from the base of the PR and between 29a0435 and e1d5875.

📒 Files selected for processing (2)
  • docs/roles-and-permissions/overview.md
  • docs/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.
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

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.

Suggested change
**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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant