[5578] fix(frontend): Restore the Remove action in the members row menu - #5584
[5578] fix(frontend): Restore the Remove action in the members row menu#5584mmabrouk wants to merge 1 commit into
Conversation
…ion (#5578) The members row menu returned null for non-RBAC-entitled EE orgs because every item was gated on canModifyRoles, which is hard-false without the RBAC entitlement. Member removal is not role modification: the backend gates DELETE /workspaces/{id}/users on org owner or owner/admin role. Add a canRemoveMembers gate mirroring that and use it for the Remove item and the menu's early return. Claude-Session: https://claude.ai/code/session_01Qitvc9dCiunLishsJYRzbp
|
@coderabbitai review |
dosubot
Bot
added
the
size:S
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughSummary by CodeRabbit
WalkthroughThe workspace permissions hook now exposes role-based member removal access. The workspace member actions menu uses this permission to determine whether the menu renders and whether the “Remove” action is available. ChangesWorkspace member removal
Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 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 |
✅ Action performedReview finished.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
web/oss/src/hooks/useWorkspacePermissions.ts (1)
35-50: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winAdd regression coverage for the new removal gate.
Cover an EE workspace without RBAC where owner/admin users can remove both pending invitations and accepted members, while other roles cannot. This guards the exact permission regression described by the PR objective.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 463efe07-d7f0-4076-b06f-0c9e1396ba92
📒 Files selected for processing (2)
web/oss/src/components/pages/settings/WorkspaceManage/cellRenderers.tsxweb/oss/src/hooks/useWorkspacePermissions.ts
|
fair point, but testing the hook directly means mocking the whole workspace + role state, so it's not a quick add. the flow itself is covered by the playwright acceptance test (members.spec.ts, "remove a pending member") which runs against the EE stage. that's actually the test that caught this regression in the first place. if this area bites again we'll add a colocated hook test as a follow-up. |
1 participant
On EE deployments whose organization does not have the RBAC entitlement, the "Remove" action never appears in a workspace member row's "..." menu — the menu renders empty (returns null), so owners and admins cannot remove members or revoke pending invitations from the UI. This is also what makes the
members.spec.tspending-member removal test time out waiting for the menu.Root cause
The row menu, including the Remove item and the menu's early return, was gated on
canModifyRoles. That flag is hard-false for EE orgs without the RBAC entitlement. But member removal is not role modification: the backend gatesDELETE /workspaces/{id}/userson being the org owner or having the owner/admin role (and allows all for non-entitled EE), so the frontend was strictly more restrictive than the API.Fix
Add a
canRemoveMembersgate inuseWorkspacePermissions(hasRole("owner") || hasRole("admin");hasRolealready returns true for org owners and for editions where RBAC is not active), mirroring the backend's check. The Remove item and the menu's early return now use it. The other items keep their existing gates: resend invitation stays oncanInviteMembers, role editing stays oncanModifyRoles.How to verify
Closes #5578
https://claude.ai/code/session_01Qitvc9dCiunLishsJYRzbp