fix(site): keep organizations out of the admin-settings gate - #27251
fix(site): keep organizations out of the admin-settings gate#27251jakehwll wants to merge 3 commits into
Conversation
…dmin menu Non-admin members no longer see the Admin settings dropdown just because they can view organizations. Organizations is not an admin setting, so it now lives in the user menu (desktop user dropdown and mobile user settings) for anyone who can view organizations, and the Admin settings menu is gated purely on genuine admin permissions. Fixes #26695
Organizations is no longer an item in the Admin settings menu, so the roles e2e no longer expects it there.
Documentation CheckThe approach in this PR was reworked. Organizations now stays under the Admin settings dropdown ( Because the Admin settings > Organizations navigation path is unchanged, the previously flagged doc updates are no longer needed. Updates Needed
No documentation changes are required for this PR. Automated review via Coder Agents |
aslilac
left a comment
There was a problem hiding this comment.
moving admin settings under the user dropdown for people who do actually have administrative abilities is not the right fix. we already rejected a pr that did basically this exact same thing. 😅
Non-admin members no longer see the Admin settings menu just because they can view organizations. canViewAdminSettings now ignores canViewOrganizations, and MobileMenu reuses it instead of its own inline check, so both desktop and mobile gate the menu on genuine admin permissions. Organizations remains an item in the menu for admins. Fixes #26695
|
Closing in favour of #27481 |
Fixes #26695
Problem
On a licensed/multi-org deployment, a regular member sees an Admin settings dropdown (containing Organizations) even though they are not an admin.
Root cause:
canViewAdminSettingssurfaced the menu when any permission was set, andcanViewOrganizationswas one of them. That flag is true for ordinary members (e.g.viewAnyMembers), so the menu appeared for non-admins.MobileMenuduplicated the same check inline.Change
Minimal gating fix, keeping Organizations where it already lives:
canViewAdminSettingsnow ignorescanViewOrganizationsand gates purely on genuine admin permissions (deployment, audit, connection log, AI, health).MobileMenureusescanViewAdminSettingsinstead of its own inlineObject.values(...).some(...), so desktop and mobile share one source of truth.getAdminSettingsItemsis unchanged: Organizations stays in the Admin settings menu and is shown whenever the menu is shown (i.e. the user has an admin permission).Net effect: members with only organization-view access no longer see the Admin settings menu; admins keep the menu with Organizations in it. Diff is 3 files.
Testing
pnpm lint:types,biome check, andknippass.adminSettings.test.ts:canViewAdminSettingsreturns false for organization access alone and true for a genuine admin permission;getAdminSettingsItemsalways lists Organizations.NavbarView/MobileMenustories and theroles.spec.tse2e (Organizations under Admin settings) continue to pass.Relationship to #26731
This is an alternative to community PR #26731, which fixed the same issue but introduced a
canView/canManageorganization split across ~22 files and relocated Organizations into the user menu. This PR keeps Organizations in the Admin settings menu and only corrects the gate, in ~3 files with no permission-model changes.