## Problem
After deploying a new edge function where you actually modified the code
from the initial template, a dialog appears about unsaved changes.
## Solution
We must check that even though the files have changed from the initial
ones, we actually saved them by deploying the function.
However, because we trigger the navigation in the mutation `onSuccess`
side effect, it happens before react can update the state that would
prevent the dialog from appearing.
This PR fixes some prettier issues:
- Bump and unify all prettier versions to 3.7.3 across teh whole repo
- Bump the SQL prettier plugin
- When running `test:prettier`, check `mdx` files also
- Run the new prettier format on all files
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
## Summary
- MCP `getSecurityAdvisors` and `getPerformanceAdvisors` now pass
`exposedSchemas` to `getLints`, fixing empty advisor results in
local/self-hosted environments
- Extracts `DEFAULT_EXPOSED_SCHEMAS` constant shared between the MCP
handler and the `run-lints` API route (cc @joshenlim related
https://github.com/supabase/supabase/pull/40043)
- Adds unit tests for `enrichLintsQuery` and the MCP advisor operations
## The bug
The MCP advisor tools (`get_advisors`) return empty arrays (`[]`) for
**all** scenarios when running locally via `supabase start`. No security
or performance advisors are surfaced, even when the database has clear
issues (e.g., tables with no RLS).
### Root cause
In `lib/api/self-hosted/mcp.ts`, both `getSecurityAdvisors` and
`getPerformanceAdvisors` call `getLints({ headers })` **without passing
`exposedSchemas`**:
```typescript
// Before (mcp.ts:131)
const { data, error } = await getLints({ headers })
```
When `exposedSchemas` is `undefined`, `enrichLintsQuery` in `lints.ts`
skips the `SET LOCAL pgrst.db_schemas = '...'` SQL statement:
```typescript
// lints.ts:23
${!!exposedSchemas ? `set local pgrst.db_schemas = '${exposedSchemas}';` : ''}
```
Without this GUC being set, the splinter SQL queries filter results
using `current_setting('pgrst.db_schemas', 't')` — which returns an
empty string in local environments. Every schema-filtered lint matches
no schemas and returns zero rows.
### Why this only affects local/self-hosted environments
In **hosted Supabase**, PostgREST sets the `pgrst.db_schemas` GUC on its
own database connections based on the project's API configuration. The
Studio MCP server in production reads the same project configuration, so
the GUC is already available.
**Locally**, PostgREST runs in a separate Docker container and only sets
this GUC on _its own_ connections. Studio connects directly to
PostgreSQL (bypassing PostgREST), so
`current_setting('pgrst.db_schemas', 't')` returns `''`.
The HTTP API endpoint (`/api/platform/.../run-lints`) already worked
because `run-lints.ts` passes `exposedSchemas: 'public, storage'` — this
parameter was simply never added to the MCP code path.
## How we verified the fix
### 1. Tests written to fail against the previous code
We wrote two test files that target the exact bug:
**`tests/unit/lints/enrichLintsQuery.test.ts`** — validates the SQL
generation:
- Confirms `SET LOCAL pgrst.db_schemas` is included when
`exposedSchemas` is provided
- Confirms it's omitted when `undefined` or empty (documenting current
behavior)
**`tests/unit/lints/mcp-advisors.test.ts`** — validates the MCP
operations:
- Asserts `getSecurityAdvisors` passes `exposedSchemas` to `getLints`
- Asserts `getPerformanceAdvisors` passes `exposedSchemas` to `getLints`
- Asserts the value matches `DEFAULT_EXPOSED_SCHEMAS`
- Verifies SECURITY/PERFORMANCE category filtering still works
Before the fix, the two `exposedSchemas` assertions failed:
```
FAIL getSecurityAdvisors should pass exposedSchemas to getLints
→ expected { Object (headers) } to have property "exposedSchemas"
FAIL getPerformanceAdvisors should pass exposedSchemas to getLints
→ expected { Object (headers) } to have property "exposedSchemas"
```
### 2. Fix applied, all tests pass
After adding `exposedSchemas: DEFAULT_EXPOSED_SCHEMAS` to both MCP
operations, all 14 tests pass (9 new + 5 existing MCP tests).
## Test plan
run `supabase start`, create a table without RLS, call `get_advisors`
via MCP — should return `rls_disabled_in_public` lint
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
## Context
Just a nit change to float the status code from status page API into
incident-status endpoint so its clearer what the error is from the
network tab
---------
Co-authored-by: Charis Lam <26616127+charislam@users.noreply.github.com>
## What kind of change does this PR introduce?
Bug fix.
## What is the current behavior?
The file storage routes under `/project/[ref]/storage/files` all use
`Storage | Project | Org | Supabase` as the browser title, even when the
user is on a more specific tab.
## What is the new behavior?
The browser title now reflects the active file-storage tab:
- `/storage/files` -> `Files | Storage | Project | Org | Supabase`
- `/storage/files/settings` -> `Settings | Storage | Project | Org |
Supabase`
- `/storage/files/policies` -> `Policies | Storage | Project | Org |
Supabase`
Ditto for `analytics` and `vector`
## What kind of change does this PR introduce?
Refactor, cleanup, and docs update.
## What is the current behavior?
After the page-title rollout, `ProjectLayout` is still in a transitional
state:
- it accepts a deprecated `title` prop
- it still supports a separate `browserTitle.surface`
- wrapper layouts are split between passing `title` directly and passing
`browserTitle.section`
That makes the API harder to reason about than it needs to be, even
though the rendered titles are already correct.
## What is the new behavior?
This cleanup finishes the API simplification that came out of the
stacked PR review:
- wrapper layouts stay `title`-first for DX
- `ProjectLayout` no longer accepts `title`
- `product` is now the single source of truth for the project-surface
title segment
- `browserTitle` is now only used for extra browser-title metadata
(`entity`, `section`, `override`)
- the remaining project-scoped callers now pass `browserTitle.section`
when they need a section label
- docs now reflect the final pattern instead of the transitional one
Rendered page titles stay the same.
## Additional context
Checks run:
- `pnpm --filter studio exec vitest --run lib/page-title.test.ts
components/layouts/ProjectLayout/index.test.tsx`
- `pnpm --filter studio typecheck`
- `pnpm exec prettier --check ...` on touched files
This is intended as the post-rollout cleanup PR based on Joshen's review
feedback across the stacked title changes.
---------
Co-authored-by: Joshen Lim <joshenlimek@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?
This introduces Query Insights. It's the first edition of possible
future updates. This takes our old prototype and builds upon it for a
more action driven insights view.
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Ali Waseem <waseema393@gmail.com>
### Summary
This PR adds a dismissable modal that prompts paid org users to fill in
their billing address. We need billing addresses for tax compliance and
the existing banner hasn't been as effective (~10k orgs still missing).
The modal shows on page load when all of these are true:
- ConfigCat flag `enableBillingAddressModal` is on
- Org is on a paid plan (not free)
- Org does not have billing address set
- Org is not partner-managed
- User has BILLING_WRITE permission on stripe.customer
The modal can be dismissed via the close button, but re-opens on every
page navigation.
Once the user saves a valid address, the organizations query is
invalidated and organization_missing_address flips to false - the modal
stops appearing permanently.
<img width="1256" height="703" alt="Screenshot 2026-03-05 at 4 22 11 PM"
src="https://github.com/user-attachments/assets/57e7d1b8-b3b6-4366-ad23-60910a0defe8"
/>
### Testing
#### Automated Tests
I've added unit tests in this PR
#### Manual testing
Manual test cases:
- Free org - modal does not appear
- Partner-managed org - modal does not appear
- User with "developer role" modal does not appear
- Configcat Flag disabled - modal does not appear
- Dismiss modal, navigate to another page - modal re-opens
- Fill form and save - modal closes and does not reappear
- API failure loading billing data - shows error state with Retry button
---------
Co-authored-by: Ignacio Dobronich <ignacio@dobronich.com>
Stacked PR 5/5 for page title improvements. Includes /new and
/new/[slug] title updates plus navigation docs note.
_Base:
[dnywh/feat/page-titles](https://github.com/supabase/supabase/pull/43538)_
---
## What kind of change does this PR introduce?
- Resolves FE-1960
- Resolves FE-1983
- Resolves DEPR-207
## What is the current behavior?
Page titles between surfaces are inconsistent and vague. Sometimes they
say the product name:
```
My Project | My Org | Supabase
```
...even when on a specific surface like Database > Tables.
Other times they show the entity name but skip over the project or org
name :
```
Edge Functions | Supabase
```
## What is the new behavior?
Includes /new and /new/[slug] title updates plus navigation docs note.
Adopts the layout title format introduced in
https://github.com/supabase/supabase/pull/43538:
```
users | Table Editor | My Project | My Org | Supabase
hello-world | Logs | Edge Functions | My Project | My Org | Supabase
Backups | Database | My Project | My Org | Supabase
Authentication | My Project | My Org | Supabase
```
That format is:
entity, section, surface, project, org, brand
## Additional context
Related stacked PRs also based on the the original
[dnywh/feat/page-titles](https://github.com/supabase/supabase/pull/43538)
branch:
- https://github.com/supabase/supabase/pull/43534
- https://github.com/supabase/supabase/pull/43535
- https://github.com/supabase/supabase/pull/43536
Stacked PR 4/5 for page title improvements. Includes account and
organization-level title updates plus organization list/selector page
titles.
_Base:
[dnywh/feat/page-titles](https://github.com/supabase/supabase/pull/43538)_
---
## What kind of change does this PR introduce?
- Resolves FE-1960
- Resolves FE-1983
- Resolves DEPR-207
## What is the current behavior?
Page titles between surfaces are inconsistent and vague. Sometimes they
say the product name:
```
My Project | My Org | Supabase
```
...even when on a specific surface like Database > Tables.
Other times they show the entity name but skip over the project or org
name :
```
Edge Functions | Supabase
```
## What is the new behavior?
Account and organization-level title updates plus organization
list/selector page titles, adopting the layout title format introduced
in https://github.com/supabase/supabase/pull/43538:
```
users | Table Editor | My Project | My Org | Supabase
hello-world | Logs | Edge Functions | My Project | My Org | Supabase
Backups | Database | My Project | My Org | Supabase
Authentication | My Project | My Org | Supabase
```
That format is:
entity, section, surface, project, org, brand
## Additional context
Related stacked PRs also based on the the original
[dnywh/feat/page-titles](https://github.com/supabase/supabase/pull/43538)
branch:
- https://github.com/supabase/supabase/pull/43534
- https://github.com/supabase/supabase/pull/43535
- https://github.com/supabase/supabase/pull/43537
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
Feature
## What is the current behavior?
Incident banner logic depends on StatusPage and Supabase project for
metadata.
## What is the new behavior?
New incident banner logic that depends only on incident.io. Displays in
non-production environments for now because I haven't wired up the rest
of the workflow. This is just to allow a total end-to-end
testing/playground for test incidents <-> Slack <-> preview dashboard
for people to try out the UX.
## Additional context
You can test using my [test
incident](https://app.incident.io/supabase/incidents/405). This has
severity minor, so the preview site should have a banner. Toggle to
informative, hard refresh dashboard with cache off, and banner should
disappear. Toggle back to minor, hard refresh without cache again, and
banner should reappear. Same thing if you edit the "Banner shown" field
from 1 to -1 and back.
## 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?
- Bring back the old home page for self hosted, because the new one does
not work for self hosted users
- Unit tests to catch this in the future
## 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)
Stacked PR 3/5 for page title improvements. Includes Logs and
Observability layout title adoption, unified logs title cleanup, and
small route title fixes.
_Base:
[dnywh/feat/page-titles](https://github.com/supabase/supabase/pull/43538)_
---
## What kind of change does this PR introduce?
- Resolves FE-1960
- Resolves FE-1983
- Resolves DEPR-207
## What is the current behavior?
Page titles between surfaces are inconsistent and vague. Sometimes they
say the product name:
```
My Project | My Org | Supabase
```
...even when on a specific surface like Database > Tables.
Other times they show the entity name but skip over the project or org
name :
```
Edge Functions | Supabase
```
## What is the new behavior?
Logs and Observability adopts the layout title format introduced in
https://github.com/supabase/supabase/pull/43538:
```
users | Table Editor | My Project | My Org | Supabase
hello-world | Logs | Edge Functions | My Project | My Org | Supabase
Backups | Database | My Project | My Org | Supabase
Authentication | My Project | My Org | Supabase
```
That format is:
entity, section, surface, project, org, brand.
Also includes unified logs title cleanup, and small route title fixes.
## Additional context
Related stacked PRs also based on the the original
[dnywh/feat/page-titles](https://github.com/supabase/supabase/pull/43538)
branch:
- https://github.com/supabase/supabase/pull/43534
- https://github.com/supabase/supabase/pull/43536
- https://github.com/supabase/supabase/pull/43537
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
## Changes
- Replaces plan ID-based chart gating with entitlement-based checks
across all observability pages (database, auth, realtime,
edge-functions)
- Adds requiredPlan display field so the upsell shows the correct target
plan (e.g. "Upgrade to Team" for disk throughput, not just "Upgrade")
- Decouples database-charts.ts from Organization Plan, now accepts
pre-computed entitlement flags instead
### Note on `requiredPlan`
The entitlement system currently tells us whether a user has access, but
not what plan they need to get access. `requiredPlan` is a frontend-only
display hint. Ideally the backend entitlement response would include a
minimumPlan field so we can remove this hardcoded mapping. For now, this
is a pragmatic workaround to avoid misleading upsell copy (e.g. a Free
user seeing "Upgrade" for a Team-only feature and landing on Pro).
## Testing
### Database
- Head to `/project/_/observability/database` with an Org on the Free
Plan and assert that the Disk throughput is gated.
<img width="1402" height="682" alt="image"
src="https://github.com/user-attachments/assets/b783d866-774d-44dc-88d1-797d26502f02"
/>
### Auth
- Head to `/project/_/observability/auth` with an Org on the Free Plan
and assert that the following metrics are gated:
<img width="1402" height="682" alt="image"
src="https://github.com/user-attachments/assets/cb062dd7-5864-4e40-a11f-ad6be1f7fd41"
/>
### Edge Functions
- Head to `/project/_/observability/edge-functions` with an Org on the
Free Plan and assert that the following metrics are gated:
<img width="1402" height="320" alt="image"
src="https://github.com/user-attachments/assets/517b5483-4575-493c-9401-2c67ac9e684c"
/>
### Realtime
- Head to `/project/_/observability/realtime` with an Org on the Free
Plan and assert that the following metrics are gated:
<img width="1402" height="722" alt="image"
src="https://github.com/user-attachments/assets/0c2757a2-8482-43f4-a65c-c0dde3d878c7"
/>
New feature — adds a platform-only API endpoint to Studio.
## What is the current behavior?
`NEXT_PUBLIC_ONGOING_INCIDENT` is not exposed outside of the dashboard.
## What is the new behavior?
`GET /api/status-override` returns `{ enabled: boolean }` indicating
whether `NEXT_PUBLIC_ONGOING_INCIDENT` is set to `"true"`. The endpoint
returns 404 on self-hosted and is added to the proxy allowlist for
hosted platform access.
This is so that the incident banner bot can detect whether an override
is in place.
## Context
Initial ground work for Marketplace Integrations (feature flagged under
the flag `marketplaceIntegrations`), in which some integrations will be
fetched over a network request (than hard-coded within the repo).
Feature flag just controls whether to we need to fetch them.
Similarly, categories under "Explore" will also be fetched, and the flag
just decides whether that should be enabled.
We're also planning to update the overview tab for integrations as well,
in which integrations fetched over the network request will use the new
UI (altho not functional just yet)
## To test
Note that the LOC changes are seemingly large, but that's just because
I've added in a types file for the Supabase project that we're using to
store the integrations data
- [x] Verify that behaviour is status quo with the flag off (Priority)
- [x] Verify that behaviour is status quo on CLI / self-host env
- [x] Verify that with the flag on you'll see one of the new
integrations fetched over network (Grafana), including an additional
category "Observability" (and clicking into it will show the new UI)
- [x] Verify that all other existing integrations are status quo
---------
Co-authored-by: Katerina Skroumpelou <sk.katherine@gmail.com>
Stacked PR 2/5 for page title improvements. Includes Auth, Database,
editors, and Edge Functions layout title adoption.
_Base:
[dnywh/feat/page-titles](https://github.com/supabase/supabase/pull/43538)_
---
## What kind of change does this PR introduce?
- Resolves FE-1960
- Resolves FE-1983
- Resolves DEPR-207
## What is the current behavior?
Page titles between surfaces are inconsistent and vague. Sometimes they
say the product name:
```
My Project | My Org | Supabase
```
...even when on a specific surface like Database > Tables.
Other times they show the entity name but skip over the project or org
name :
```
Edge Functions | Supabase
```
## What is the new behavior?
Auth, Database, editors, and Edge Functions adopt the layout title
format introduced in https://github.com/supabase/supabase/pull/43538:
```
users | Table Editor | My Project | My Org | Supabase
hello-world | Logs | Edge Functions | My Project | My Org | Supabase
Backups | Database | My Project | My Org | Supabase
Authentication | My Project | My Org | Supabase
```
That format is:
entity, section, surface, project, org, brand
## Additional context
Related stacked PRs also based on the the original
[dnywh/feat/page-titles](https://github.com/supabase/supabase/pull/43538)
branch:
- https://github.com/supabase/supabase/pull/43535
- https://github.com/supabase/supabase/pull/43536
- https://github.com/supabase/supabase/pull/43537
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
## Problem
When editing email templates or edge functions, users may navigate away
from the page without a warning indicating they may loose their changes.
This is because we only handle the `beforeunload` event when we should
also handle NextJS routing events.
This is actually done for the observability reports.
## Solution
Extract the logic from the observability reports into a reusable
component and use it where needed
## How to test
On staging, for each case:
- Authentication email templates
- Observability reports
- Edge functions creation
- Edge functions edition
Test:
- Modify the template/report/function
- Navigate away using either the sidebar link, the browser back button
or closing the tab
- Cancel navigation in the confirmation dialog
- Navigation should be prevented and you should not loose your changes
Test:
- Modify the template/report/function
- Navigate away using either the sidebar link, the browser back button
or closing the tab
- Confirm navigation in the confirmation dialog
- Navigation should not be prevented and you should have lost your
changes
## Summary
The `homeNew` PostHog experiment has concluded. This PR graduates it by
making the new homepage (`ProjectHome`, formerly `HomeV2`) the permanent
default for all users, and removes all dead code from the old
experiment.
## Changes
- Remove `homeNew` PostHog feature flag checks and `home_new` experiment
exposure tracking from 3 files
- Rename `HomeNew/` → `ProjectHome/` directory and `HomeV2` →
`ProjectHome` export
- Delete old `Home/Home.tsx` component (shared components like
`ProjectList/` are kept — still used by org pages)
- Delete `pages/project/[ref]/building.tsx` and add a server-side
redirect from `/project/:ref/building` → `/project/:ref` to prevent 404s
during rollout (old cached JS bundles may still route to `/building`)
- Simplify `ContentWrapper` building-state logic in `ProjectLayout` —
always redirect building projects to home, always suppress building
interstitial on home page
- Always route to `/project/{ref}` after project creation (remove
`/building` path)
- Update all Observability imports from `HomeNew` → `ProjectHome`
## Self-hosted behavior change
Self-hosted Studio previously showed the old `Home` component (client
libraries + example projects) since PostHog flags don't load. This PR
changes self-hosted to show `ProjectHome` (TopSection with service
status + instance diagram, advisor, custom reports). All sections query
backend APIs that exist on self-hosted. E2E tests pass against the
self-hosted build.
## Testing
- [x] `pnpm turbo run build --filter=studio` passes
- [x] No remaining references to `homeNew`, `home_new`, or `HomeNew` in
codebase
- [x] No broken imports to deleted files
- [x] Self-hosted E2E tests pass (145 passed, 1 flaky, 4 skipped)
- [x] `/building` redirect added to both platform and self-hosted config
blocks
**Quick test:**
1. Navigate to any project homepage — should render the ProjectHome
component
2. Create a new project — should redirect to `/project/{ref}` (not
`/building`)
3. Visit a project in `COMING_UP` state on a non-home route — should
redirect to home
4. Visit `/project/{ref}/building` directly — should 302 redirect to
`/project/{ref}`
## Linear
- fixes GROWTH-671
Bug fix
## What is the current behavior?
Read-only users cannot download files because the download feature
requires minting a temporary API key, which is properly blocked for
read-only users.
## What is the new behavior?
Instead of using temporary API keys, we now create signed URLs for the
files to be downloaded. We batch-create signed URLs for an entire
folder's worth of files, requiring only a single management API call,
then use those signed URLs to download the files. This allows read-only
users to download files without needing elevated permissions.
## Additional context
Resolves FE-2737
## 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?
This introduces a small snippet preview of the error code coming via our
content API for the docs. This appears in a couple of places right now.
- **Auth Overview** - This page isn't fully released yet, but it appears
on the error codes table (as depicted below).
- **Logs** - When you delve into the logs panel, if there's an error
code available, they're also wrapped in this popover.
We are also working on a shared-data package (#43458) to potentially
replace this endpoint internally. Also introduces a multifaceted button
to debug/fix with either Assistant or LLM of choice.
| Auth Overview | Logs Panel |
|--------|--------|
| <img width="407" height="287" alt="Screenshot 2026-03-09 at 14 14 09"
src="https://github.com/user-attachments/assets/7450dddb-6828-4cd3-802d-37d47ba1b440"
/> | <img width="394" height="216" alt="Screenshot 2026-03-09 at 14 13
56"
src="https://github.com/user-attachments/assets/80c2a46e-dbe4-4e88-a0a7-68b977a71d6b"
/> |
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Problem
The `projectCreationEnableRlsEventTrigger` A/B experiment tested showing
an opt-in "Enable automatic RLS" checkbox in the project creation flow,
which sets up a Postgres event trigger to auto-enable RLS on every new
table in the public schema. The test variant passed with a +3.3pp lift.
## Changes
- `SecurityOptions.tsx` — removed PostHog flag check, checkbox is now
always rendered
- `pages/new/[slug].tsx` — removed experiment flag reads, exposure
tracking (`useTrackExperimentExposure`), and the conditional
`rlsOptionVariant` telemetry property
The underlying feature logic (`enableRlsEventTrigger` form field,
`AUTO_ENABLE_RLS_EVENT_TRIGGER_SQL`, submission handling) is unchanged —
we're just removing the scaffolding that was gating it.
## Testing
Verified `pnpm typecheck` passes clean. The "Enable automatic RLS"
checkbox now shows unconditionally in the Security Options section of
project creation.
GROWTH-653
## Context
Taking a slightly different approach to [this
PR](https://github.com/supabase/supabase/pull/43370)
Original problem was that if you opened some folders while in a bucket
and then switched to a different bucket, the folder UI will persists
(folders from Bucket A will render when landing on Bucket B)
## Changes involved
- Shift `StorageExplorerStateContextProvider` into `[bucketId].tsx]`
instead of `ProjectContext`
- The valtio store here only applies for the storage explorer so having
it so high in the project's context was unnecessary
- This also just implies that the valtio store will automatically reset
whenever the bucket changes
- Simplify storage explorer valtio store by initializing the store with
the bucket
- We'll initialize the selected bucket with the store now (Same as
previous PR)
- Removes unnecessary `setSelectedBucket` method which required a
separate `useEffect` in `StorageExplorer.tsx`
## To test
- [ ] Verify that the original is resolved
- [ ] General smoke test of the storage explorer - i've also re-added
the e2e test that Gildas wrote up in his PR
Allows users to select logs and copy their contents for debugging, or
pass them on to assistant with one click.
## To test
- go to logs or log explorer
- select some logs
- try copying as json, markdown, or sending it to assistant.
Adds the new `dedicated_pooler` entitlement and it's respective
entitlement checks in the following components: `ConnectTabContent`,
`ConnectStepsSection`, `LogsSidebarMenuV2` and `ConnectionPooling`
## Testing
### ConnectTabContent and ConnectStepsSection
- Head to `project/_?showConnect=true` with an Org on the Pro Plan or
above
- Assert that the `Dedicated Pooler` option is available.
<img width="1007" height="641" alt="image"
src="https://github.com/user-attachments/assets/b4891544-b84b-4745-9e25-4cbc7c76686c"
/>
### IPv4SidePanel
- Head to `/project/_/database/settings` with an Org on the Pro Plan and
above and assert that the Dedicated Pooler is available
<img width="889" height="562" alt="image"
src="https://github.com/user-attachments/assets/3150cb3d-18e9-4b34-bc9b-2589d0a33c5f"
/>
### Dedicated Pooler Logs
- Head to `/project/_/logs/dedicated-pooler-logs` with an Org on the Pro
Plan and assert that you are in the `dedicated-poolers-logs` page.
- Head to `/project/_/logs/dedicated-pooler-logs` with an Org on the
Free Plan and assert that you are redirected to `/logs/pooler-logs`
### Logs Sidebar
- Head to `/project/jdvjfujajfyywbaaakje/logs/explorer` with an Org on
the Free Plan
- Assert that only the "Poolers" collection is shown
- Head to `/project/jdvjfujajfyywbaaakje/logs/explorer` with an Org on
the Pro Plan
- Assert that the Dedicated and Shared Poolers collections are shown
<img width="251" height="774" alt="image"
src="https://github.com/user-attachments/assets/747bceee-d5e7-4a8f-911d-6b02cdb115eb"
/>
## 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?
- For the new filters experience, we are missing null changes for dates
and also no support for isNull
- Updated E2E tests to account for new null cases
## Context
Just cleaning up the `unifiedReplication` feature flag now that this is
fully rolled out
Also addresses some bugs that I came across while cleaning up,
specifically for the new home page
- Add enabled features flag check for read replicas in database
replication
- Infra diagram, read replicas
- View connection string CTA to open connect UI with the right database
selected
- Replaced all other actions with a "Manage replica" CTA which links to
the replica details page
## Context
Follow up from https://github.com/supabase/supabase/pull/43329, but
mutually exclusive
Just cleaning up feature flags that have been toggled on for all users
and unchanged for the past 2 months
- edgefunctionreport
- storagereport
- realtimeReport
- postgrestreport
- authreportv2
- newEdgeFunctionOverviewCharts
- apiReportCountries (Already not used)
- SentryLogDrain
- reportGranularityV2
- storageAnalyticsVector
- ShowIndexAdvisorOnTableEditor
## Context
Just cleaning up feature flags that have been toggled on for all users
and unchanged for the past 2 months
- advisorRules
- newJwtSecrets
- isWorkOSTPAEnabled
- EnableOAuth21
- gitlessBranching
- showRefreshToast
- awsPrivateLinkIntegration
- useBedrockAssistant (Already not used)
- enableStripeSyncEngineIntegration
- ShowExplainWithAiInQueryPerformance
Doing it in 2 parts so its easier for review
## What kind of change does this PR introduce?
UI change
## What is the current behavior?
Organization settings are currently spread across a NavMenu. This is
getting unweildy as the amount of children within Organization settings
grows.
## What is the new behavior?
Organization settings are now on a sidebar, just like Project Settings
and most other surfaces.
| Before | After |
| --- | --- |
| <img width="1024" height="563" alt="Supabase"
src="https://github.com/user-attachments/assets/3889858c-157a-4deb-8714-71fe9cf002e6"
/> | <img width="1024" height="563" alt="General Supabase"
src="https://github.com/user-attachments/assets/1b4eb2c3-a67c-4eda-ab3c-e6610dd5ccf4"
/> |
## Additional context
@fsansalvadore and the design team have have other efforts going on to
reduce interface clutter, e.g. nested sidebars.
## What kind of change does this PR introduce?
UI update
## What is the current behavior?
- Database settings uses an older, much wider, layout
- This will become problematic later on as more complex elements are
added to the page
- Titles and descriptions are inconsistently formatted
## What is the new behavior?
| Before | After |
| --- | --- |
| <img width="1728" height="994" alt="Oldie 2 Toolshed
Supabase-EE998752-3696-45E4-A842-9666049153D8"
src="https://github.com/user-attachments/assets/8f0004cf-3bb4-4b00-900a-b116b80371a6"
/> | <img width="1728" height="994" alt="Oldie 2 Toolshed
Supabase-7E86FD58-35BB-4912-8B2F-8C7AAA03B462"
src="https://github.com/user-attachments/assets/606b51b4-21a0-4b7b-870b-ac92ed363f3c"
/> |
Feature enhancement — smarter incident banner targeting logic
## What is the current behavior?
Displaying the incident banner requires toggling a flag or environment
variable. Banners are shown to all users regardless of whether their
projects are in affected regions or whether the incident affects project
creation.
## What is the new behavior?
Banner visibility is now driven by `show_banner` metadata from the
StatusPage API — no manual flag or env var toggle needed. Per-user
targeting is then applied:
- Users with projects only see the banner when they have a database in
an affected region
- Users without projects only see the banner when the incident affects
project creation
Incident responses are enriched with cache data (`affected_regions`,
`affects_project_creation`) fetched from a Supabase table. Visibility
logic is extracted into a dedicated hook and pure utility function,
backed by unit tests.
## Additional context
Resolves FE-2562
## What kind of change does this PR introduce?
Feature. Resolves DEPR-390
## What is the current behavior?
Projects aren’t sortable in either the card or table view.
## What is the new behavior?
Projects are sortable in both:
- Card view: sort dropdown
- Table view: sort dropdown or table column headers
| Before | After |
| --- | --- |
| <img width="1382" height="797"
alt="Supabase-4D1BFE40-875D-494C-8F17-A68D92826458"
src="https://github.com/user-attachments/assets/c4f17b77-bc90-447f-90cd-78a11c2e4129"
/> | <img width="1382" height="797"
alt="Supabase-D8C0AC7C-A28D-4AA6-BA7C-0FCD61DB5D11"
src="https://github.com/user-attachments/assets/d926d03d-2702-48e5-9d1f-0e09d163079d"
/> |
| <img width="1382" height="797"
alt="Supabase-0A545C5C-40B5-47F7-9ACD-2200879BB95E"
src="https://github.com/user-attachments/assets/f2103c32-a150-4db7-a78a-8bd610e2a028"
/> | <img width="1382" height="797"
alt="Supabase-0F7AB608-2E86-4F0C-BB60-C85D9B7F3D57"
src="https://github.com/user-attachments/assets/baa63f14-4059-483d-a9d6-33663e5cff43"
/> |
## Additional context
I wonder if this is overkill given most folks only have 1–2 projects.
Some ideas:
- Only sortable in table view via column headers
- Conditional rendering for folks with 2+ projects
- Opt-in feature
- Feature-flag
I’ve opted to make it global and synced for now.
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
Gildas Garcia