fix: hide provider and key action buttons based on RBAC permissions

[impoiler]

Summary

Improves RBAC enforcement across the configuration and providers UI by hiding action controls entirely when the user lacks the required permissions, rather than rendering them in a disabled state.

Changes

• The config layout now checks the current route to determine which RBAC resource to evaluate — APIKeys for /workspace/config/api-keys routes and Settings for all others, so users without API key access are not incorrectly blocked from other config pages.
• The "Add Provider" dropdown is now conditionally rendered only when the user has provider create access, instead of always rendering with a disabled state.
• The "Add new key" button in the model provider keys table is now hidden entirely when the user lacks update access, rather than being rendered as disabled.
• The per-row actions dropdown menu (Edit/Delete) in the model provider keys table is now hidden entirely when the user has neither update nor delete access.

Type of change

• Bug fix
• Feature
• Refactor
• Documentation
• Chore/CI

Affected areas

• Core (Go)
• Transports (HTTP)
• Providers/Integrations
• Plugins
• UI (React)
• Docs

How to test

1. Log in as a user with restricted RBAC permissions (no APIKeys view access, no provider create/update/delete access).
2. Navigate to /workspace/config/api-keys — the no-permission view should be shown.
3. Navigate to another config page — it should load normally.
4. Navigate to the Providers page — the "Add Provider" dropdown should not be visible.
5. Open a provider's key table — the "Add new key" button and the per-row actions menu should not be visible.
6. Log in as a user with full access and verify all controls appear and function as expected.

cd ui
pnpm i || npm i
pnpm build || npm run build

Screenshots/Recordings

If UI changes, add before/after screenshots or short clips.

Breaking changes

• Yes
• No

Related issues

Link related issues and discussions.

Security considerations

These changes tighten UI-level RBAC enforcement by ensuring that action controls are not rendered at all for unauthorized users, reducing the surface area for accidental or misleading interactions. Server-side authorization remains the authoritative enforcement layer.

Checklist

• I read docs/contributing/README.md and followed the guidelines
• I added/updated tests where appropriate
• I updated documentation where needed
• I verified builds succeed (Go and UI)
• I verified the CI pipeline passes locally if applicable

[coderabbitai]

📝 Walkthrough

Summary by CodeRabbit

• UI/UX Improvements
  • Configuration data loading is now optimized—loading only what's needed for your current configuration section
  • Provider and configuration management buttons are now intelligently displayed based on access level instead of showing disabled buttons, creating a cleaner interface

Walkthrough

Three workspace UI files now conditionally render elements based on RBAC permissions. The config layout route determines required access level from the current pathname and gates data fetching accordingly. The provider page hides the create dropdown when access is denied. The provider keys table hides add and row action controls when the user lacks corresponding permissions.

Changes

Permission-Based UI Rendering

Layer / File(s)	Summary
Config Route RBAC Gating ui/app/workspace/config/layout.tsx	Route derives pathname, determines if currently under /workspace/config/api-keys, selects requiredAccess accordingly, and gates both useGetCoreConfigQuery execution and NoPermissionView rendering.
Provider Creation and Imports ui/app/workspace/providers/page.tsx	Imports reordered; AddProviderDropdown now conditionally renders only when hasProviderCreateAccess is true, replacing unconditional render with disabled state.
Provider Keys Table Conditional Actions ui/app/workspace/providers/views/modelProviderKeysTableView.tsx	"Add new" button renders only when provider is non-keyless and user has update access; row dropdown menu renders only when user has update or delete permissions.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 Permission checks now gate the view,
No disabled buttons—just what's true.
Hide what users cannot touch,
Cleaner UI, oh so much!
Config, providers, all in sync,
RBAC flows without a blink. 🌟

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'fix: hide provider and key action buttons based on RBAC permissions' clearly and specifically summarizes the main changes, accurately reflecting the conditional rendering improvements across configuration and provider UI components.
Description check	✅ Passed	The PR description is comprehensive and well-structured, following the template with all major sections completed including summary, detailed changes, type of change, affected areas, testing steps, and security considerations.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch 05-07-fix_rbac_checks_for_model_provider_page

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

