feat(site): hide workspace UI from users without workspace access - #28042
Draft
jscottmiller wants to merge 1 commit into
Draft
feat(site): hide workspace UI from users without workspace access#28042jscottmiller wants to merge 1 commit into
jscottmiller wants to merge 1 commit into
Conversation
Adds a site-wide `viewWorkspaces` permission check (workspace read, any org, owner me) and uses it to adapt the UI for users whose org member roles do not grant workspace access. - The dashboard index route lands these users on their account settings. - Workspaces, Templates, Tasks and Agents nav items render dimmed and non-interactive with a tooltip; the workspace proxy latency menu is hidden. - Schedule and SSH Keys are removed from the user settings sidebar and their routes redirect to the account page. - Workspace and Task notification groups are hidden. - The account name field drops the template property hint. Also adds a description for the organization-workspace-access role in the role selector.
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
1 participant
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.
Implements PLAT-460, points 1, 3, 4 and 5. The dismissible intro modal (point 2) is out of scope pending copy.
There is no server-side account type for these users. The signal is RBAC: an org member without
organization-workspace-accesshas no workspace permissions at all. This PR adds a site-wideviewWorkspacescheck (workspaceread, any org, ownerme) tosite/permissions.jsonand drives the UI from it. Read is used rather thancreateso that members withorganization-workspace-creation-bankeep the workspace UI.Behavior when
viewWorkspacesis false:/settings/accountinstead of/workspaces, and the navbar logo follows the same target.TODO(PLAT-460).data.coder_workspace_owner.me.full_namehint.The admin settings dropdown needs no change:
canViewAdminSettingsalready hides it for a plain org member.Also adds the missing
organization-workspace-accessentry to the role description map used by the role selector.Coverage is Storybook only, per the frontend guidelines:
WithoutWorkspaceAccessstories forNavbarView,MobileMenu,NotificationsPageandAccountForm, plus a newUserSettingsPage/Sidebarstory file.Not changed here:
/workspaces,/templates,/tasksand/agentsremain reachable by direct URL, since those pages already degrade to empty states. The pre-existing desktop and mobile nav divergence (mobile Agents is not gated bycreateChat, and mobile has no Tasks item) is also left alone.Implementation plan
PLAT-460: Improve UI for users without workspace access
Scope: frontend only (
site/) plus one sharedsite/permissions.jsonentry. Point 2 of the ticket (dismissible intro modal) is out of scope.Naming rule: do not use the term "gateway account" in code, comments, or UI strings. The behaviour is driven purely by the signed-in user's permission set, so identifiers read as
viewWorkspaces/canViewWorkspacesand comments describe the permission, not an account type.Current state
organization-workspace-access(codersdk/rbacroles.go:18,coderd/rbac/roles.go:716-729) grants the wholeworkspaceaction set; a member without it has no workspace permissions at all (coderd/rbac/roles.go:1138-1151).site/permissions.json, are evaluated server-side into page metadata (site/site.go:548-590), fetched viaAuthProviderand read throughuseAuthenticated().permissions.createWorkspaceis used, and only to hide "New workspace" / "Create Workspace" CTAs.Step 0: the signal
Use workspace read, not create: members with
organization-workspace-creation-banstill need the workspace UI.site/permissions.json: addviewWorkspaces.permissions.viewWorkspacesviauseAuthenticated(); pass it down ascanViewWorkspacesprops. No new context.site/src/testHelpers/entities.tspermission fixtures.Step 1: landing route (ticket 1)
Navigatewith a component that redirects to/settings/accountwhenviewWorkspacesis false./workspacesstays reachable; it already renders an empty state.data.coder_workspace_owner.me.full_namehelper text on the account page.Step 2: navbar (tickets 3 and 4)
ProxyMenuin desktop and mobile.canViewAdminSettingsalready hides it for a plain member.TODO(PLAT-460)marker.viewWorkspacesis false.Step 3: settings subnav (ticket 5)
Step 4: notifications (ticket 5.3)
canSeeNotificationGroupso "Workspace Events" and "Task Events" requireviewWorkspaces. Finer-grained per-template filtering would need new backend metadata.Step 5: tests
playfunctions asserting the dimmed nav items are non-interactive and expose the tooltip.Explicitly not in this plan
This pull request was created by Coder Agents on behalf of @jscottmiller.