## 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.
## What kind of change does this PR introduce?
UI nit changes
## What is the current behavior?
- We use big dots `•` to separate semantically different sets of text
that are in the same row
- This looks a bit odd given how large the dot is to text
- We put _Project Settings_ in its own sidebar section but without a
separator like all other sidebar sections
## What is the new behavior?
- Use the smaller dots `·` to separate text
- Place a separator above _Project Settings_ in sidebar
| Before | After |
| --- | --- |
| <img width="1342" height="711" alt="AWS Healthy Toolshed
Supabase-70BD1825-8077-4D1B-84C1-831A4ADAFC0B"
src="https://github.com/user-attachments/assets/70246009-a3c7-4b5c-8d75-122140a637d1"
/> | <img width="1342" height="711" alt="AWS Healthy Toolshed Supabase"
src="https://github.com/user-attachments/assets/e3fc13e4-923d-472e-aaf9-d689e890697b"
/> |
## 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)
### Changes
- Adds a dismissible banner prompting paid org users to add a Tax ID to
their billing settings
- Only shown to users with billing read permissions on orgs with a paid
plan and no Tax ID set
- Dismissal is persisted per-org via localStorage; banner also
auto-hides when a Tax ID is added
### Testing
- Log in as a user with no billing permissions into a Free Plan Org with
no tax id: no banner is shown
- Log in as a user with billing permissions into a Free Plan Org with no
tax id: no banner is shown
- Log in as a user with billing permissions into a Paid Plan Org with no
tax id
- Assert banner appears at the top
- Head to `/org/_/billing` with a paid Org. Change your billing country
to a not support one (like Paraguay) and click save. Assert that the
banner disappears. Change it back to continue testing.
- Click dismiss: banner disappears and stays dismissed across
navigation/refresh
- Log in as a user with billing permissions into a different Paid Plan
Org with no tax id
- Add a Tax ID via billing settings, assert that the banner disappears
immediately
<img width="1911" height="50" alt="image"
src="https://github.com/user-attachments/assets/d6208d6d-0939-4ff6-9613-5c687e7c622e"
/>
## 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?
- Added tracker when the main ai button was pressed
- Added new event to track "Open in" third party apps
- Added 2 missing telemetry sources
## 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"
/>
## 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 from preview, but keep local storage check for now for those who
enabled it.
## How to test
- Check the feature does not exist
- Enable the key manually
`localStorage.setItem('supabase-ui-api-side-panel', 'true')` to see it
work
## 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?
Spotted by @kostasb, index advisor was recommending slightly different
column names. Index advisor was running on mismatched queries thus
recommending for the wrong table.
## Context
Adds a warning if running an `ALTER DATABASE` command that prevents
connections to the database. This would lock the dashboard out of the
database, and re-configuring the setting will require a direct
connection to the DB
<img width="623" height="535" alt="image"
src="https://github.com/user-attachments/assets/4c388f4a-753b-4fd6-89c5-89dfaa52c859"
/>
## To test
- Could try running the following command in the SQL editor to check the
warning, this will show all the warnings
```
ALTER TABLE colors2 drop column sss;
update colors set name = 'test';
alter database postgres connection limit 0;
```
## 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>
## Problem
Editing a column from the schema visualiser requires many clicks
## Solution
When hovering over a column in the schema visualiser, an edit button
should appear on the right side. Clicking this button should open the
column edit pane on the right side of the screen. This would reduce the
number of clicks required and allow users to make edits directly from
the visualiser instead of using it only as a visual aid.
## 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 PR changes the logic for show/hide password icon in the sign up
form. Fix#39399 and #41459
## What is the current behavior?
For Password Field Eye Icon Label
<ul>
<li>When password is hidden: Button shows "Hide password" label
(incorrect).
<li>When password is visible: Button shows "Show password" label
(incorrect)
</ul>
For Edge Functions Secrets
<ul>
<li>All secret values are always visible in plain text
<li>No visibility toggle functionality exists
<li>No way to hide/show individual secret values
</ul>
## What is the new behavior?
Sign-up Form Password Field:
<ul>
<li>When password is hidden: Button correctly shows "Show password"
label
<li>When password is visible: Button correctly shows "Hide password"
label</ul>
Labels now accurately describe what clicking the button will do
<p></p>
Edge Functions Secrets:
<ul>
<li>Secret values are hidden by default (security-first approach)
<li>Each secret has its own independent visibility toggle button
<li>Hidden secrets display as bullet points (•••••••••••••••••••••)
<li>Eye icon appears when secret is hidden - click to reveal
<li>EyeOff icon appears when secret is visible - click to hide
<li>Tooltip shows "Hidden" when value is masked, actual value when
visible</ul>
---------
Co-authored-by: Gildas Garcia <1122076+djhi@users.noreply.github.com>
Co-authored-by: Alaister Young <a@alaisteryoung.com>
**Changes:**
- Add function exposure controls to Data API settings
- Adds a per-function GRANT/REVOKE UI to the Data API settings page,
alongside the existing table selector.
- Empty state: shows "No tables/functions available" instead of "0 of 0
X exposed" when there's nothing to show
- Renamed update-exposed-tables-mutation →
update-exposed-entities-mutation to handle both tables and functions in
one save
**Decisions of note:**
- Functions are grouped by schema.name across overloads — toggling one
entry grants/revokes `EXECUTE` on all overloads
- Only normal and window functions are shown (`prokind in ('f', 'w')`) —
triggers and aggregates are excluded
---
**To test:**
- Table and schema selectors still works end-to-end
- Toggling a function and saving updates the count label and applies the
grant (check via SQL Editor: select * from
information_schema.role_routine_grants where routine_schema = 'public')
- Functions in unexposed schemas are dimmed and unclickable
- With no functions in the selected schemas, the selector label reads
"No functions available" and the dropdown shows the same
## 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
## Context
We reached to a consensus that we'll keep manually written queries
within the `pg-meta` package
I'll shift queries over in several PRs but wanted to double check if the
changes here is a good folder structure
## Changes involved
- Am organizing dashboard queries in `pg-meta` based on product
- So folder structure will be `/sql/studio/[product]/*.ts`
- Every constant will be exported directly from `pg-meta`'s index
- So consumption in dashboard will just be `import { xxx } from
'@supabase/pg-meta`
cc @avallete and @soedirgo on this one - lemme know if this is alright,
or if there's a preferred way to do this
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 is something we've discussed for a while. A shared place for error
codes and their mappings, descriptors etc. Available for all projects in
the monorepo.
## 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
- database e2e tests run in serial mode, which is slower
- they also are a bit flaky
## Solution
- Ensure they can run in parallel
- Make them more stable by using UI checks when waiting
- Use assertions that automatically wait/retry in playwright
## Problem
The `tableCreateGeneratePolicies` A/B experiment tested an AI-assisted
policy generator (`RLSManagement`) as a variation in the table creation
side panel. The variation didn't pass — control wins, so the standard
RLS checkbox should be the permanent behavior.
## Changes
- Deleted `useTableCreateGeneratePolicies` hook (PostHog flag + exposure
tracking)
- Deleted the entire `RLSManagement/` component directory (variation UI
— `RLSManagement`, `PolicyList`, `PolicyListEmptyState`,
`ToggleRLSButton`)
- Removed experiment flag checks from `TableEditor.tsx` — RLS checkbox
is now always rendered (was already the control)
- Removed experiment conversion tracking from `SidePanelEditor.tsx`
## Testing
Verified `pnpm typecheck` passes clean. Table creation side panel
renders the RLS checkbox unconditionally as it did in the control.
GROWTH-653
## 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
## Problem
- Some tests don't always cleanup after themselves or don't do it
consistently which make it hard to work on them locally
- Some test suites don't allow parallel execution of their tests
- Some tests are flaky
This a follow up of #43547
## 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?
Bug fix
## What is the current behavior?
Currently, the SMTP Host input field in the Project Dashboard
(Authentication > Email > SMTP Settings) does not sanitize whitespace.
If a user accidentally pastes a hostname with leading or trailing spaces
(e.g., " smtp.resend.com "), the DNS lookup fails during the OTP
delivery process.
This results in the following error in the Auth logs:
```"dial tcp: lookup smtp.resend.com on 127.0.0.53:53: server misbehaving"```
Noticed, the other input fields of Sender details and Host, Username and Password under SMTP Provider settings take leading and trailing whitespaces as well.
## What is the new behavior?
Input sanitization has been applied across the SMTP configuration schema. The following fields now utilize .trim() to ensure data integrity:
- SMTP_HOST
- SMTP_ADMIN_EMAIL & SMTP_SENDER_NAME
- SMTP_USER
- SMTP_PASS
## Screenshots:
Before Fix:
<img width="604" height="198" alt="Screenshot 2026-03-09 at 2 04 49 AM" src="https://github.com/user-attachments/assets/76ae23a6-3ad8-4f82-8f0f-ab12f4168e81" />
After Fix:
<img width="594" height="194" alt="Screenshot 2026-03-09 at 1 58 48 AM" src="https://github.com/user-attachments/assets/03f64294-0bfe-4fca-a82b-12ee07a6d218" />
This fixes the issue #43529
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
## What kind of change does this PR introduce?
- UI fix
## What is the current behavior?
- The _New project_ button overflows to the right on smaller
(phone-sized) breakpoints
- Due to addition of _Sort by_ dropdown last week
## What is the new behavior?
- All actions now wrap on smaller breakpoint
| Before | After |
| --- | --- |
| <img width="393" height="852"
alt="Supabase-383C523F-0BF1-48CD-8052-F6D68301DA4E"
src="https://github.com/user-attachments/assets/3983a815-16ff-48cd-857f-b84b82bfc923"
/> | <img width="393" height="852"
alt="Supabase-ED7AD923-E837-4D48-B7D1-6DA3C6E45BFA"
src="https://github.com/user-attachments/assets/fe19f9cc-f832-4c5d-b412-0aa1a0c16d5b"
/> |
## 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
## What kind of change does this PR introduce?
Resolves FDBK-40065
## What is the current behavior?
Using the _Run_ button on either inline or “full” SQL Editor removes
focus from the Monaco editor.
## What is the new behavior?
The text caret remains in the Monaco editor even after button press.
## To test
Try running a few queries both with keyboard (⌘ enter) and mouse click
on the _Run_ button:
```sql
-- 1) Create a mock table + seed data
drop table if exists public.test;
create table public.test (
id bigserial primary key,
name text not null,
created_at timestamptz not null default now()
);
insert into public.test (name)
values
('alpha'),
('beta'),
('gamma'),
('delta');
select * from public.test order by id;
```
```sql
-- 2) Deletion query that should trigger the warning modal (destructive op)
delete from public.test where id <= 2;
-- Verify remaining rows
select * from public.test order by id;
```
## Additional context
- [ ] This was FDBK-40065 that we should reply to
## What kind of change does this PR introduce?
Bug fix: custom icons now respect their source SVG’s stroke/fill and
stroke-width instead of always getting a global stroke.
## What is the current behavior?
Every custom icon gets `stroke="currentColor"` and `strokeWidth={2}`
from `createSupabaseIcon`, so fill-only logos get an extra stroke and
icons designed at `stroke-width="1"` (e.g. postgres, auth) render too
thick. Call sites and the design-system grid needed workarounds
(`strokeWidth={0}`, `FILL_ONLY_ICONS`, `STROKE_WIDTH_FROM_SOURCE`).
## What is the new behavior?
The icon build reads root SVG attributes (`fill`, `stroke`,
`stroke-width`, etc.) and passes them as per-icon defaults. Fill-only
icons (chatgpt, claude, axiom, last9) have `stroke="none"` in source and
render with no stroke; stroke icons keep their source stroke-width (e.g.
postgres at 1). No `strokeWidth={0}` or allowlists needed at call sites
or in the icon grid.
| Before | After |
| --- | --- |
| <img width="1826" height="552" alt="CleanShot 2026-03-05 at 10 53
31@2x-3D63CEF0-1132-44F5-A382-730346432F1E"
src="https://github.com/user-attachments/assets/9caf73fa-351b-4ea2-a420-b3339f934742"
/> | <img width="1814" height="552" alt="CleanShot 2026-03-05 at 10 53
40@2x-514FC8BD-D30F-4D23-B209-0ECD6D13A184"
src="https://github.com/user-attachments/assets/936ea5a5-dae0-413f-8545-b90a502cea69"
/> |
## Additional context
- Added `stroke="none"` to the four fill-only source SVGs;
sentry/grafana/otlp/datadog already had `stroke-width="0"`.
- `createSupabaseIcon` only applies `color`/`strokeWidth` when the
consumer passes them, so `svgDefaults` from the build are used
otherwise.
- Removed workarounds from `icons.tsx` and GuidesSidebar; updated
icons.mdx (defaults + fill-only guidance).
JSON column viewer looks fine on dark mode, but barely visible on light
mode, especially when the value is of string type.
There are no colors that can satisfy the 4.5:1 contrast ratio (minimum
requirement for web and digital accessibility) on both white and black
background, so I had to pick different classes for ight mode (dark mode
is fine, I checked the colors against the dark background and the
contrast is good).
Even though the new colors may not look that contrasting to each other,
I prioritized accessibility, and made sure they all complied with the
4.5:1 contrast ratio.
Before:
<img width="499" height="179" alt="112"
src="https://github.com/user-attachments/assets/7f0821cf-6127-4246-a2c2-a78a5d31083a"
/>
After:
<img width="499" height="211" alt="222"
src="https://github.com/user-attachments/assets/0b5b2c35-9211-4a25-a9f5-eef4e5c8c8f3"
/>
Fixes#40633
---------
Co-authored-by: Ali Waseem <waseema393@gmail.com>
### Changes
- Replaces the isPaid plan-based check on the "Prevent use of leaked
passwords" (PASSWORD_HIBP_ENABLED) setting with a proper entitlement
check using the `password_hibp` entitlement key
- Adds a new `useHasEntitlementAccess` hook that returns a reusable
checker function for any entitlement key, backed by the same cached
entitlements query
### Testing
- Head to `/project/_/auth/providers?provider=Email` with an Org on the
Free Plan
- Assert that the "Prevent use of leaked passwords" toggle is disabled.
- Head to `/project/_/auth/providers?provider=Email` with an Org on the
Pro Plan
- Assert that the "Prevent use of leaked passwords" toggle is enabled
and can be toggled and saved.
<img width="612" height="496" alt="image"
src="https://github.com/user-attachments/assets/fc1ccc79-016c-4265-96ac-bdb458d2a8de"
/>
Adds a feature flagged exposed tables config to postgrest settings:
<img width="1158" height="589" alt="Screenshot 2026-03-02 at 17 04 13"
src="https://github.com/user-attachments/assets/8fa8ab81-0bfa-4781-83bc-80ac52e180f8"
/>
To test:
- make sure the existing (feature flag off) settings work as expected
- make sure exposing and removing schemas works in the new mode
- make sure exposing and removing tables works in the new mode
- ideally try with a lot of tables to check search and infinite scroll
work as expected
- try exposing a schema without any tables (like `graphql_public`) and
make sure it doesn't get removed randomly when editing tables
- try with a table with custom permissions (for example `REVOKE SELECT
ON public.posts FROM anon;`) and make sure the user is informed with the
tooltip
---------
Co-authored-by: Nick Babadzhanian <33933459+pgnickb@users.noreply.github.com>
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.
### Changes
- Replace plan-based checks (`LOG_RETENTION`, `availableIn`) with
`useCheckEntitlements('log.retention_days')` in the chart interval
dropdown
- `ChartIntervalDropdown` now calls the entitlements hook internally
instead of receiving plan props
- Remove `LOG_RETENTION` constant and `availableIn` from
`CHART_INTERVALS`
- Update consumer components (`ProjectUsage`, `ProjectUsageSection`,
`ObservabilityOverview`) to remove plan prop passing
### Testing
- Head to `/project/_/observability` with a Free plan org.
- Click on the time selector "Last 7 days" is disabled, default is "Last
60 minutes", tooltip shows retention limit and upgrade link
<img width="827" height="151" alt="image"
src="https://github.com/user-attachments/assets/20988398-8f0a-46b6-be3d-af4e9d530f81"
/>
- With a Pro Org and above the "Last 7 days" option should be enabled
The "Management of read replicas has moved" banner in Settings >
Infrastructure linked to /database/replication, which returns a 404-like
page for users who don't have the database:replication feature enabled.
The notice is now only shown when the feature is enabled.
## What kind of change does this PR introduce?
Form handling improvement.
## What is the current behavior?
https://github.com/supabase/supabase/pull/43201/ standardised our
discard changes behaviour with a shared hook and
`DiscardChangesConfirmationDialog` component. But many forms and sheets
still:
1. Don’t have any Discard-confirm close behaviour, making it too easy to
make accidental discards
2. Use a more complicated, manually-created `CloseConfirmationModal`
approach
## What is the new behavior?
- Replaced all instances of `#2` above that had `CloseConfirmationModal`
with `DiscardChangesConfirmationDialog` and its hook
- Improved design system documentation around dirty form dismissal
| Before | After |
| --- | --- |
| <img width="987" height="569" alt="Mercor Apexroles Foo
Supabase-9A40EC7C-F335-4B26-B567-450FC0845463"
src="https://github.com/user-attachments/assets/363bed82-34d2-4cc8-9164-6d18cfdbdbbc"
/> | <img width="987" height="569" alt="Mercor Apexroles Foo
Supabase-F427F1FA-DECC-4194-B663-A9E5A6F285A1"
src="https://github.com/user-attachments/assets/d49fafdc-a5c2-46df-9b67-ec42bacbe716"
/> |
## To test
Try editing values these sheets in staging, then blurring the sheet or
pressing `esc`:
- CreateQueueSheet.tsx
- CronJobsTab.tsx
- CronJobPage.tsx
- EditWrapperSheet.tsx
- OverviewTab.tsx
- WrappersTab.tsx
- CreateFunction/index.tsx
- EditHookPanel.tsx
- TriggerSheet.tsx
- SidePanelEditor.tsx
- EditSecretSheet.tsx
- PolicyEditorModal/index.tsx
- PolicyEditorPanel/index.tsx
## Still to come
- [ ] Incrementally take on `#1`: implement
`DiscardChangesConfirmationDialog` and its hook in sheets or dialog
forms that have no dirty form dismissal handling
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>