• Generate code and open pull requests
• Plan features and break down work
• Investigate incidents and troubleshoot customer tickets together
• Automate recurring tasks and respond to alerts with triggers
• Summarize progress and report instantly

Built for teams:

• Shared memory across your entire org—no repeating context
• Per-thread sandboxes to safely plan and execute work
• Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[impoiler]

• fix: remove 100-item upper limit on paginated teams query #3323
• feat: add MCPToolGroups RBAC resource and separate access control from MCPGateway #3319
• feat: add MCPLogs RBAC resource and enforce access control on MCP logs route and sidebar #3316
• fix: hide delete log button instead of disabling it when user lacks delete access #3314
• fix: hide provider and key action buttons based on RBAC permissions #3296 👈 (View in Graphite)
• feat: add granular RBAC checks for API keys, inference, metrics, and filter inaccessible sidebar items #3295
• dev

This stack of pull requests is managed by Graphite. Learn more about stacking.

[greptile-apps]

Confidence Score: 4/5

Safe to merge — the changes only affect UI rendering logic and introduce no new data mutations or server-side access paths.

The RBAC guard in the config layout correctly routes to different permission checks based on pathname, and the conditional rendering in the providers views is straightforward. The only issues are cosmetic: two disabled props that are now always false were left in after their enclosing conditions made them unreachable.

No files require special attention; the redundant disabled props in providers/page.tsx and modelProviderKeysTableView.tsx are worth cleaning up but have no runtime impact.

Important Files Changed

Filename	Overview
ui/app/workspace/config/layout.tsx	Adds route-aware RBAC check: uses APIKeys permission for api-keys routes and Settings permission for all other config sub-routes. The NoPermissionView always shows a generic "configuration" label regardless of which permission is missing.
ui/app/workspace/providers/page.tsx	Conditionally renders AddProviderDropdown only when hasProviderCreateAccess is true; the disabled prop passed to it is now always false and can be removed.
ui/app/workspace/providers/views/modelProviderKeysTableView.tsx	Hides Add-key button and per-row actions dropdown when user lacks the required permissions; the disabled prop on the Button is now redundant since it only renders when hasUpdateProviderAccess is true.

_{Reviews (1): Last reviewed commit: "fix: RBAc checks for model provider page" | Re-trigger Greptile}

[coderabbitai]

🧹 Nitpick comments (3)

ui/app/workspace/providers/views/modelProviderKeysTableView.tsx (2)

155-155: 💤 Low value

Clarify or remove the empty onClick handler.

The table row has an empty onClick handler (onClick={() => { }}). If this is intentional to prevent event bubbling or for future use, consider adding a comment. Otherwise, remove it for clarity.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@ui/app/workspace/providers/views/modelProviderKeysTableView.tsx` at line 155,
The table row contains an empty onClick handler (onClick={() => { }}) which is
ambiguous; either remove the handler entirely from the row element to avoid
needless no-op code, or replace it with a brief explanatory comment and a named
no-op function (e.g., rowClickPlaceholder) if it intentionally prevents event
bubbling or is reserved for future behavior; locate the row element in
modelProviderKeysTableView's render/JSX (the row with onClick={() => { }}) and
apply one of these changes so the intent is explicit.

---

109-120: ⚡ Quick win

Remove redundant disabled prop.

The "Add new key" button now renders only when hasUpdateProviderAccess is true, so the disabled={!hasUpdateProviderAccess} prop on line 111 will always evaluate to disabled={false} and can be removed.

♻️ Simplified code

 {!isKeyless && hasUpdateProviderAccess ? (
   <Button
-    disabled={!hasUpdateProviderAccess}
     data-testid="add-key-btn"
     onClick={() => {
       handleAddKey();
     }}
   >
     <PlusIcon className="h-4 w-4" />
     Add new {entityLabel}
   </Button>
 ) : null}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@ui/app/workspace/providers/views/modelProviderKeysTableView.tsx` around lines
