## What kind of change does this PR introduce?
Feature. Resolves FE-3417.
## What is the current behavior?
Project Settings has a top-level `G then ,` shortcut, but its
subnavigation and repeated key/log drain actions do not have scoped
keyboard shortcuts or visible shortcut tooltips.
| Area | Current behaviour |
| --- | --- |
| Project Settings sidebar | Routes are click-only once users are inside
Settings. |
| API/JWT keys | Creation buttons do not expose keyboard shortcuts. |
| Log Drains | Add/save destination actions do not expose keyboard
shortcuts. |
## What is the new behavior?
Adds scoped Project Settings navigation chords, shortcut tooltips on the
sidebar rows, and page/action shortcuts for API keys, JWT standby keys,
and Log Drains.
| Area | New shortcut coverage |
| --- | --- |
| Project Settings sidebar | `S then G/C/I/N/W/K/J/L/A/D` for eligible
in-section routes. |
| API Keys | `Shift+P` and `Shift+S` open the publishable/secret key
dialogs; `Mod+Enter` submits the open dialog. |
| JWT Keys | `Shift+N` opens Create standby key; `Mod+Enter` submits the
open dialog. |
| Log Drains | `Shift+N` adds a destination when the primary action is
available; `Mod+Enter` saves the open destination sheet. |
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added keyboard shortcuts for Project Settings navigation and for
actions in API Keys, JWT Keys, and Log Drains (open, create/submit).
* **Improvements**
* Dialogs and forms now support keyboard-triggered open and submit
actions with improved enable/disable gating and updated settings menu
composition; shortcuts appear in the shortcuts reference.
* **Tests**
* Added tests covering shortcut wiring and shortcut-driven open/submit
behaviors across dialogs and action panels.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46352?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Ali Waseem <waseema393@gmail.com>
## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
## What kind of change does this PR introduce?
- Remove queue operations from feature preview into settings
- Refactor dashboard settings
- Resolves DEPR-434
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Dashboard settings panel in Account preferences with toggles for
Inline Editor and Queue Operations; “Dashboard” added to project
Configuration.
* **Removed**
* Old Inline Editor settings UI and the Queue Operations feature-preview
UI removed.
* **Refactor**
* Consolidated dashboard preferences into a single settings surface;
banners and actions now navigate to preferences; account/preferences
layouts and back-navigation behavior adjusted for platform vs
self-hosted.
* **Tests**
* Added tests for settings UI, menu generation, redirects, and
local-storage.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
Co-authored-by: Danny White <3104761+dnywh@users.noreply.github.com>
## What kind of change does this PR introduce?
Feature that resolves DEPR-321.
## What is the current behavior?
From @dshukertjr:
> Users of free and pro orgs frequently struggle to figure out how to
add teammates to a project.
## What is the new behavior?
Project Settings → General now has a Project access section showing who
can access the project (email + role), with a link to team management
(_Manage members_ or _View team_ for limited users). Large member lists
are truncated with +N more.
| Permutations |
| --- |
| <img width="1462" height="544" alt="CleanShot 2026-03-06 at 17 00
00@2x"
src="https://github.com/user-attachments/assets/68e5519f-3851-4ab8-a364-9fcb222fbcb7"
/> |
| <img width="1486" height="676" alt="CleanShot 2026-03-06 at 16 59
48@2x"
src="https://github.com/user-attachments/assets/e1b85bb5-6fbd-46ec-9b13-15501defd030"
/> |
| <img width="1464" height="566" alt="CleanShot 2026-03-06 at 16 59
34@2x"
src="https://github.com/user-attachments/assets/e9fdc188-cf79-4af9-8b3c-313e98256109"
/> |
| <img width="1438" height="654" alt="CleanShot 2026-03-06 at 17 11
25@2x-83D06149-E4AE-4AC0-98D9-FBBE10A58C8C"
src="https://github.com/user-attachments/assets/8a6e1aa2-76bb-486e-999a-1df4f88c3692"
/> |
## Additional context
Behaviour is based on user role visibility, not a special plan-only
toggle. Team+ orgs are more likely to hit limited/project-scoped cases;
free/pro are usually org-wide access.
## Context
Related to dashboard scalability
Previous PR: https://github.com/supabase/supabase/pull/42856
Note: Changes are all feature flagged still and I'm still not entirely
convinced with the current UX
Will iterate as as go along, and only make this publicly available when
we're satisfied with the behaviour
Adds a "Dashboard preference" section to the project settings
<img width="265" height="740" alt="image"
src="https://github.com/user-attachments/assets/6ce1aa19-26c2-47c6-a9c4-595137266631"
/>
In which users can then select which database they'd like to use for
read queries run from the dashboard
Note: Everything is local storage for now, but we'd need middleware
support if we want to make this setting persist for all users on the
project
<img width="791" height="434" alt="image"
src="https://github.com/user-attachments/assets/e651d6d9-fed4-4da4-b552-c9f93f8d46d3"
/>
Added a dialog as well to further explain what this implies
<img width="610" height="312" alt="image"
src="https://github.com/user-attachments/assets/0aa957af-cb51-476f-aa79-8948a7cbe5ae"
/>
## To test
- Choosing a replica in dashboard preferences will only affect the table
editor as thats the only place that's set up so far to use a replica for
read queries (I'll need to follow up for other parts of the dashboard in
subsequent PRs)
## What kind of change does this PR introduce?
Impending feature addition. Resolves DEPR-340.
## What is the current behavior?
We don’t have any platform webhook support.
## What is the new behavior?
This puts the scaffolding for platform webhooks **behind a feature
flag**. The content is currently UI-only (with mock data and a
[temporary tracking
file](8adadc61f5/apps/studio/components/interfaces/Platform/Webhooks/DEPR-340-backend-integration-tracker.md)).
Merging this in lets us work incrementally from here on.
