RBAC and GAC#429
Merged
sriramveeraghanta merged 15 commits intomasterfrom Apr 27, 2026
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughReorganizes docs: removes legacy workspace role/permission pages, adds a new Roles and permissions section (overview, member roles, schemes, custom roles, permissions matrix), updates workspace/project member pages and sidebar, and adds redirects in Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 8
🧹 Nitpick comments (2)
docs/roles-and-permissions/custom-roles.md (1)
89-91: “One-time inheritance” label is misleading for described behavior.The note describes ongoing linkage to system scheme updates, not one-time inheritance. Consider renaming the callout title to avoid confusion.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/roles-and-permissions/custom-roles.md` around lines 89 - 91, The callout title "One-time inheritance" is misleading because the text describes live linkage to the system scheme; change the callout header token from "One-time inheritance" (the ::: info block title) to a clearer label such as "Linked inheritance" or "Live inheritance" and update the callout body if necessary to match the new title so the header and description are consistent (look for the ::: info One-time inheritance block and replace the title token and any contradictory wording).docs/roles-and-permissions/member-roles.md (1)
54-56: Consider varying sentence starts in this paragraph.Minor readability nit: consecutive sentences begin with “Project Admin...”.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/roles-and-permissions/member-roles.md` around lines 54 - 56, The two consecutive sentences both start with "Project Admin", making the paragraph repetitive; edit the sentences that reference "Project Admin" and "Project Admins" to vary sentence openings — e.g., keep the first sentence describing permissions ("Project Admin has full control..."), change the second to start with a pronoun or role-based lead ("They can also delete or archive the project itself.") or restructure into one fluent sentence, and ensure the following guidance sentence ("Use Project Admin for...") remains distinct; update occurrences of "Project Admin" and "Project Admins" in this paragraph accordingly.
🤖 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/custom-roles.md`:
- Around line 12-13: The markdown references dead routes
"/roles-and-permissions/member-roles-and-permissions" and
"/workspaces-and-users/create-permission-schemes"; update those anchor URLs to
the current roles-and-permissions routes used elsewhere in the docs (replace
each occurrence at the mentions around the first block and also occurrences near
lines 48-49 and 95-97). Locate the link markup text "[Roles and permissions]"
and "[Create permission schemes]" and swap their hrefs to the new, existing
routes used by the site (or update them to relative paths that match the current
roles-and-permissions section), ensuring all three occurrences are replaced
consistently.
In `@docs/roles-and-permissions/member-roles.md`:
- Line 10: Update the two stale links that point to removed routes by replacing
occurrences of the dead paths
"/roles-and-permissions/member-roles-and-permissions" and
"/workspaces-and-users/create-custom-roles" in the document (seen in the text
"For the conceptual background..." and the other occurrences around lines 133
and 149) with the current, canonical routes for those pages; find the correct
target URLs by searching the docs for the pages titled "Roles and permissions"
and "Create custom roles" and update the anchor hrefs so navigation no longer
fails.
In `@docs/roles-and-permissions/overview.md`:
- Around line 24-33: Add a language identifier to the fenced code block
containing the workspace hierarchy (the triple-backtick block that starts at the
diagram showing "Workspace ├── Project ...") to satisfy markdownlint MD040; for
example, change the opening fence from ``` to ```text so the block is explicitly
marked as plain text and the linter stops flagging it.
- Around line 135-136: Update the two dead links by changing the href targets
for the "Create custom roles" and "Create permission schemes" anchor texts to
the new routes under roles-and-permissions; replace the deprecated
/workspaces-and-users/create-custom-roles with the new
/roles-and-permissions/create-custom-roles and replace
/workspaces-and-users/create-permission-schemes with
/roles-and-permissions/create-permission-schemes so the links in the lines
containing "Create custom roles" and "Create permission schemes" point to the
correct pages.
In `@docs/roles-and-permissions/permission-schemes.md`:
- Line 10: This page contains dead internal links (e.g. the hrefs
"/roles-and-permissions/member-roles-and-permissions",
"/workspaces-and-users/create-custom-roles",
"/workspaces-and-users/disable-system-roles") that trigger VitePress CI
warnings; update each broken anchor to the correct relative doc path or use the
canonical permalinks used elsewhere in the site, ensuring link targets exist and
use consistent trailing slashes (or remove them) so VitePress can resolve
them—search for those exact strings in the file (and the similar occurrences
around lines 94–96) and replace them with the correct routes used by the docs
site.
In `@docs/roles-and-permissions/permissions-matrix.md`:
- Line 10: The markdown contains dead links pointing to
/roles-and-permissions/member-roles-and-permissions (e.g., the sentence "For
conceptual background, see [Roles and
permissions](/roles-and-permissions/member-roles-and-permissions)"); update
those link targets to /roles-and-permissions/overview everywhere they appear
(also replace any other occurrences of
/roles-and-permissions/member-roles-and-permissions such as the second instance
near the bottom), ensuring the link text remains correct and the new URL is used
consistently.
- Around line 21-23: Update the first paragraph so it matches the actual tables:
instead of saying "The Owner column is omitted from individual tables and
assumed ✓ throughout," change the wording to state that the Owner column is
included in the workspace tables and that Workspace Owner holds a full-access
wildcard (appearing as ✓ throughout). Also ensure the following sentence about
"Workspace Admin and Owner bypass projects" remains accurate and consistent with
the new Owner wording.
- Line 570: Update the markdown link "[Create custom
roles](/workspaces-and-users/create-custom-roles)" to point to the new
documentation route (replace the old /workspaces-and-users path with the current
docs path for custom roles), i.e. locate the link text "Create custom roles" in
permissions-matrix.md and change its target URL to the new
/roles-and-permissions/create-custom-roles (or the project's canonical new
route) so CI no longer flags the outdated path.
---
Nitpick comments:
In `@docs/roles-and-permissions/custom-roles.md`:
- Around line 89-91: The callout title "One-time inheritance" is misleading
because the text describes live linkage to the system scheme; change the callout
header token from "One-time inheritance" (the ::: info block title) to a clearer
label such as "Linked inheritance" or "Live inheritance" and update the callout
body if necessary to match the new title so the header and description are
consistent (look for the ::: info One-time inheritance block and replace the
title token and any contradictory wording).
In `@docs/roles-and-permissions/member-roles.md`:
- Around line 54-56: The two consecutive sentences both start with "Project
Admin", making the paragraph repetitive; edit the sentences that reference
"Project Admin" and "Project Admins" to vary sentence openings — e.g., keep the
first sentence describing permissions ("Project Admin has full control..."),
change the second to start with a pronoun or role-based lead ("They can also
delete or archive the project itself.") or restructure into one fluent sentence,
and ensure the following guidance sentence ("Use Project Admin for...") remains
distinct; update occurrences of "Project Admin" and "Project Admins" in this
paragraph accordingly.
🪄 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: 917187de-4387-46ca-9995-a442e6ab33ea
📒 Files selected for processing (13)
docs/.vitepress/config.tsdocs/core-concepts/projects/manage-project-members.mddocs/core-concepts/workspaces/members.mddocs/core-concepts/workspaces/overview.mddocs/introduction/tutorials/invite-members.mddocs/roles-and-permissions/custom-roles.mddocs/roles-and-permissions/member-roles.mddocs/roles-and-permissions/overview.mddocs/roles-and-permissions/permission-schemes.mddocs/roles-and-permissions/permissions-matrix.mddocs/workspaces-and-users/permissions.mddocs/workspaces-and-users/roles.mdvercel.json
💤 Files with no reviewable changes (2)
- docs/workspaces-and-users/permissions.md
- docs/workspaces-and-users/roles.md
Comment on lines
+24
to
+33
| ``` | ||
| Workspace | ||
| ├── Project | ||
| │ ├── Work items, Epics, Modules, Cycles | ||
| │ ├── Pages, Views, Intake | ||
| │ └── Labels, States, Estimates, ... | ||
| ├── Teamspace ──(grants access to)──► Project | ||
| ├── Wiki, Initiatives, Releases, Dashboards | ||
| └── Integrations, Webhooks, Analytics, ... | ||
| ``` |
There was a problem hiding this comment.
Add a language to the fenced code block.
Line 24 uses a fenced code block without a language, which triggers markdownlint (MD040).
Proposed fix
-```
+```text
Workspace
├── Project
│ ├── Work items, Epics, Modules, Cycles
│ ├── Pages, Views, Intake
│ └── Labels, States, Estimates, ...
├── Teamspace ──(grants access to)──► Project
├── Wiki, Initiatives, Releases, Dashboards
└── Integrations, Webhooks, Analytics, ...</details>
<!-- suggestion_start -->
<details>
<summary>📝 Committable suggestion</summary>
> ‼️ **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.
```suggestion
🧰 Tools
🪛 markdownlint-cli2 (0.22.0)
[warning] 24-24: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/roles-and-permissions/overview.md` around lines 24 - 33, Add a language
identifier to the fenced code block containing the workspace hierarchy (the
triple-backtick block that starts at the diagram showing "Workspace ├── Project
...") to satisfy markdownlint MD040; for example, change the opening fence from
``` to ```text so the block is explicitly marked as plain text and the linter
stops flagging it.
Comment on lines
+135
to
+136
| - To create custom roles, see [Create custom roles](/workspaces-and-users/create-custom-roles). | ||
| - To build reusable permission bundles, see [Create permission schemes](/workspaces-and-users/create-permission-schemes). No newline at end of file |
There was a problem hiding this comment.
Fix dead links to custom roles and permission schemes pages.
Line 135 and Line 136 point to deprecated paths that CI already flags as dead. Update these to the new roles-and-permissions routes.
Proposed fix
-- To create custom roles, see [Create custom roles](/workspaces-and-users/create-custom-roles).
-- To build reusable permission bundles, see [Create permission schemes](/workspaces-and-users/create-permission-schemes).
+- To create custom roles, see [Create custom roles](/roles-and-permissions/custom-roles).
+- To build reusable permission bundles, see [Create permission schemes](/roles-and-permissions/permission-schemes).📝 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
| - To create custom roles, see [Create custom roles](/workspaces-and-users/create-custom-roles). | |
| - To build reusable permission bundles, see [Create permission schemes](/workspaces-and-users/create-permission-schemes). | |
| - To create custom roles, see [Create custom roles](/roles-and-permissions/custom-roles). | |
| - To build reusable permission bundles, see [Create permission schemes](/roles-and-permissions/permission-schemes). |
🧰 Tools
🪛 LanguageTool
[style] ~135-~135: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...pts/projects/manage-project-members). - To create custom roles, see [Create custom...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~136-~136: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...paces-and-users/create-custom-roles). - To build reusable permission bundles, see ...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/roles-and-permissions/overview.md` around lines 135 - 136, Update the
two dead links by changing the href targets for the "Create custom roles" and
"Create permission schemes" anchor texts to the new routes under
roles-and-permissions; replace the deprecated
/workspaces-and-users/create-custom-roles with the new
/roles-and-permissions/create-custom-roles and replace
/workspaces-and-users/create-permission-schemes with
/roles-and-permissions/create-permission-schemes so the links in the lines
containing "Create custom roles" and "Create permission schemes" point to the
correct pages.
dheeru0198
reviewed
Apr 16, 2026
|
|
||
| **Role-Based Access Control (RBAC)** is the foundation. Every user holds a role — Owner, Admin, Member, Guest, Contributor, Commenter, or a custom role you've defined — and that role carries a defined set of permissions. | ||
|
|
||
| **Granular Access Control (GAC)** sits on top. It lets you grant or deny specific permissions to specific users on specific resources, independent of their role. A Member could be denied "delete work items" on one particular project, or a Guest could be granted "edit" on a specific page. GAC is for the exceptions — situations where role-level access is too coarse. |
Member
There was a problem hiding this comment.
@danciaclara Guest could be granted "edit" on a specific page, this might be a bad example to convey the possibilities of GAC, as the Guest (or any system) role is not editable
dheeru0198
reviewed
Apr 16, 2026
| └── Integrations, Webhooks, Analytics, ... | ||
| ``` | ||
|
|
||
| Permissions inherit upward. If a user has Admin on a project, they have access to everything inside that project. If a user has Admin on the workspace, they have access to all projects and their content via wildcard grants. |
Member
There was a problem hiding this comment.
@danciaclara "wildcard grants", this is an internal technical term we're using in the code. We're not providing anything like "wildcard grants" in the UI (for system roles or custom roles), so it's better to remove this wording.
dheeru0198
reviewed
Apr 16, 2026
| | -------------------------------------------- | ---- | --- | -------- | ---------- | | ||
| | Workspace Admin, Member, Guest | ✓ | ✓ | ✓ | ✓ | | ||
| | Project Admin, Contributor, Commenter, Guest | ✓ | ✓ | ✓ | ✓ | | ||
| | **Workspace Owner role** | — | — | ✓ | ✓ | |
Member
There was a problem hiding this comment.
@danciaclara Workspace owner is for all the plans. Workspace Admin is for Business and Enterprise.
dheeru0198
reviewed
Apr 16, 2026
Comment on lines
+81
to
+82
| 1. **Explicit DENY** on this exact resource → access denied. | ||
| 2. **Explicit GRANT** on this exact resource → access allowed. |
Member
There was a problem hiding this comment.
@danciaclara These 2 are future scope, we can probably keep it but there is no way right now to do explicit deny or grant permissions on resource
dheeru0198
reviewed
Apr 16, 2026
|
|
||
| **Teamspace → project link relations.** A teamspace can be linked to one or more projects, and the link carries a role. All teamspace members get that role on the linked project without a separate project membership being created. A user can have both a direct project membership and teamspace-derived access — both are evaluated, and access resolves to whichever permits the action. | ||
|
|
||
| **Guest ceiling.** Workspace Guests are restricted from receiving high-privilege project roles. When you add a workspace Guest to a project, you can only assign them the Guest or Commenter role. Attempting to assign Admin or Contributor returns an error. This prevents privilege escalation through project assignment. |
Member
There was a problem hiding this comment.
@danciaclara This can be further expanded to convey that, "A workspace guest can't be assigned to a custom role at project"
dheeru0198
reviewed
Apr 16, 2026
|
|
||
| Owner is the highest workspace role. It carries full access to everything in the workspace, including the two operations no other role can perform: deleting the workspace and transferring ownership to another user. | ||
|
|
||
| Owner exists from the Business plan onwards. On Free and Pro, Admin is the highest role and there is no separate Owner. |
Member
There was a problem hiding this comment.
@danciaclara We're giving Owner to all the plans and Admin to business/enterprise
dheeru0198
reviewed
Apr 16, 2026
Comment on lines
+112
to
+120
| Roles have an internal authority level used to enforce who can manage whom. A user can only modify members whose role level is lower than their own. | ||
|
|
||
| | Role | Level | | ||
| | ------------------------------------------------------------- | ----- | | ||
| | Owner (workspace) | 25 | | ||
| | Admin (workspace, project) | 20 | | ||
| | Member (workspace), Contributor (project), Member (teamspace) | 15 | | ||
| | Commenter (project) | 10 | | ||
| | Guest (workspace, project) | 5 | |
Member
There was a problem hiding this comment.
@danciaclara We're not following this integer hierarchy. This is there in the codebase but it's just dead code for now. Let's not add this to documentation
dheeru0198
reviewed
Apr 16, 2026
|
|
||
| ## Why use permission schemes | ||
|
|
||
| You could theoretically attach permissions directly to a role, but schemes give you three advantages: |
Member
There was a problem hiding this comment.
@danciaclara This is not possible even theoretically with the recently made changes. Can't attach permissions directly to a role, can only attach permission schemes
There was a problem hiding this comment.
Actionable comments posted: 4
♻️ Duplicate comments (6)
docs/roles-and-permissions/permissions-matrix.md (1)
21-21:⚠️ Potential issue | 🟡 MinorMake the Owner note match the tables.
The intro says the Owner column is omitted, but the workspace tables below include
Ownerexplicitly.Suggested change
-**Owner has full access.** Workspace Owner holds a full-access wildcard and matches every permission in this document. The Owner column is omitted from individual tables and assumed ✓ throughout. +**Owner has full access.** Workspace Owner holds full access and appears as ✓ throughout the workspace tables in this document.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/roles-and-permissions/permissions-matrix.md` at line 21, Update the introductory Owner note to match the actual tables by removing the claim that the "Owner column is omitted" and instead state that the Owner column is included and that Workspace Owner holds full-access (wildcard) and is represented with ✓ in the tables; edit the sentence starting with "**Owner has full access.** Workspace Owner holds a full-access wildcard..." so it no longer says the Owner column is omitted and explicitly aligns with the tables that include an `Owner` column.docs/roles-and-permissions/overview.md (3)
24-33:⚠️ Potential issue | 🟡 MinorAdd a language to the fenced diagram block.
Use
texton the opening fence so markdownlint stops flagging this section.Suggested change
-``` +```text Workspace ├── Project │ ├── Work items, Epics, Modules, Cycles │ ├── Pages, Views, Intake │ └── Labels, States, Estimates, ... ├── Teamspace ──(grants access to)──► Project ├── Wiki, Initiatives, Releases, Dashboards └── Integrations, Webhooks, Analytics, ...</details> <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against the current code and only fix it if needed.
In
@docs/roles-and-permissions/overview.mdaround lines 24 - 33, The fenced
ASCII diagram block in overview.md is missing a language tag which triggers
markdownlint; update the opening fence for that diagram block to specify the
language "text" (i.e., change the triple backtick that precedes the diagram to
49-55:⚠️ Potential issue | 🟠 MajorThis “what changed” section contradicts the role model above.
It says “Two things” but lists three bullets, and the first bullet collapses
Workspace AdminintoWorkspace Ownereven though the plan table above still treatsWorkspace Adminas a separate role. Please rewrite this section to describe the current model instead of presenting those roles as a rename.Suggested change
-## What changed from earlier versions - -Two things were renamed or restructured rather than added: - -- **"Workspace Admin" is now called "Workspace Owner."** +## What changed from earlier versions + +A few names and access patterns changed: + +- **Workspace Owner and Workspace Admin are distinct roles.** Owner exists across plans; Workspace Admin is a higher-privilege role on Business and Enterprise.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/roles-and-permissions/overview.md` around lines 49 - 55, Update the "What changed from earlier versions" section (header "What changed from earlier versions") to accurately describe the current role model rather than implying simple renames: remove "Two things" and instead state that the roles now include Workspace Owner, Workspace Admin (if still distinct per the plan table), Contributor (replaces Project Member), and Commenter (replaces the previous guest view toggle), and explicitly explain the mapping (e.g., "Project Member → Contributor" and "guest view toggle → Commenter role") so the bullets match the plan table above and no roles are incorrectly collapsed (do not drop Workspace Admin if the plan table still lists it). Ensure the three bullets are corrected to reflect these mappings and that the language clarifies the current behavior: Commenter grants view + comment permissions rather than a toggle.
16-19:⚠️ Potential issue | 🟠 MajorDon't present per-resource grant/deny as shipped behavior.
This section says GAC can explicitly allow or deny a permission on one specific resource. That reads like current product functionality, not a future direction, and the examples will send readers looking for controls that may not exist.
Suggested change
-**Granular Access Control (GAC)** sits on top. It lets you grant or deny specific permissions to specific users on specific resources, independent of their role. A Contributor could be denied "delete work items" on one particular project while keeping that permission everywhere else, or a specific user could be granted temporary edit access to a single page for the duration of an external review — all without changing anyone's role. GAC is for the exceptions — situations where role-level access is too coarse. +**Granular Access Control (GAC)** sits on top. In practice, Plane further refines role-based access with conditional rules such as creator-scoped and lead-scoped permissions on specific resources. Use it for exceptions where the base role alone is too coarse.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/roles-and-permissions/overview.md` around lines 16 - 19, Update the GAC paragraph to avoid implying per-resource allow/deny is current shipped behavior: in the "Granular Access Control (GAC)" section, change the language to explicitly mark per-resource grant/deny examples as hypothetical or planned (e.g., "illustrative / planned behavior" or "in future releases") and/or indicate current availability (what's supported today and where to find controls). Remove definitive phrasing that a Contributor "could be denied" on a specific project and replace with a clarifying sentence such as "This describes planned/illustrative GAC capabilities; check the product docs or release notes for current availability." Also update the examples to be clearly labeled as illustrative scenarios rather than existing features.docs/roles-and-permissions/member-roles.md (2)
108-115:⚠️ Potential issue | 🟠 MajorAvoid documenting the internal role-level hierarchy here.
“Internal authority level” reads like a supported product model, but the actionable rules are the bullets below. If the UI/API only guarantees those concrete rules, keep the section at that level instead of documenting the hidden hierarchy.
Suggested change
-## Role hierarchy - -Roles have an internal authority level used to enforce who can manage whom. A user can only modify members whose role level is lower than their own. +## Role management rules - Only Owners can manage other Owners. - Owners and Admins can manage Admins. - The last Admin or Owner of a workspace cannot leave or be demoted (last-admin protection). - The last Admin of a project cannot leave (last-admin protection).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/roles-and-permissions/member-roles.md` around lines 108 - 115, Remove the sentence referencing an "internal authority level" from the "## Role hierarchy" section and leave only the concrete, actionable bullets; specifically edit the paragraph that says "Roles have an internal authority level used to enforce who can manage whom. A user can only modify members whose role level is lower than their own." so it is deleted or replaced with a short lead-in that does not imply a hidden model, and keep the four bullets ("Only Owners can manage other Owners.", "Owners and Admins can manage Admins.", "The last Admin or Owner of a workspace cannot leave or be demoted (last-admin protection).", "The last Admin of a project cannot leave (last-admin protection).") unchanged.
22-24:⚠️ Potential issue | 🟡 MinorUse one plan name for Admin/custom-role availability.
This page uses
Enterprise Grid, whileoverview.mdusesEnterprisein the plan table. Please keep the entitlement label consistent across the new roles docs.Suggested change
-### Admin <Badge type="tip" text="Business" /> <Badge type="warning" text="Enterprise Grid" /> +### Admin <Badge type="tip" text="Business" /> <Badge type="warning" text="Enterprise" /> … -## Custom roles <Badge type="warning" text="Enterprise Grid" /> +## Custom roles <Badge type="warning" text="Enterprise" />Also applies to: 117-121
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/roles-and-permissions/member-roles.md` around lines 22 - 24, The docs use two different plan labels; replace the badge text "Enterprise Grid" with the consistent plan name used in overview (e.g., "Enterprise") across this file — update the Admin heading badge (the line containing "Admin <Badge type=\"tip\" text=\"Business\" /> <Badge type=\"warning\" text=\"Enterprise Grid\" />") and all other role badges/mentions (including the section around 117-121) so every badge.text and plain mention uses the same "Enterprise" entitlement label.
🤖 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/.vitepress/config.ts`:
- Around line 289-313: Unblock the commented sidebar group in
docs/.vitepress/config.ts so the "Roles and permissions" nav entry and its child
items become visible; specifically remove the block comment wrapping the object
whose text is "Roles and permissions" (and items linking to
"/roles-and-permissions/overview", "/roles-and-permissions/member-roles",
"/roles-and-permissions/permission-schemes",
"/roles-and-permissions/custom-roles",
"/roles-and-permissions/permissions-matrix") so those pages are reachable from
the hand-curated nav, and verify any new .md files under
docs/roles-and-permissions/ have corresponding links in that object.
In `@docs/roles-and-permissions/permissions-matrix.md`:
- Around line 255-260: The permissions matrix row for "Edit Issues" incorrectly
grants the Commenter role "+Creator", conflicting with member-roles.md which
states Commenters cannot create or edit work items; update the "Edit Issues"
cell for the Commenter column to "x" (or otherwise match the wording used in
member-roles.md) so both documents consistently show that Commenters cannot
create or edit work items, and double-check the "Create Issues" row also aligns
with member-roles.md for the Commenter role.
- Around line 542-562: The permissions summary table is out of sync with the
detailed tables—specifically reconcile the entries for Project Commenter
(currently "Edit and delete work items"), Project Contributor (mentions "project
assets"), Workspace Member ("wiki collections" and "Delete workspace drafts"),
and Project Guest ("View, edit, and delete intake items") so they match the
source tables; either remove these summary rows if those permissions don't exist
in the detailed tables or add/adjust the missing detailed table rows to reflect
these summary grants. Locate the matrix lines listing roles and permissions
(e.g., "Project Commenter", "Project Contributor", "Workspace Member", "Project
Guest") and update the summary text or the detailed tables until both are
consistent. Ensure all permission names exactly match the labels used elsewhere
(e.g., "Delete Issues", "project assets", "wiki collections", "workspace
drafts") to avoid future drift.
- Around line 144-154: The permissions matrix contradicts the explanatory note:
the rows "Edit Teamspaces", "Manage Teamspace Members", and "Delete Teamspaces"
currently mark Admin with ✓ but the note below states "Workspace Admin role
alone is not sufficient" and requires being the teamspace lead; update the
matrix to reflect the rule by changing the Admin cells for those three rows from
✓ to +Lead (or otherwise mark they require lead status) so the table and the
note are consistent, ensuring the entries "Edit Teamspaces", "Manage Teamspace
Members", and "Delete Teamspaces" explicitly indicate the lead requirement
rather than unconditional Admin permission.
---
Duplicate comments:
In `@docs/roles-and-permissions/member-roles.md`:
- Around line 108-115: Remove the sentence referencing an "internal authority
level" from the "## Role hierarchy" section and leave only the concrete,
actionable bullets; specifically edit the paragraph that says "Roles have an
internal authority level used to enforce who can manage whom. A user can only
modify members whose role level is lower than their own." so it is deleted or
replaced with a short lead-in that does not imply a hidden model, and keep the
four bullets ("Only Owners can manage other Owners.", "Owners and Admins can
manage Admins.", "The last Admin or Owner of a workspace cannot leave or be
demoted (last-admin protection).", "The last Admin of a project cannot leave
(last-admin protection).") unchanged.
- Around line 22-24: The docs use two different plan labels; replace the badge
text "Enterprise Grid" with the consistent plan name used in overview (e.g.,
"Enterprise") across this file — update the Admin heading badge (the line
containing "Admin <Badge type=\"tip\" text=\"Business\" /> <Badge
type=\"warning\" text=\"Enterprise Grid\" />") and all other role
badges/mentions (including the section around 117-121) so every badge.text and
plain mention uses the same "Enterprise" entitlement label.
In `@docs/roles-and-permissions/overview.md`:
- Around line 24-33: The fenced ASCII diagram block in overview.md is missing a
language tag which triggers markdownlint; update the opening fence for that
diagram block to specify the language "text" (i.e., change the triple backtick
that precedes the diagram to ```text) so the block starting with "Workspace" is
fenced as a text code block.
- Around line 49-55: Update the "What changed from earlier versions" section
(header "What changed from earlier versions") to accurately describe the current
role model rather than implying simple renames: remove "Two things" and instead
state that the roles now include Workspace Owner, Workspace Admin (if still
distinct per the plan table), Contributor (replaces Project Member), and
Commenter (replaces the previous guest view toggle), and explicitly explain the
mapping (e.g., "Project Member → Contributor" and "guest view toggle → Commenter
role") so the bullets match the plan table above and no roles are incorrectly
collapsed (do not drop Workspace Admin if the plan table still lists it). Ensure
the three bullets are corrected to reflect these mappings and that the language
clarifies the current behavior: Commenter grants view + comment permissions
rather than a toggle.
- Around line 16-19: Update the GAC paragraph to avoid implying per-resource
allow/deny is current shipped behavior: in the "Granular Access Control (GAC)"
section, change the language to explicitly mark per-resource grant/deny examples
as hypothetical or planned (e.g., "illustrative / planned behavior" or "in
future releases") and/or indicate current availability (what's supported today
and where to find controls). Remove definitive phrasing that a Contributor
"could be denied" on a specific project and replace with a clarifying sentence
such as "This describes planned/illustrative GAC capabilities; check the product
docs or release notes for current availability." Also update the examples to be
clearly labeled as illustrative scenarios rather than existing features.
In `@docs/roles-and-permissions/permissions-matrix.md`:
- Line 21: Update the introductory Owner note to match the actual tables by
removing the claim that the "Owner column is omitted" and instead state that the
Owner column is included and that Workspace Owner holds full-access (wildcard)
and is represented with ✓ in the tables; edit the sentence starting with
"**Owner has full access.** Workspace Owner holds a full-access wildcard..." so
it no longer says the Owner column is omitted and explicitly aligns with the
tables that include an `Owner` column.
🪄 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: be35b260-4229-40cf-960e-0d3731f22f70
📒 Files selected for processing (8)
docs/.vitepress/config.tsdocs/core-concepts/projects/manage-project-members.mddocs/core-concepts/workspaces/members.mddocs/roles-and-permissions/custom-roles.mddocs/roles-and-permissions/member-roles.mddocs/roles-and-permissions/overview.mddocs/roles-and-permissions/permission-schemes.mddocs/roles-and-permissions/permissions-matrix.md
✅ Files skipped from review due to trivial changes (2)
- docs/roles-and-permissions/custom-roles.md
- docs/roles-and-permissions/permission-schemes.md
🚧 Files skipped from review as they are similar to previous changes (2)
- docs/core-concepts/workspaces/members.md
- docs/core-concepts/projects/manage-project-members.md
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (4)
docs/roles-and-permissions/permissions-matrix.md (3)
21-21:⚠️ Potential issue | 🟡 MinorUpdate documentation to match actual table structure.
Line 21 states "The Owner column is omitted from individual tables," but the workspace permission tables below (starting at line 31) explicitly include an Owner column. This was flagged in previous reviews but appears unresolved.
📝 Suggested clarification
-**Owner has full access.** Workspace Owner holds a full-access wildcard and matches every permission in this document. The Owner column is omitted from individual tables and assumed ✓ throughout. +**Owner has full access.** Workspace Owner holds a full-access wildcard and matches every permission in this document. Workspace tables explicitly show the Owner column as ✓ throughout.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/roles-and-permissions/permissions-matrix.md` at line 21, Update the sentence "The Owner column is omitted from individual tables and assumed ✓ throughout." to accurately reflect the current tables by either removing that claim or changing it to state that the Owner column is explicitly present in the workspace permission tables; locate and edit the exact line containing that sentence ("The Owner column is omitted from individual tables...") in permissions-matrix.md so the prose matches the actual tables starting at line 31, ensuring consistency between the description and the tables.
144-154:⚠️ Potential issue | 🟠 MajorResolve teamspace permission contradiction.
The table shows workspace Admin with unconditional ✓ for "Edit Teamspaces," "Manage Teamspace Members," and "Delete Teamspaces" (lines 149-151), but the explanatory note (line 153) states "Workspace Admin role alone is not sufficient" and requires being the teamspace lead. This internal contradiction was flagged in a previous review but remains unresolved.
🔧 Recommended fix based on the note's intent
If the note is correct (Admin requires +Lead for these operations), update the table:
-| Edit Teamspaces | ✓ | ✓ | +Lead | x | -| Manage Teamspace Members | ✓ | ✓ | +Lead | x | -| Delete Teamspaces | ✓ | ✓ | +Lead | x | +| Edit Teamspaces | ✓ | +Lead | +Lead | x | +| Manage Teamspace Members | ✓ | +Lead | +Lead | x | +| Delete Teamspaces | ✓ | +Lead | +Lead | x |Alternatively, if Admin does have unconditional access, remove or revise the note at line 153.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/roles-and-permissions/permissions-matrix.md` around lines 144 - 154, The table and the explanatory note conflict: either change the three permission cells for "Edit Teamspaces", "Manage Teamspace Members", and "Delete Teamspaces" under the "Admin" column to "+Lead" (matching the note that "Workspace Admin role alone is not sufficient") or keep the "✓" values and edit the note to state that Workspace Admins can perform those actions unconditionally; update the rows "Edit Teamspaces", "Manage Teamspace Members", and "Delete Teamspaces" and/or the explanatory sentence mentioning "Workspace Admin role alone is not sufficient" to make the intended behavior for the Workspace Admin role consistent.
255-260:⚠️ Potential issue | 🟠 MajorFix Commenter edit permission inconsistency.
Line 259 grants Commenter "+Creator" access to "Edit Issues," but
docs/roles-and-permissions/member-roles.mdat line 74 explicitly states: "They cannot create or edit work items, modules, cycles, or pages." This was flagged in a previous review and remains unresolved.🔧 Proposed fix to align with member-roles.md
-| Edit Issues | ✓ | ✓ | +Creator | +Creator | +| Edit Issues | ✓ | ✓ | x | +Creator |Please verify this change is correct and also check line 347 "Edit Intake Items" for Commenter, as intake items may have different rules than regular issues.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/roles-and-permissions/permissions-matrix.md` around lines 255 - 260, The "Edit Issues" permission row in the permissions matrix incorrectly grants Commenter "+Creator"; update the "Edit Issues" cell for the Commenter column from "+Creator" to "x" to align with docs/roles-and-permissions/member-roles.md (which states Commenters cannot create or edit work items), and while you're editing the matrix also verify the "Edit Intake Items" row for the Commenter (the entry near line 347) to ensure intake-item rules don't differ and adjust that cell if necessary.docs/roles-and-permissions/overview.md (1)
24-33:⚠️ Potential issue | 🟡 MinorAdd language identifier to code block.
The fenced code block lacks a language identifier, triggering markdownlint rule MD040. Adding
textwill resolve the linting warning.🔧 Proposed fix
-``` +```text Workspace ├── Project │ ├── Work items, Epics, Modules, CyclesAs per coding guidelines, formatting checks should pass before merging.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/roles-and-permissions/overview.md` around lines 24 - 33, The fenced ASCII diagram code block in the markdown lacks a language identifier (triggering MD040); update the fenced code block in the Roles and Permissions overview (the triple-backtick block that begins with "Workspace" and the tree diagram) to include a language tag such as `text` (e.g., change ``` to ```text) so the markdown linter passes.
🧹 Nitpick comments (3)
docs/roles-and-permissions/overview.md (1)
10-10: Optional: Vary sentence structure for improved flow.Three consecutive sentences begin with "If you..." While grammatically correct, varying the opening can enhance readability.
♻️ Optional rewording
-If you're looking for what a specific role can or can't do, see the [Permissions matrix](/roles-and-permissions/permissions-matrix). If you want a list of system roles, see [Member roles](/roles-and-permissions/member-roles). If you want to perform a task, see the how-to guides linked at the bottom of this page. +For details on what a specific role can or can't do, see the [Permissions matrix](/roles-and-permissions/permissions-matrix). For a list of system roles, see [Member roles](/roles-and-permissions/member-roles). To perform a task, see the how-to guides linked at the bottom of this page.🤖 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 10, The three consecutive sentences "If you're looking for what a specific role...", "If you want a list of system roles...", and "If you want to perform a task..." should be rewritten to vary sentence openings for better flow; edit the paragraph to keep the same links and meaning but change one or two sentence starters (e.g., turn one into a statement like "See the Permissions matrix..." or use "For a list of system roles, consult..." and rephrase the third to "To perform a task, refer to...") so the phrasing is less repetitive while preserving links and intent.docs/roles-and-permissions/permissions-matrix.md (1)
8-8: Optional: Add hyphen to compound modifier.Consider "system-defined role" for clarity, though "system defined role" is acceptable.
-This is the exhaustive permissions reference for every system defined role in Plane. +This is the exhaustive permissions reference for every system-defined role in Plane.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/roles-and-permissions/permissions-matrix.md` at line 8, Update the sentence in permissions-matrix.md to use the hyphenated compound "system-defined role" instead of "system defined role"; locate the line containing the phrase "This is the exhaustive permissions reference for every system defined role in Plane." and change it to "This is the exhaustive permissions reference for every system-defined role in Plane." to apply the hyphenated modifier.docs/roles-and-permissions/member-roles.md (1)
56-56: Optional: Consider varying sentence structure.Three consecutive sentences begin with "Project Admins/Admin." While grammatically correct, varying the structure slightly can improve readability.
♻️ Optional rewording suggestion
-Project Admin has full control over the project — settings, members, work items, epics, cycles, modules, pages, views, intake, automations, workflows, labels, states, and estimates. Project Admins can also delete or archive the project itself. +Project Admin has full control over the project — settings, members, work items, epics, cycles, modules, pages, views, intake, automations, workflows, labels, states, and estimates. This role can also delete or archive the project itself.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/roles-and-permissions/member-roles.md` at line 56, The three consecutive sentences that begin with "Project Admin"/"Project Admins" should be rephrased for variety and readability: modify the sentence starting "Project Admin has full control over the project — settings, members, work items, epics, cycles, modules, pages, views, intake, automations, workflows, labels, states, and estimates." by either breaking the long list into a shorter sentence and using a different subject for the following sentence(s) (for example, "They can also delete or archive the project itself." or "Project Admins additionally have the ability to delete or archive the project.") or by combining parts into a single sentence that avoids repeating "Project Admins" at the start; ensure the meaning (full control and ability to delete/archive) is preserved while varying sentence openings.
🤖 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/permissions-matrix.md`:
- Around line 542-561: The summary table contains undefined permission names
("project assets", "wiki collections", "workspace drafts") and inconsistent
phrasing for Intake ("intake work items" vs "Intake Items"); either add
corresponding detailed permission sections (with the same canonical names) for
Project Assets, Wiki Collections, and Workspace Drafts, or remove those three
rows from the summary; also standardize the Intake terminology by changing
"intake work items" to "Intake Items" (or vice versa) so the summary matches the
detailed table exactly.
---
Duplicate comments:
In `@docs/roles-and-permissions/overview.md`:
- Around line 24-33: The fenced ASCII diagram code block in the markdown lacks a
language identifier (triggering MD040); update the fenced code block in the
Roles and Permissions overview (the triple-backtick block that begins with
"Workspace" and the tree diagram) to include a language tag such as `text`
(e.g., change ``` to ```text) so the markdown linter passes.
In `@docs/roles-and-permissions/permissions-matrix.md`:
- Line 21: Update the sentence "The Owner column is omitted from individual
tables and assumed ✓ throughout." to accurately reflect the current tables by
either removing that claim or changing it to state that the Owner column is
explicitly present in the workspace permission tables; locate and edit the exact
line containing that sentence ("The Owner column is omitted from individual
tables...") in permissions-matrix.md so the prose matches the actual tables
starting at line 31, ensuring consistency between the description and the
tables.
- Around line 144-154: The table and the explanatory note conflict: either
change the three permission cells for "Edit Teamspaces", "Manage Teamspace
Members", and "Delete Teamspaces" under the "Admin" column to "+Lead" (matching
the note that "Workspace Admin role alone is not sufficient") or keep the "✓"
values and edit the note to state that Workspace Admins can perform those
actions unconditionally; update the rows "Edit Teamspaces", "Manage Teamspace
Members", and "Delete Teamspaces" and/or the explanatory sentence mentioning
"Workspace Admin role alone is not sufficient" to make the intended behavior for
the Workspace Admin role consistent.
- Around line 255-260: The "Edit Issues" permission row in the permissions
matrix incorrectly grants Commenter "+Creator"; update the "Edit Issues" cell
for the Commenter column from "+Creator" to "x" to align with
docs/roles-and-permissions/member-roles.md (which states Commenters cannot
create or edit work items), and while you're editing the matrix also verify the
"Edit Intake Items" row for the Commenter (the entry near line 347) to ensure
intake-item rules don't differ and adjust that cell if necessary.
---
Nitpick comments:
In `@docs/roles-and-permissions/member-roles.md`:
- Line 56: The three consecutive sentences that begin with "Project
Admin"/"Project Admins" should be rephrased for variety and readability: modify
the sentence starting "Project Admin has full control over the project —
settings, members, work items, epics, cycles, modules, pages, views, intake,
automations, workflows, labels, states, and estimates." by either breaking the
long list into a shorter sentence and using a different subject for the
following sentence(s) (for example, "They can also delete or archive the project
itself." or "Project Admins additionally have the ability to delete or archive
the project.") or by combining parts into a single sentence that avoids
repeating "Project Admins" at the start; ensure the meaning (full control and
ability to delete/archive) is preserved while varying sentence openings.
In `@docs/roles-and-permissions/overview.md`:
- Line 10: The three consecutive sentences "If you're looking for what a
specific role...", "If you want a list of system roles...", and "If you want to
perform a task..." should be rewritten to vary sentence openings for better
flow; edit the paragraph to keep the same links and meaning but change one or
two sentence starters (e.g., turn one into a statement like "See the Permissions
matrix..." or use "For a list of system roles, consult..." and rephrase the
third to "To perform a task, refer to...") so the phrasing is less repetitive
while preserving links and intent.
In `@docs/roles-and-permissions/permissions-matrix.md`:
- Line 8: Update the sentence in permissions-matrix.md to use the hyphenated
compound "system-defined role" instead of "system defined role"; locate the line
containing the phrase "This is the exhaustive permissions reference for every
system defined role in Plane." and change it to "This is the exhaustive
permissions reference for every system-defined role in Plane." to apply the
hyphenated modifier.
🪄 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: f2a9b989-06c0-43b2-b181-2e0ed1c320c2
📒 Files selected for processing (6)
docs/.vitepress/config.tsdocs/roles-and-permissions/custom-roles.mddocs/roles-and-permissions/member-roles.mddocs/roles-and-permissions/overview.mddocs/roles-and-permissions/permission-schemes.mddocs/roles-and-permissions/permissions-matrix.md
✅ Files skipped from review due to trivial changes (2)
- docs/roles-and-permissions/custom-roles.md
- docs/roles-and-permissions/permission-schemes.md
🚧 Files skipped from review as they are similar to previous changes (1)
- docs/.vitepress/config.ts
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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/permissions-matrix.md`:
- Around line 25-540: There are two duplicated "## Workspace permissions"
sections and a separator block; remove the entire first block (the
feature-grouped tables starting at the earlier "## Workspace permissions"
through the "-----------------------------" line) so only the second,
role-builder-aligned "## Workspace permissions" section remains; delete the
duplicate heading and the long blank/separator (`-----------------------------`)
and ensure any internal references now point to the single remaining "##
Workspace permissions" tables (use the second section as canonical).
- Line 14: The heading "## Symbols used on this page`" contains a stray trailing
backtick; remove the backtick so the header reads "## Symbols used on this page"
(locate the heading string in permissions-matrix.md and delete the unmatched `
character).
🪄 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: 6bb10f66-dbc2-45bd-a8e1-4cc60cf67041
📒 Files selected for processing (3)
docs/.vitepress/config.tsdocs/roles-and-permissions/permissions-matrix.mdvercel.json
✅ Files skipped from review due to trivial changes (1)
- vercel.json
sriramveeraghanta
approved these changes
Apr 25, 2026
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/roles-and-permissions/permissions-matrix.md (1)
1-970:⚠️ Potential issue | 🟠 MajorFormatting check is failing in CI; run formatter before merge.
Pipeline already reports
oxfmt --checkfailure for this file. Please run the repo formatter and commit the result sopnpm check:formatpasses.As per coding guidelines
**/*: “Run pnpm fix:format before committing and ensure CI check via pnpm check:format passes; formatting is enforced”.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/roles-and-permissions/permissions-matrix.md` around lines 1 - 970, The Permissions matrix markdown ("title: Permissions matrix") is failing the formatting check (CI reports oxfmt --check); fix it by running the repo formatter (run pnpm fix:format or directly run the formatter used by CI), stage and commit the formatted changes to this document, then verify locally with pnpm check:format so the CI formatting check passes before merging.
🤖 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/permissions-matrix.md`:
- Around line 16-19: Legend and tables use inconsistent symbols (e.g., "x",
"+Creator", "—", "Own") causing ambiguity; pick one canonical notation (for
example: ✓, Own, Lead, x) and update the legend and every permissions table
entry to match it (replace occurrences of "+Creator" and "+Lead" with the chosen
"Own"/"Lead" tokens and replace "—" with the chosen unavailable token "x" or
vice versa), and ensure the legend lines (the block defining "✓",
"Own"/"+Creator", "Lead"/"+Lead", "x") exactly match the tokens used in the
tables (also update the other occurrences noted at lines 30-33 and 123-124).
- Line 8: Update the user-facing copy by hyphenating the compound adjective:
replace the phrase "system defined roles" with "system-defined roles" in the
document where the sentence "This is the exhaustive permissions reference for
every system defined role in Plane." appears so the heading/line reads "This is
the exhaustive permissions reference for every system-defined role in Plane."
- Around line 881-890: Remove the duplicated Teamspace intro block by keeping a
single copy of the blockquote and the explanatory sentence ("Workspace Owners
and Admins have full access to all teamspace content..." and "Workspace Guests
cannot be added to teamspaces." plus the following sentence about tables
applying to explicit teamspace members and Lead being a designation) and delete
the second repeated instance so the document contains only one introductory
paragraph for teamspace members.
---
Outside diff comments:
In `@docs/roles-and-permissions/permissions-matrix.md`:
- Around line 1-970: The Permissions matrix markdown ("title: Permissions
matrix") is failing the formatting check (CI reports oxfmt --check); fix it by
running the repo formatter (run pnpm fix:format or directly run the formatter
used by CI), stage and commit the formatted changes to this document, then
verify locally with pnpm check:format so the CI formatting check passes before
merging.
🪄 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: 222da278-0063-4e9f-9fc7-0366bfada2a3
📒 Files selected for processing (1)
docs/roles-and-permissions/permissions-matrix.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit
Documentation
Chores