109 - 120, The Button rendering includes a redundant disabled prop because the
conditional already ensures it only renders when hasUpdateProviderAccess is
true; remove the disabled={!hasUpdateProviderAccess} prop from the Button
component in modelProviderKeysTableView.tsx (the JSX block that references
isKeyless, hasUpdateProviderAccess, Button, handleAddKey, and entityLabel) so
the Button is rendered without the unnecessary disabled attribute.

ui/app/workspace/providers/page.tsx (1)

243-251: ⚡ Quick win

Remove redundant disabled prop.

Since AddProviderDropdown now renders only when hasProviderCreateAccess is true, the disabled={!hasProviderCreateAccess} prop on line 245 will always evaluate to disabled={false} and can be removed. The same applies to line 143 in the empty state.

♻️ Simplified code

 {hasProviderCreateAccess ? <div className="pb-4">
   <AddProviderDropdown
-    disabled={!hasProviderCreateAccess}
     existingInSidebar={existingInSidebarNames}
     knownProviders={knownProviders}
     onSelectKnownProvider={handleSelectKnownProvider}
     onAddCustomProvider={() => setShowCustomProviderSheet(true)}
   />
 </div> : null}

And similarly at line 142–149:

 <AddProviderDropdown
-  disabled={!hasProviderCreateAccess}
   existingInSidebar={existingInSidebarNames}
   knownProviders={knownProviders}
   onSelectKnownProvider={handleSelectKnownProvider}
   onAddCustomProvider={() => setShowCustomProviderSheet(true)}
   variant="empty"
 />

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@ui/app/workspace/providers/page.tsx` around lines 243 - 251, The
AddProviderDropdown is only rendered when hasProviderCreateAccess is true, so
remove the redundant disabled={!hasProviderCreateAccess} prop from the
AddProviderDropdown instances (the one in the provider list block and the one in
the empty state block); keep all other props (existingInSidebarNames,
knownProviders, onSelectKnownProvider, onAddCustomProvider which calls
setShowCustomProviderSheet) unchanged.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@ui/app/workspace/providers/page.tsx`:
- Around line 243-251: The AddProviderDropdown is only rendered when
hasProviderCreateAccess is true, so remove the redundant
disabled={!hasProviderCreateAccess} prop from the AddProviderDropdown instances
(the one in the provider list block and the one in the empty state block); keep
all other props (existingInSidebarNames, knownProviders, onSelectKnownProvider,
onAddCustomProvider which calls setShowCustomProviderSheet) unchanged.

In `@ui/app/workspace/providers/views/modelProviderKeysTableView.tsx`:
- Line 155: The table row contains an empty onClick handler (onClick={() => {
}}) which is ambiguous; either remove the handler entirely from the row element
to avoid needless no-op code, or replace it with a brief explanatory comment and
a named no-op function (e.g., rowClickPlaceholder) if it intentionally prevents
event bubbling or is reserved for future behavior; locate the row element in
modelProviderKeysTableView's render/JSX (the row with onClick={() => { }}) and
apply one of these changes so the intent is explicit.
- Around line 109-120: The Button rendering includes a redundant disabled prop
because the conditional already ensures it only renders when
hasUpdateProviderAccess is true; remove the disabled={!hasUpdateProviderAccess}
prop from the Button component in modelProviderKeysTableView.tsx (the JSX block
that references isKeyless, hasUpdateProviderAccess, Button, handleAddKey, and
entityLabel) so the Button is rendered without the unnecessary disabled
attribute.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 164b6794-ba9f-46ee-bbc2-eada2820d66d

📥 Commits

Reviewing files that changed from the base of the PR and between 641ad72 and 9585ac6.

📒 Files selected for processing (3)

• ui/app/workspace/config/layout.tsx
• ui/app/workspace/providers/page.tsx
• ui/app/workspace/providers/views/modelProviderKeysTableView.tsx

[akshaydeo]

Merge activity

• May 8, 11:29 AM UTC: A user started a stack merge that includes this pull request via Graphite.
• May 8, 11:30 AM UTC: @akshaydeo merged this pull request with Graphite.