fix(site): remove member-facing Models nav item - #28772
Conversation
d14539d to
f898b0b
Compare
f898b0b to
c22a5c3
Compare
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c22a5c36c0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
@codex review re: Preserve AI Navigation for organization model admins Not a real issue - the premise that org-scoped model admins have canViewSiteWideAISettings === false is incorrect. canViewSiteWideAISettings includes canAccessAnyChatModelConfig(permissions), which checks viewAnyChatModelConfig / createAnyChatModelConfig / etc. Despite living in the site-wide Permissions object, these are any_org: true authorization checks (site/permissions.json): "viewAnyChatModelConfig": {"object": {"resource_type": "chat_model_config", "any_org": true}, "action": "read"} Per the RBAC policy (coderd/rbac/policy.rego) and rbac.Object.AnyOrgOwner docs, an any_org check passes if the actor holds the permission in any single organization. So a user whose only model-management grant is org-scoped still gets canAccessAnyChatModelConfig === true → canViewSiteWideAISettings === true → canViewAISettings === true, and the Admin settings → AI entry renders for them. Their navbar path into /ai/settings is unchanged by this PR. The removed link's own gating confirms this: canViewModels = !canViewAISettings && ... meant the Models link never rendered for org model admins in the first place - they were already covered by the dropdown. The only users losing the entry point are plain members with zero model-config permissions, which is the intended behavior (they see available models in the chat model selector). Folding accessible-model orgs into the canViewAISettings gate would regress the original complaint by surfacing the Admin settings dropdown for every member of any org with models. re: Add Storybook Coverage for the removed Models entry Declining this one. The deleted stories existed solely to exercise the canViewModels prop, which this PR removes from NavbarView and MobileMenu entirely - after this change, "member with model access" is not a representable state at the component level, so there is no code path left for a story to cover. A negative assertion ("Models is absent") wouldn't guard a live invariant: the link isn't conditionally hidden, the code is deleted. Such a story only fails if someone deliberately reintroduces the feature (and would update the story anyway), or false-fails if an unrelated "Models" entry is legitimately added later. The "neighboring navigation stays available" concern is already covered: ForMember / Member render the exact member state with adminPermissions: {}, and the ForAdmin / OrgAdmin / Admin stories open the dropdown and mobile menu through real interactions via play functions. Any regression hiding unrelated entries would fail those existing stories and their snapshots. |
|
Codex Review: Didn't find any major issues. Bravo. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
Members with model access but no AI settings permissions got a dedicated top-level Models item in the navbar. The chat model selector already shows available models, so remove the dashboard entry point entirely. Also drops the per-organization chat models fan-out the navbar performed on every dashboard load.
c22a5c3 to
6a06cec
Compare
|
Pixel failure and changes are unrelated |
Members with model access but no AI settings permissions got a dedicated top-level Models item in the navbar. The chat model selector already shows which models are available, so this removes the dashboard entry point entirely.
Also drops the per-organization chat models fan-out the navbar performed on every dashboard load just to decide whether to render the link. Admins still reach the models page via Admin settings → AI.