## Summary
- Converts ~27 `executeSql` call sites in `apps/studio/data/**` to build
SQL through `safeSql` / `ident` / `literal` / `keyword` /
`joinSqlFragments` instead of raw template-string interpolation.
- Tightens the `useDatabaseCronJobCreateMutation` and
`useDatabaseEventTriggerCreateMutation` `sql`/`query` parameter types
from `string` to `SafeSqlFragment` (callers already produce one).
- Updates `getDeleteEnumeratedTypeSQL` in `packages/pg-meta` to return
`SafeSqlFragment`.
- Fixes a bug noticed while testing where Queues integration does not
correctly handle queues with uppercase names.
## Pages to manually test
- Integrations > Cron Jobs
- Integrations > Queues
- Database > Triggers > Event Triggers
- Database > Indexes
- Reports > Query Performance
- Storage
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
* **Bug Fixes**
* Queue lookups now correctly handle case-insensitive queue names.
* Queue table references are now properly managed and consistently
applied throughout the queue management interface.
* Improved queue name display normalization in the user interface.
* **Chores**
* Enhanced SQL query safety across the database layer through
parameterized query construction and safer templating approaches.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Logo field now accepts/editable logo URL, plus a new storage-based
Logo Picker to select or remove images from project storage.
* Full storage picker: browse buckets, columns/list views, search,
drag‑and‑drop uploads, file previews (image/audio/video), and
single-file selection with responsive mobile/desktop layouts.
* **Refactor**
* Logo submission streamlined to send the provided URL directly (legacy
file-read/upload flow removed).
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Consolidate Table Editor grid header actions into a single row
https://github.com/user-attachments/assets/1020c385-8fa9-4ef1-b5e7-03983111508b
## Changes involved
- Index advisor, Realtime, and API docs are now behind a dropdown menu
button (Treated as secondary actions)
- Grid header actions shifted into the same row as filter bar (more
space for data grid)
- Header actions will hide while filter bar is in focus (remove
distractions, more space for filter bar)
## Changes to filter bar
- Filter bar will refocus when deleting a filter
- Clicking on the search icon will focus on the free form input of the
filter bar
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added a “More” dropdown in grid actions to access Realtime, API docs,
and Index Advisor.
* New dialogs for enabling Index Advisor and toggling Realtime are now
consistently managed.
* **Improvements**
* Improved filter focus handling with auto-refocus when conditions
change and responsive header behavior.
* Adjusted popover alignment, separator visuals,
header/footer/pagination layout and sizing.
* Filter bar now supports programmatic focus; Connect button supports
icon-only mode.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Gildas Garcia <1122076+djhi@users.noreply.github.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?
Refactor / security improvement
## What is the current behavior?
SQL fragments across Studio are built from plain `string` values with no
type-level distinction between developer-authored SQL, DB-sourced
identifiers, and user-typed or externally-influenced content.
## What is the new behavior?
Extends the safe SQL model to additional Studio interfaces, using
`SafeSqlFragment`, `safeSql`, `ident()`, `literal()`, `untrustedSql()`,
and `acceptUntrustedSql()` from `@supabase/pg-meta/src/pg-format`:
- **Policy editor**: template constants typed as `SafeSqlFragment` via
`safeSql` tagged literals; Monaco editor `onInputChange` emits
`untrustedSql()`; `acceptUntrustedSql()` called only at the Save
gesture; roles selector emits a composed `SafeSqlFragment` via `ident()`
+ `joinSqlFragments()`
- **Auth hooks**: grant/revoke SQL statements use `ident()` for schema
and function names
- **Docs description editor**: `COMMENT ON` queries use `ident()` and
`literal()` for table/column/function names and values
- **Cron jobs**: `cron.schedule()` call and HTTP request builder use
`literal()` for all user-provided values
- **GraphQL linter CTA**: `REVOKE` statement uses `ident()` for schema,
table, and role
- **Storage public bucket warning**: `DROP POLICY` uses `ident()` for
policy name
- **View security autofix modal**: `ALTER VIEW` uses `ident()` for
schema and view name
- **API settings**: `CREATE SCHEMA` mutation uses `safeSql` tagged
literal
- **Database event trigger delete**: `DROP EVENT TRIGGER` uses `ident()`
for trigger name
- **Database queues query**: queue list query uses `safeSql` tagged
literal
- **Role impersonation**: function invocation SQL uses `ident()` and
`literal()`
## Manual testing checklist
- Authentication > Policies
- Authentication > Hooks
- Integrations > Queues
- Database > Event Triggers
- Integrations > Cron Jobs
- Table Editor > View entity security autofix
- API Settings > expose schema
- Linter > GraphQL exposure CTA
- Docs > table/column description editor
- Role impersonation (user impersonation panel)
## Additional context
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Replaced ad-hoc SQL string building with a safer, fragment-based SQL
construction across auth, policies, integrations, storage, and DB
operations to improve SQL safety while preserving behavior.
* **Bug Fixes / UX**
* Policy editor and code editor now propagate role and input changes
more reliably, improving editor responsiveness and policy handling
without UI changes.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Context
Main fix is actually just the disabled check on the "Merge branch"
button
We're preventing merging of branches via the dashboard if the project
has GH integration + "Deploy to production" enabled (the latter we're
checking via if the `git_branch` property from the main branch exists,
from the GET branches API endpoint)
However, the `git_branch` property persists even after disabling the GH
integration (by design), and hence we were incorrectly disabling the
"Merge branch" button if the user removed the GH integration. Hence the
fix is to also check if the project has an active GH integration
## Other changes
- Refactored the merge page into smaller components
- Added an admonition to callout the "Deploy to production" + what steps
to take (otherwise it's not clear at all what to do in this scenario)
<img width="1451" height="524" alt="image"
src="https://github.com/user-attachments/assets/9df7d432-b220-4f71-b8f4-5ed0fd426afc"
/>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Redesigned merge request page interface with dedicated components for
title, subtitle, and merge actions, improving user clarity and
experience.
* Added GitHub production deployment restriction messaging—users cannot
proceed with merge requests when this integration deployment method is
enabled.
* **Refactor**
* Enhanced GitHub integration connection query patterns and overall code
organization.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Context
Main fix is to ensure that the tooltip here is scrollable - but also
adding some refactors
This is the org billing page when downgrading an org
### Before
<img width="400" alt="image"
src="https://github.com/user-attachments/assets/6094c2e6-c1bb-460f-a2d2-347c1d7d2e77"
/>
### After
<img width="400" alt="image"
src="https://github.com/user-attachments/assets/9d0ac9a6-6e89-4758-af14-8144a8a86469"
/>
## Changes involved
- Use HoverCard for invoice estimate in plan confirmation dialog
- Also nudge the UI a little, e.g use a separate column for the compute
prices + adjust text color to improve clarity
- Refactor usage of `any` for some of the TS declarations
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added an invoice estimate tooltip in subscription settings showing
monthly charges with plan fees, combined compute rows, per-project
compute costs, optional compute credits, and a total monthly estimate.
* **Refactor**
* Simplified the plan update flow by consolidating subscription preview
handling and extracting the invoice UI into the new tooltip component.
* **Chores**
* Improved internal type definitions for subscription preview data and
pricing tier identifiers.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## 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?
Cleanup after shipping https://github.com/supabase/supabase/pull/45389,
the backend is now defaulting to the new v2 `format`, and made `format`
param optional.
So this:
- removes references to `v2` naming, as this is the only format
- removes the `format` query param from the audit logs API calls
## What is the current behavior?
Same audit log functionality shown in
https://github.com/supabase/supabase/pull/45389
## What is the new behavior?
Functionally the same behavior for audit logs.
- [x] Manual test in staging
## Additional context
⚠️ Will leave the `do-not-merge` tag on until:
- [ ] backend `format` optional PR lands in production.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Consolidated audit log type definitions and updated internal API
request formatting for audit endpoints across Account and Organization
audit log components. No changes to user-facing functionality or audit
log display.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Mark provenance of SQL via the branded types SafeSqlFragment and
UntrustedSqlFragment. Only SafeSqlFragment should be executed;
UntrustedSqlFragments require some kind of implicit user approval (show
on screen + user has to click something) before they are promoted to
SafeSqlFragment.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Editor and RLS tester show loading states for inferred/generated SQL
and include a dedicated user SQL editor for safer edits.
* **Refactor**
* Platform-wide SQL handling tightened: snippets and AI-generated SQL
are treated as untrusted/display-only until promoted, improving safety
and consistency.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
The Max IOPS reference line in the Database Observability report
displays the provisioned disk IOPS, but its tooltip claims it shows the
"Maximum IOPS for your current compute size". The real effective ceiling
is `min(compute IOPS limit, provisioned disk IOPS)`. Users who upgrade
their disk IOPS without upgrading compute see an inflated number and may
draw incorrect conclusions about their IO headroom.
Reported in [Linear
DEBUG-63](https://linear.app/supabase/issue/DEBUG-63) (originally
[FE-2856](https://linear.app/supabase/issue/FE-2856)).
## Fix
In
[apps/studio/data/reports/database-charts.ts](apps/studio/data/reports/database-charts.ts),
use the existing `mapComputeSizeNameToAddonVariantId` +
`COMPUTE_MAX_IOPS` lookup (already used in DiskManagement) to compute
the effective ceiling and pass it as the `disk_iops_max` reference line
value. Tooltip rewritten to match.
```ts
const provisionedDiskIops = diskConfig?.attributes?.iops
const computeIopsLimit =
COMPUTE_MAX_IOPS[mapComputeSizeNameToAddonVariantId(project?.infra_compute_size)]
const effectiveMaxIops =
typeof provisionedDiskIops === 'number' && typeof computeIopsLimit === 'number'
? Math.min(provisionedDiskIops, computeIopsLimit)
: provisionedDiskIops
```
## Test plan
- [ ] On a project where compute IOPS limit < provisioned disk IOPS
(e.g. Micro compute with upgraded disk), confirm the Max IOPS reference
line on `/project/{ref}/observability/database` reflects the compute
limit, not the disk IOPS.
- [ ] On a project where provisioned disk IOPS < compute IOPS limit,
confirm the reference line still shows the disk IOPS.
- [ ] Hover the line and confirm the tooltip reads "Effective maximum
IOPS for your current compute and disk configuration..."
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
* **Bug Fixes**
* Enhanced IOPS limit calculations in database reports to account for
both compute size and disk provisioning constraints, resulting in more
accurate Max IOPS reference values. Improved chart tooltips to better
reflect the effective combined compute and disk IOPS constraints.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.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?
- Update to the audit log schema (changes were already applied in
staging)
- Updates the org & project audit log page to reflect the changes to the
schema
- The schema should be agnostic to whether logs were emitted to logflare
with the old & new schema format - the backend adjusts old logs to the
new format.
## What is the current behavior?
Currently, the frontend is parsing the legacy schema as the backend
returns this by default. It also doesn't show some of these new fields
yet.
## What is the new behavior?
### Org Audit Logs - Table View
<img width="1810" height="1310" alt="CleanShot 2026-04-29 at 18 27 22"
src="https://github.com/user-attachments/assets/47fec068-1ffa-4e52-bc46-3bffdef55adb"
/>
### Org Audit Logs - Single log View
<img width="1842" height="1494" alt="CleanShot 2026-04-29 at 18 27 37"
src="https://github.com/user-attachments/assets/3cff3bdf-4a6a-4981-acaa-7f95bb3ae9cf"
/>
Note that the `Target` field is no longer there. We just show the
`metadata` JSON.
<img width="1842" height="1494" alt="CleanShot 2026-04-29 at 18 27 40"
src="https://github.com/user-attachments/assets/d2e681f0-41a6-4bc7-a3d7-ec7e8101616c"
/>
### Account (Profile) Audit Logs - Table View
<img width="1810" height="1310" alt="CleanShot 2026-04-29 at 18 25 20"
src="https://github.com/user-attachments/assets/c72e19df-9b82-4611-8889-7af463769550"
/>
### Account (Profile) Audit Logs - Single log View
<img width="1810" height="1310" alt="CleanShot 2026-04-29 at 18 25 32"
src="https://github.com/user-attachments/assets/46f8d3b6-4f2f-4944-b891-431a93e5f3c3"
/>
## Additional context
⚠️ currently leaving the `do not merge` tag on, until:
- [x] I have verified it works in staging
- [x] We've deployed the new schema to production
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Audit logs now use the v2 format with microsecond-accurate timestamps,
improved ordering, and a revamped details panel showing clearer
actor/action/request/project/org fields and fallback labels.
* Page/header layout updated so audit logs render at top level with
adjusted spacing.
* **Refactor**
* Shared sorting and filtering utilities added for consistent
user/project filtering and non-mutating log sorting.
* **Tests**
* Added tests for timestamp conversion, sorting, filtering, and
date-range formatting.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
This PR fixes an issue where the infinite list doesn't work for cron
jobs. If the initial data (20 cronjobs) renders and you have a tall
monitor to fit the entire table, the `react-data-grid` can't `onScroll`
event which fetches the next page.
To test:
1. Add 40-50 cron jobs by running `SELECT cron.schedule('test 30', '0 2
* * 1', 'select 1');` repeatedly.
2. Open the /project/_/integrations/cron/jobs
3. See if you can scroll and trigger the second page.
Fixes
https://linear.app/supabase/issue/FE-3117/cron-job-is-not-scrollable
This PR migrates the whole monorepo to use Tailwind v4:
- Removed `@tailwindcss/container-queries` plugin since it's included by
default in v4,
- Bump all instances of Tailwind to v4. Made minimal changes to the
shared config to remove non-supported features (`alpha` mentions),
- Migrate all apps to be compatible with v4 configs,
- Fix the `typography.css` import in 3 apps,
- Add missing rules which were included by default in v3,
- Run `pnpm dlx @tailwindcss/upgrade` on all apps, which renames a lot
of classes
- Rename all misnamed classes according to
https://tailwindcss.com/docs/upgrade-guide#renamed-utilities in all
apps.
---------
Co-authored-by: Jordi Enric <jordi.err@gmail.com>
Updates the marketplace DB query to use the new `publish_dashboard`
column that was added in https://github.com/supabase/marketplace/pull/49
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Updated internal marketplace integration query and database type
definitions to streamline listing management logic.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What kind of change does this PR introduce?
Cleanup.
## What is the current behavior?
Temporary access still has a couple of leftover JIT fallback messages
and an unnecessary local unavailable-reason type after the Platform
response types were split into `JitAccessResponse` and
`JitStateResponse`.
## What is the new behavior?
Studio relies on the generated `JitStateResponse` discriminated union
for the toggle warning and uses temporary access copy consistently in
the remaining fallback toasts.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Improvements**
* Refined error messaging for temporary database access grant and revoke
operations.
* Enhanced condition detection for toggle failure warnings in database
access configuration.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What kind of change does this PR introduce?
UI and copywriting improvements for temporary access.
## What is the current behavior?
The temporary access UI still used older JIT/ephemeral naming in some
places, did not clearly explain the setup requirements, and had to infer
unavailable states from Platform error message text.
## What is the new behavior?
The settings UI now uses temporary access naming consistently, explains
that temporary access uses short-lived tokens for manual database
connections, and renders clearer unavailable states for projects that
require either a Postgres upgrade or a platform migration.
The Studio query now consumes Platform’s structured `unavailableReason`
contract instead of parsing human-readable error strings, so the UI owns
the copy while Platform owns the eligibility reason.
Validation:
- `pnpm eslint
components/interfaces/Settings/Database/JitDatabaseAccess/JitDbAccessConfiguration.tsx
data/jit-db-access/jit-db-access-query.ts`
- `pnpm tsc --noEmit --pretty false`
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* IP range input now supports one CIDR range per row with add/remove
rows and form integration.
* **Documentation**
* Replaced “JIT” wording with “Temporary” / “Ephemeral token-based”
access across UI, dialogs, toasts, and help links.
* Added minimum PostgreSQL version requirement (17.6.1.081+).
* **Improvements**
* Per-row CIDR validation with precise nested error messages.
* Refined layout spacing and moved the temporary-access configuration
earlier in Database settings.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Etienne Stalmans <etienne@supabase.io>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
## Context
Resolves FE-3077
Related discussion: https://github.com/orgs/supabase/discussions/45233
Verifying the correctness of your RLS policies set up has always been a
gap, as highlighted by a number of GitHub discussions like
[here](https://github.com/orgs/supabase/discussions/12269) and
[here](https://github.com/orgs/supabase/discussions/14401). As such,
we're piloting a dedicated UI for RLS testing (using role impersonation
as the base), in which you'll be able to
- Run a SQL query as a user (not logged in / logged in - this is the
role impersonation part)
- See which RLS policies are being evaluated as part of the query
- And hopefully be able to debug which policies are not set up correctly
Changes are currently set as a feature preview - and we'll iterate as we
get feedback from everyone 🙂🙏
<img width="613" height="957" alt="image"
src="https://github.com/user-attachments/assets/83c37f8a-28fc-43b3-b0ff-e28571d8710c"
/>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* RLS Tester: run queries as anon or authenticated users, view inferred
SQL, per-table policy summaries, and data previews of accessible rows.
* UI preview: new RLS Tester preview card and modal with opt-in toggle;
RLS Tester sheet with role/user selector and query editor.
* SQLEditor: “Explain” tab is always visible.
* **Chores**
* Added supporting API endpoints, background checks for table RLS
status, and a local-storage flag to persist the preview opt-in.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What kind of change does this PR introduce?
Bug fix
## What is the current behavior?
Creating a schema only branch fails because ETL publication is owned by
`supabase_etl_admin` which users have no access.
## What is the new behavior?
Since ETL supports user managed publications, create them through pgmeta
so it's owned by `postgres` role instead.
## Additional context
mirrors [upstream
etl](https://github.com/supabase/etl/blob/main/etl-api/src/db/publications.rs#L22-L51)
implementation
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Added guards to prevent creating publications when project or
connection info is missing, with clearer error logging.
* Ensure the project connection string is explicitly passed so
publications target the correct database.
* **Refactor**
* Publication creation now executes generated SQL directly against the
database, with correct handling of empty or selected table lists and
proper identifier quoting for reliability.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: CodeRabbit <noreply@coderabbit.ai>
## 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?
Feature
## What is the current behavior?
When sending organization invites to multiple emails at once, the
invitations API is called once for each email passed, passing a single
email address in the `email` field.
## What is the new behavior?
A single request is used when sending multiple organization invites at
once, by using the new `emails` field.
## Additional context
This builds further on https://github.com/supabase/supabase/pull/42637⚠️ Note: I'd like to merge this after getting the API changes in first:
https://github.com/supabase/platform/pull/31561
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Bulk invite: paste comma-separated emails (parsed, trimmed,
deduplicated, lowercased) and send as a single batched request; inputs
are categorized into new, already-invited, and existing members.
* SSO and project scope options included in invite payloads.
* **Bug Fixes / API**
* Invitation endpoint now accepts multiple emails; resend uses
multi-email format. Invalid addresses are blocked, existing members are
skipped with error toasts, and overall success is reported with the
dialog closing after invite.
* **Tests**
* Added unit and UI tests covering parsing, categorization, payload
building, validation limits, and invite flows.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Danny White <3104761+dnywh@users.noreply.github.com>
## Summary
- Add tax preview to the credit top-up flow by integrating the new `POST
/organizations/{slug}/billing/credits/preview` endpoint
- Show a price breakdown (credit amount, tax line item, total) in the
top-up dialog before the user confirms payment
- Handle all three `tax_status` states: show tax when `calculated`, hide
the line when `not_applicable`, show an inline warning when `failed`
## Behavior
- Preview fires as soon as a valid amount (300–2000) is entered; address
and tax ID are optional and refine the estimate
- Amount and address changes are debounced at 1s to avoid excessive API
calls
## Test plan
- [ ] Open credit top-up dialog - verify preview appears with default
$300 amount
- [ ] Change amount within 300–2000 - verify preview updates after
debounce
- [ ] Enter amount outside range (e.g. 100 or 3000) - verify preview
hides and validation error shows
- [ ] Add a new payment method with a billing address in a taxed region
- verify tax line item appears
- [ ] Add a new payment method with no tax jurisdiction - verify no tax
line, just total
- [ ] Complete a top-up - verify the charge goes through and dialog
closes
<img width="571" height="551" alt="image"
src="https://github.com/user-attachments/assets/d3357752-f913-4a4a-b84a-f78e2f457c7b"
/>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Credit top-up preview with charge breakdown (credit, tax or tax note,
total).
* Onboarding survey endpoint and ISO 27001 certificate availability for
organizations.
* **Updates**
* Improved top-up UX: debounced address/tax inputs, enforced min/max
amount validation, preview-driven form state, and submit disabled while
preview is loading/stale.
* API docs wording changed to “temporary access configuration.”
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What kind of change does this PR introduce?
UI improvements.
- Resolves DEPR-401
- Resolves DEPR-424
- Resolves DEPR-425
## What is the current behaviour?
Studio currently blurs two different concepts together:
- `billing_partner` / `billing_via_partner`, which represent real
billing ownership for marketplace-managed organisations such as AWS and
Vercel
- Stripe connection state, which is not actually partner billing in the
same sense, but was previously being mocked through the same UI paths
That made the Stripe work harder to reason about and left some local
behaviour dependent on temporary overrides rather than the API shape we
want to ship.
## What is the new behaviour?
This PR separates those concerns while keeping the existing AWS and
Vercel marketplace experience intact.
- AWS and Vercel continue to use `billing_partner` /
`billing_via_partner` for billing ownership, lockouts, and manage CTAs
- Stripe display state now comes from `integration_source`, which lets
Studio show Stripe-specific badges and alerts without treating Stripe as
a billing partner
- organisation-level partner UI is unified across AWS, Vercel, and
Stripe, including the org banner, navbar icon treatment, and
organisation cards
- project-level Stripe UI now appears only when the project itself is
marked as Stripe-connected, including the project switcher, project list
surfaces, and a project-level banner
- Stripe-connected organisations are no longer incorrectly blocked
behind the AWS/Vercel-style billing management alerts for invoices,
billing address, payment methods, or plan changes
- banner dismissal is scoped to the relevant org/project and
partner/integration state
## Review order
Most of the diff size here is regression tests and generated types. The
behavioural changes are concentrated in a smaller set of files.
Recommended review order:
1. `integration_source` vs `billing_partner` data-model split and
org/project query mapping
2. org-level UI: partner icon, org banner, org dropdown/card treatment
3. billing gating updates for Stripe vs AWS/Vercel
4. project-level Stripe UI: dropdown, list surfaces, banner
5. tests and generated types
| Stripe Org(s) |
| --- |
| <img width="1024" height="759" alt="Organizations Supabase"
src="https://github.com/user-attachments/assets/d0ef338c-3b41-4c6d-b3bd-f21a2c182840"
/> |
| Vercel Org(s) |
| --- |
| <img width="1024" height="759" alt="Organizations Supabase"
src="https://github.com/user-attachments/assets/1dc57770-3f24-45ac-840f-34680555cde8"
/> |
| AWS Org(s) |
| --- |
| <img width="1024" height="759" alt="Organizations Supabase"
src="https://github.com/user-attachments/assets/7847dad0-ee30-4a65-ab0b-b3b16af0d34f"
/> |
| Stripe Org, Non-Stripe Project |
| --- |
| <img width="1152" height="885" alt="Mallet Toolshed
Supabase-1673E019-792C-462C-B6F8-C5DDB810B331"
src="https://github.com/user-attachments/assets/556fbea3-b5ae-4f2f-96b9-6f66c6654e4a"
/> |
| Stripe Org, Stripe Project |
| --- |
| <img width="1152" height="885" alt="Hammer Toolshed
Supabase-7E86C17C-561F-4221-BD16-EAFF7D41AAE0"
src="https://github.com/user-attachments/assets/94f8daf6-0320-413e-8d56-59f9acaaea15"
/> |
| Vercel Org |
| --- |
| <img width="1024" height="759" alt="Projects Toolshed
Supabase-A7891653-9366-4B99-89DD-789D70CD52E3"
src="https://github.com/user-attachments/assets/c87ee6e8-4451-4866-a905-23a38b2593e3"
/> |
| AWS Org |
| --- |
| <img width="1024" height="759" alt="Projects Toolshed
Supabase-58A43ECE-569E-4541-9463-346A90B02CFF"
src="https://github.com/user-attachments/assets/9350a180-4d58-42a1-ad1a-95893c2e8b12"
/> |
This also removes the old Stripe mock override path in Studio so the
frontend matches the intended API model more closely.
## ~~Dependencies~~ (merged!)
This work depends on the private platform change that exposes
`integration_source` on the relevant organisation and project payloads:
- https://github.com/supabase/platform/pull/31874
_Update: now merged._
## Local testing
### Stripe
If you have the private `platform` repo checked out locally, make sure
your local API returns `integration_source: 'stripe_projects'`
consistently for the Stripe-linked org/project you are testing.
Important responses:
- `/platform/organizations`
- `/platform/organizations/:slug/projects`
- `/platform/projects/:ref`
Verify:
- org banner and org icon show the Stripe connected state
- unopened and opened project switcher both show Stripe only for
Stripe-linked projects
- project cards / table rows show the Stripe chip only for Stripe-linked
projects
- the project-level Stripe banner appears across project surfaces
- billing address, tax ID, invoices, payment methods, and plan changes
remain editable in Studio for Stripe orgs
### Vercel
Use a Vercel Marketplace org with real `billing_partner` /
`billing_via_partner` values.
Important org-level endpoints for local mocking in `platform`:
- `/platform/organizations`
- `/platform/organizations/:slug`
- `/platform/organizations/:slug/billing/subscription`
Project-level Vercel indicators still come from
`/platform/integrations/:slug`, not `integration_source`.
### AWS
Use an AWS Marketplace org with real `billing_partner` /
`billing_via_partner` values.
Important org-level endpoints for local mocking in `platform`:
- `/platform/organizations`
- `/platform/organizations/:slug`
- `/platform/organizations/:slug/billing/subscription`
AWS does not currently have a Stripe-like project-level indicator in
these org/project payloads.
## Notes
- `billing_partner` is no longer the right abstraction for the
Stripe-connected case in this PR. It remains the source of truth for
marketplace billing ownership, while Stripe currently uses
`integration_source` as a connection/display signal.
- I re-ran `pnpm api:codegen` while tightening this PR and kept only the
generated type changes this branch actually depends on, to avoid
unrelated API drift in the review.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Stripe Projects integration added for billing and project flows
* Partner icons/badges shown across org and project lists, dropdowns,
and rows
* Dismissible, partner-specific marketplace/integration banners with
contextual CTA behavior
* Improved partner-billing detection to drive billing UI and
invoice/plan availability
* **Tests**
* Extensive new test coverage for billing UI, partner-managed fallbacks,
banners, icons, and related flows
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>
Edit: Can be merged, mgmt api deployed
Dashboard addition to frontend for access to the ISO 27001 certificate.
View for Team customers:
<img width="1737" height="1151" alt="image"
src="https://github.com/user-attachments/assets/cd62d24f-8b6e-4600-9ded-943a170cd124"
/>
Resolves SEC-799
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* ISO 27001 certificate added to Documents with a Download action,
confirmation modal, new-tab open on success, and error toast on failure.
* Users without billing permission see a no-permission view; users
missing entitlement see an “Upgrade to Team” prompt.
* **Refactor**
* Upgrade-to-Team flows for SOC2 and related upgrade UI standardized to
use the shared upgrade component.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Improved SQL query handling for vector bucket creation and Foreign
Data Wrapper operations
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Fixes the RLS policies page showing self-contradictory or wrong
admonitions for tables with partial grants. Classifies each table using
the same `granted / custom / revoked` semantics used by the Data API
settings page so the two views agree on what counts as "exposed".
**Changed:**
- `PolicyTableRow` now uses `useTableApiAccessQuery` (shared cache with
the Table Editor sidebar) instead of a bespoke
`tables-roles-access-query`
- Boolean soup collapsed into a single `TableDataApiStatus`
discriminated union (`schema-not-exposed | no-grants | custom-grants |
publicly-readable | locked-by-rls | secured`) via a pure helper
- Admonition copy for `no-grants` and `locked-by-rls` updated; a table
with no policies but full grants now reads "No data will be returned via
the Data API as no RLS policies exist on this table." instead of the
earlier self-contradictory "can be accessed but no data will be
returned"
- `table-api-access-query.ts` now exposes a `grantStatus: 'granted' |
'custom'` on `access` entries — `granted` = all 3 API roles × all 4 CRUD
privileges (matches `getTableGrantsCTEs` in pg-meta)
**Added:**
- New `custom-grants` admonition: "This table has custom Data API
permissions — access may be restricted for some roles or operations."
- Unit tests for `getTableDataApiStatus`, `getTableAdmonitionMessage`,
and `isFullyGranted`
**Removed:**
- `data/tables/tables-roles-access-query.ts` and the `rolesAccess` key —
no more callers
## To test
On a project with the `public` schema exposed, for each scenario check
the admonition shown on `/project/{ref}/auth/policies`:
1. Table with full standard grants, RLS on, no policies → "No data will
be returned via the Data API as no RLS policies exist on this table."
2. Table with full standard grants, RLS off → yellow warning "can be
accessed by anyone"
3. Table with partial grants (e.g. only `GRANT SELECT ON t TO anon`) →
new "custom Data API permissions" admonition regardless of RLS state
4. Table with no anon/authenticated/service_role grants → "cannot be
accessed via the Data API"
5. Schema not in the exposed list → "schema not exposed" admonition with
link
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Tests**
* Added unit tests covering table Data API/RLS status classification and
API grant validation.
* **Refactor**
* Introduced a unified per-table API/RLS status model and reusable
utilities to derive display status and admonitions.
* Simplified UI logic to drive access indicators and warnings from the
new status.
* **Chores**
* Removed legacy role-based access query and its related keying logic.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
Preserve `formattedError` through the `ResponseError` path and fall back
to splitting `error.message` on newlines so enhanced permission-denied
HINTs from supabase/postgres#2084 render as separate lines in the SQL
editor — users can actually read the GRANT example now.
**Context:** postgres#2084 adds a multi-line HINT to SQLSTATE 42501
errors, telling users exactly how to grant access per-table. Today the
SQL editor rendered the whole thing on one line because `formattedError`
was stripped by the fetchers' error handling and the `message` fallback
didn't split on `\n`. This PR fixes both.
Blocks [FE-3023](https://linear.app/supabase/issue/FE-3023) — the
project-creation toggle that flips default privileges; without readable
HINTs users land on RLS debugging rabbit holes when they hit a
permission denied.
**Changed:**
- `ResponseError` now carries an optional `formattedError` field;
`ConnectionTimeoutError` / `UnknownAPIResponseError` thread it through.
- `handleError` in `data/fetchers.ts` extracts `formattedError` from the
raw error body and forwards it to the thrown subclass.
- `UtilityTabResults.tsx` uses a new `getSqlErrorLines` helper — prefers
`formattedError`, falls back to splitting `message` on newlines when
it's multi-line (defense in depth since the exact field pg-meta
populates for the HINT depends on the path). Copy button now uses the
same lines.
**Added:**
- `getSqlErrorLines` pure helper + 9 unit tests.
- 5 new tests in `handleError.test.ts` covering `formattedError`
preservation on classified and unclassified errors.
## To test
1. Pull the branch, run `pnpm dev:studio`, open any project's SQL
editor.
2. Run a query that triggers the enhanced HINT (requires postgres#2084
deployed on the DB — currently staging-only). Example: `select * from
some_table_you_cant_read;` as a role without grants.
3. Expect the ERROR line, HINT line, and the `GRANT ...` example to each
render on their own `<pre>` line, plus the Copy button to copy the full
multi-line text.
4. Sanity check existing single-line errors (e.g. `select * from
nonexistent_table`) still render as `Error: relation "nonexistent_table"
does not exist` in the `<p>` fallback.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
* **New Features**
* Improved SQL error message formatting in the editor for better
readability and clarity.
* **Refactor**
* Centralized error formatting logic for more consistent error
presentation across the application.
* **Tests**
* Added comprehensive test coverage for SQL error message parsing and
formatting.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
Lets self-hosted Studio toggle flags in `enabled-features.json` at
container start time via `ENABLED_FEATURES_*` env vars, without
rebuilding the prebuilt image. Addresses
[FE-3036](https://linear.app/supabase/issue/FE-3036/allow-enabled-featuresjson-flags-to-be-overridden-via-env-vars)
and is a prerequisite for
[COM-205](https://linear.app/supabase/issue/COM-205/add-feature-flag-to-disable-all-logs-in-studio).
**Added:**
- `packages/common/enabled-features/overrides.ts` — pure parser that
maps `ENABLED_FEATURES_*` env vars to a disabled-features list
(forward-only key mapping, boolean validation, typo warnings) + 10
vitest tests
- `apps/studio/pages/api/enabled-features-overrides.ts` — Next.js API
route reading `process.env` at request time; no-op (`{
disabled_features: [] }`) when `IS_PLATFORM`
- `apps/studio/data/misc/enabled-features-override-query.ts` — React
Query hook with `staleTime: Infinity`, `enabled: !IS_PLATFORM`
- `packages/common/enabled-features/README.md` — docs the env var
convention, resolution order, `IS_PLATFORM` gating, and the
`Support.constants.ts` build-time caveat
**Changed:**
- `apps/studio/hooks/misc/useIsFeatureEnabled.ts` — merges the
override's `disabled_features` with `profile.disabled_features`
### Env var shape
One var per flag, prefixed `ENABLED_FEATURES_`. Feature key → env name:
uppercase with every non-alphanumeric char replaced by `_`.
```bash
ENABLED_FEATURES_LOGS_ALL=false
ENABLED_FEATURES_BRANDING_LARGE_LOGO=true
```
Values are `true`/`false` case-insensitively. Other values and prefixed
vars that don't match a known feature are logged and ignored.
### Resolution order (runtime, Studio only)
1. `ENABLED_FEATURES_*` (self-hosted, via API route → React Query →
hook)
2. `profile.disabled_features` (hosted, from `/platform/profile`)
3. `enabled-features.json` static value
4. Default (enabled)
`ENABLED_FEATURES_OVERRIDE_DISABLE_ALL` still short-circuits everything.
### Known limitation
`apps/studio/components/interfaces/Support/Support.constants.ts:4` calls
`isFeatureEnabled('billing:all')` at module load to build
`CATEGORY_OPTIONS`, which is spread into Zod form schemas. That call
site stays resolved from the JSON — documented in the package README.
`billing:all` isn't on the radar for self-hosted runtime toggling.
## To test
- `cd packages/common && pnpm exec vitest run enabled-features` — 10 new
tests pass
- `pnpm --filter studio run typecheck` clean
- Spin Studio locally with `NEXT_PUBLIC_IS_PLATFORM=false` and
`ENABLED_FEATURES_LOGS_TEMPLATES=false`;
`/project/[ref]/logs/explorer/templates` should reflect the flag after
the override fetch resolves
- Confirm the API route returns `{ disabled_features: [] }` when
`NEXT_PUBLIC_IS_PLATFORM=true`
- Set a typo like `ENABLED_FEATURES_LOGS_TMEPLATES=false` and check the
warning in container logs; flag stays enabled
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Runtime feature-flag overrides for self-hosted deployments (env var
driven), new API endpoint and client-side hook to fetch overrides, and
client logic now merges profile and runtime overrides.
* **Documentation**
* Added comprehensive README describing the feature-flag system and
override configuration.
* **Tests**
* Added unit tests for override parsing and E2E tests covering runtime
override behavior.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
## What kind of change does this PR introduce?
Feature. Resolves DEPR-430.
## What is the current behaviour?
The homepage Advisor summary, shared Advisor panel, and top-nav Advisor
indicator only surface lints and notifications. Banned IPs are not
represented as dismissible Advisor items, so network bans are easy to
miss unless a user visits Database Settings directly.
The `public bucket allows listing` warning is no longer part of this PR.
That warning will move to a follow-up Splinter `WARN` lint so it can
flow through the standard lint surfaces instead of a bespoke Studio
signal path.
## What is the new behaviour?
- adds a new Advisor `signal` source for banned IPs on the platform
homepage, in the shared Advisor panel, and in the top-nav Advisor
indicator
- keeps dismissals client-side only for now, scoped by project and exact
IP fingerprint
- keeps banned IP signals at `warning` severity because they still
indicate suspicious traffic and remain actionable if a user wants to
review or remove a ban
- leaves `/project/[ref]/advisors/security` as follow-up work because
that surface is still lint-native, and banned IPs are management-plane
signals rather than Splinter lints
| After |
| --- |
| <img width="1728" height="997" alt="Mallet Toolshed
Supabase-65A60B4A-107E-4D79-B9A8-23F754BEAB08"
src="https://github.com/user-attachments/assets/c08ecbbb-c302-43bd-81bb-6ba7eb18b7b3"
/> |
## Reviewer testing notes
1. Use a throwaway project.
2. Get the database connection string for that project.
3. Attempt to connect with the wrong password 3-4 times until you hit an
`ECONNREFUSED`-style error, which should mean your IP has been banned.
4. Refresh Studio and confirm the project overview shows the new `Banned
IP address` signal.
5. Open the Advisor Center and confirm:
- the top-nav Advisor dot turns warning yellow
- the signal detail shows `Entity`, `Issue`, and `Resolve`
- `Edit network bans`, `Dismiss`, and `Learn more` are present
6. Open Database Settings > Network bans and confirm your banned IP
appears there and can be unbanned.
7. Note that `/project/[ref]/advisors/security` will not show this item.
That page is still lint-only, and this banned IP work is a short-term
client-side signal rather than a true lint.
Longer term, we likely want a more durable event model here so banned
IPs can power notifications, webhooks, emails, and other project-level
alerts.
---------
Co-authored-by: kemal <hello@kemal.earth>
Co-authored-by: Charis Lam <26616127+charislam@users.noreply.github.com>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Overhauled SQL generation across the Studio: queries and helpers now
use safer, parameterized SQL construction for more robust and consistent
behavior.
* **Bug Fixes**
* Improved trigger update flow so event values are normalized before
saving, reducing errors when modifying webhooks/triggers.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## TL;DR
the table editor definition panel was showing incomplete SQL for views
with `WITH (security_invoker = true)`
ignoring the reloption and making it easy to accidentally strip it when
recreating the view
## prob
When viewing a security invoker view in the Table Editor, the Definition
panel only showed `CREATE VIEW ... AS ...`
without the `WITH (security_invoker = true)` clause
which caused two issues:
1. the displayed SQL was incomplete and didn't match the actual view
definition
2. users copying the SQL to recreate the view would unintentionally lose
the security_invoker setting
## ex:
| Before | After |
|--------|-------|
| `create view public.exposed_api as`<br>`select id, secret from
public.rls_protected_table;` | `create view public.exposed_api with
(security_invoker = true) as`<br>`select id, secret from
public.rls_protected_table;` |
## ref:
- closes https://github.com/supabase/supabase/issues/44934
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* View definitions now show the full CREATE statement (including
materialized views and WITH (...) options) and preserve security options
like security_invoker when viewed or opened in the SQL editor.
* **Tests**
* Added end-to-end test verifying security option preservation in view
definitions and when opening them in the SQL editor.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
This PR integrates with the new marketplace db to allow Grafana (and
other partners) OAuth apps to install from the integrations page. A demo
of this working locally is available here:
https://supabase.slack.com/archives/C01GN60J0BS/p1775551752479709. End
to end flow is documented here:
https://www.notion.so/supabase/Grafana-Integration-Flow-33a5004b775f80eeaf91c098beb8071f.
TODO:
- [ ] Make sure `NEXT_PUBLIC_MARKETPLACE_API_URL` variable is set to the
new marketplace db.
- [x] Test with the `marketplaceIntegrations` enabled and disabled in
staging once https://github.com/supabase/platform/pull/31298 is merged
and available in staging.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Add OAuth "Install integration" button that detects installed
integrations and supports GET/POST install flows
* Marketplace listings now include install links, installation method,
partner info, and listing assets/logos
* **Infrastructure**
* Allow marketplace API origin for images and content in security and
image config
* Centralize marketplace types and switch marketplace data source for
more reliable listings
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
## Context
Preferred fix to this PR
[here](https://github.com/supabase/supabase/pull/44886)
On a security email template page (e.g. Reauthentication), if you edit
the Subject or Body without saving, then toggle **Enable notification**
in the Configuration card and click **Save changes**, the Content edits
are reverted to the last saved values.
## Changes involved
Opting to not invalidate the `authConfig` RQ cache on a successful
mutation when toggling the security email notification while on the
template editor page
## To test
- [ ] Open a security email template
- [ ] Make some changes to the template without saving
- [ ] Toggle the notification and save
- [ ] Ensure that the template changes are still present and not
reverted
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Optimized query cache handling for authentication configuration
updates to reduce unnecessary refresh operations.
* Enhanced type safety for form submissions in authentication settings
to prevent data validation errors.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Display tax information in the upcoming invoice breakdown.
- Show a "Tax" line item with amount and rate tooltip when tax is
successfully calculated
- Show a warning row when tax estimation fails, prompting users to
verify their billing address
- Update Current Costs and Projected Costs tooltips to indicate whether
tax is included or could not be estimated
## Test plan
- [ ] Verify tax row appears with correct amount
when `tax_status` is `calculated`
- [ ] Verify tax rate percentage shows in the tooltip (e.g., "Estimated
tax at 10%...")
- [ ] Verify warning row appears when `tax_status` is `failed`
- [ ] Verify no tax row appears when `tax_status` is `not_applicable`
- [ ] Verify "Applicable tax included." appears in Current/Projected
Costs tooltips when tax is calculated
- [ ] Verify "Tax could not be estimated and is not included." appears
in tooltips when tax fails
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Upcoming invoices now include tax details and a tax status.
* Billing breakdown shows projected tax and conditionally displays
projected totals excluding tax when applicable.
* If tax estimation fails, a “Tax — Could not be estimated” row appears
and totals reflect the failure.
* Added "Stripe Projects" as a billing partner option and clarified that
projected amounts may be explicitly null.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
## Summary
Reorder AddPaymentMethodForm and PaymentMethodSelection to use a dry run
validation → Stripe payment setup → real update flow:
- Validate address and tax ID via `dry_run: true` before touching Stripe
- Proceed with Stripe payment method creation / 3DS only if validation
passes
- Persist the customer profile update with dry run disabled after Stripe
succeeds
- Add `dry_run` support
to `useOrganizationCustomerProfileUpdateMutation`
- Add `getFormValues()` to `PaymentMethodElementRef` to read address and
tax ID form state
- Delete the now-unused `organization-tax-id-update-mutation.ts`
## Test plan
### Adding a Payment Method
From the billing dashboard `/org/_/billing`:
- [ ] Add a payment method with a valid tax ID: should dry-run
validate, then create the payment method via Stripe, then persist the
billing profile
- [ ] Add a payment method with an invalid tax ID: should show a
validation error from the dry run and not proceed to Stripe payment
setup
- [ ] Add a payment method with the "primary billing address" checkbox
unchecked: should skip the customer profile update entirely and only
create the payment method
- [ ] Add a payment method where Stripe 3DS fails: billing profile
should not be persisted (only the dry run ran)
### Credit Top Up
- [ ] Top up credits with a new payment method and valid tax ID: should
dry-run validate, then create the payment method, then process the
top-up
- [ ] Top up credits with a new payment method and invalid tax ID:
should show a validation error from the dry run and not proceed to
Stripe payment method creation
### Plan Upgrade
- [ ] Upgrade plan with a new payment method and valid tax ID: should
dry-run validate before creating the payment method
- [ ] Upgrade plan with a new payment method and invalid tax ID: should
show a validation error and not proceed to Stripe
- [ ] Upgrade plan with an existing payment method: should proceed
without dry-run validation
## 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 connects the Advisor from the splinter repo. Below are the list of
changes:
- Register advisor which should appear in both the legacy Advisors and
Advisors sidebar.
- Adds a "Dismiss" button to the admonition inside the bucket view.
- Makes the check for select policy on public buckets tiny bit
stricter/truer.
This is awaiting the [PR](https://github.com/supabase/splinter/pull/152)
in splinter going in!
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added a security lint that flags public storage buckets allowing
listing, with a direct "View bucket" link.
* Users can dismiss public-bucket warnings per project+bucket for 14
days via a Dismiss button.
* **Improvements**
* Tightened policy detection to better target bucket-scoped select
policies and avoid unrelated matches.
* **Telemetry**
* Added events for policy removal and dismiss-button clicks.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Danny White <3104761+dnywh@users.noreply.github.com>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
- Call the new `POST /platform/organizations/preview-creation` endpoint
when creating an organization on a paid plan to show a tax breakdown
before submission
- Preview is triggered reactively when the user completes the billing
address in the Stripe AddressElement (debounced, same pattern as
subscription upgrades)
- Displays plan price, tax line (with percentage), and total due today -
hides the plan price row when there's no tax adjustment
## Test plan
- [ ] Create a new org on the Free plan - no preview should appear
- [ ] Create a new org on Pro/Team - fill in billing address with all
fields including name
- [ ] Verify tax preview appears after address is complete (1s
debounce)
- [ ] Verify tax line shows for taxable jurisdictions (NY Zip Code
10001), hidden for non-taxable
- [ ] Verify plan price row is hidden when total equals plan price (no
tax)
- [ ] Change address country - verify preview updates
- [ ] Add a tax ID - verify preview updates
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Pricing preview during organization signup that shows plan price
differences, tax details (rate/amount or estimation failure), and “Total
due today.”
* Preview updates reactively based on selected plan and spend cap (PRO
without spend cap treated as PAYG) and appears only for paid plans after
preview initialization.
* Debounced billing address and tax ID input collection for accurate
previews; panel opacity reduced while fetching.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Summary
- Reset the table rows query after the user confirms loading data on a
high-cost table, so React Query re-executes the fetch without the
preflight check
- Close the confirmation dialog after the user clicks "I understand,
proceed"
**Root cause:** `preflightCheck` is intentionally excluded from the
React Query query key (to avoid duplicate cache entries). When the user
clicked "Load data", the preflight flag flipped to `false` but the query
key stayed the same — so React Query returned the cached error instead
of refetching.
## Test plan
- [x] Navigate to a table with high estimated query cost (triggers "Data
not loaded to protect database performance")
- [x] Click "Load data" → "I understand, proceed"
- [x] Verify the dialog closes and table data loads
- [x] Verify the warning does not reappear for the same table in the
same session
To test this you can run this locally with COST_THRESHOLD set to a low
value (< 10)
Fixes FE-2979
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Confirming the high-cost warning now closes the dialog and proceeds
with loading as expected.
* Improved query cache key composition so queries reflect the full set
of relevant parameters for correct caching.
* Loading from the grid error now properly clears related cached results
and proceeds when the user confirms.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Summary
- Consolidate tax ID saving into the `PUT
/organizations/{slug}/customer` endpoint instead of using a
separate `/tax-ids` endpoint
## Test plan
### Updating billing information
From the billing dashboard`/org/_/billing`:
- [ ] Manually test updating billing address + tax ID from org billing
settings - single API call should save both
- [ ] Clear the Tax ID in the org, save and assert that it has been
deleted
- [ ] Modify all the fields in the address form, including TaxID. Click
"Cancel" and assert that everything has returned to the previous values.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Billing address and tax ID updates are now sent in a single update
operation.
* Error messaging for billing updates consolidated into a single failure
notification.
* Tax ID handling clarified: you can clear tax ID explicitly or leave it
unchanged; omitting address fields no longer overwrites existing
address.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Show OAuth server endpoints in oauth server settings page.
Preview: [OAuth Server
settings](https://studio-staging-git-chore-show-oauth-server-endpoints-supabase.vercel.app/dashboard/project/_/auth/oauth-server)
<img width="1138" height="496" alt="Screenshot 2026-01-09 at 12 00 31"
src="https://github.com/user-attachments/assets/eeca7726-0426-4abe-990d-271b702e4f7b"
/>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added an OAuth endpoints table showing Authorization, Token, JWKS, and
Discovery/OpenID URLs with copy-to-clipboard and a masked preview mode.
* Inline preview of the Authorization URL when an authorization path is
set.
* **Improvements**
* Reorganized OAuth server settings for clearer enable/disable flow,
conditional field visibility, and disable confirmation.
* Dynamic loading of the endpoints table, improved loading skeletons,
layout refinements, and form reset to reflect saved defaults.
<sub>✏️ Tip: You can customize this high-level summary in your review
settings.</sub>
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
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?
Refactor based on https://github.com/supabase/platform/pull/31325
## What is the current behavior?
We presented a page to Stripe users to let them either pick an existing
org or create one.
## What is the new behavior?
We're forcing them to create a new one (or show that there was one
already linked).
- It also adds the option to sign out when there's a conflict. Fixes
https://linear.app/supabase/issue/API-963/add-a-button-to-logout-from-the-page-you-must-be-logged-in-as-x-to
- And adds the link to root from the logo.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added organization preview creation endpoint for billing workflows.
* **Bug Fixes**
* Removed organization-picking flow from Stripe Projects login; users
now proceed directly with confirmation.
* Added a "Sign out" button on error pages.
* **Refactor**
* Removed a legacy billing partner option.
* Made the Supabase logo clickable for quick navigation.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>
Fixes#44587
index-delete-mutation.ts and index-create-mutation.ts construct SQL
using raw string interpolation for identifiers (schema, table, column
names) without escaping double quotes. Uses ident() from
@supabase/pg-meta/src/pg-format, same utility already used in the
database-queues mutations.
## Summary by CodeRabbit
* **Refactor**
* Improved identifier quoting/escaping for creating and dropping
database indexes to ensure consistent, safer index operations.
---------
Co-authored-by: Charis Lam <26616127+charislam@users.noreply.github.com>
## Problem
The disk throughput chart on the database observability report was gated
to Team plan and above. This prevented Free and Pro tier users from
seeing disk throughput data, which is a useful self-debugging aid when
hitting DiskIO-related resource exhaustion, especially on smaller
instances where baseline throughput limits are a major constraint.
The gate was originally introduced to reduce load on the metrics
infrastructure while observability queries were being scaled. That
constraint no longer applies.
## Fix
Remove the `entitlement` and `requiredPlan` fields from the
`disk-throughput` chart config in
`apps/studio/data/reports/database-charts.ts`. The rendering logic in
the database observability page only shows the upsell prompt when
`chart.entitlement` is set, so removing it makes the chart render
unconditionally for all tiers.
## How to test
- Open the database observability report at
`/project/<ref>/observability/database` on a Free or Pro project
- Confirm the Disk Throughput chart is visible and showing data (not an
upsell card)
- Confirm the chart still works correctly on a Team or Enterprise
project
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Removed plan-based access restrictions from disk-throughput metrics,
making them available to all users.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Summary
- Passes billing address and tax ID from the payment form to the
subscription preview endpoint, so taxes are recalculated live as the
user updates their details
- Debounces address/tax ID changes (1s) in `NewPaymentMethodElement` to
avoid excessive API calls while typing
- Decouples the preview refetch from the payment form's mount state -
uses `keepPreviousData` so the form stays mounted and the breakdown dims
with `opacity-50` instead of unmounting/remounting during refetches.
Shimmer skeleton only shows on initial load.
- Disables the "Confirm upgrade" button while a refetch is in progress
to prevent submitting with stale tax data
- Respects the "Use address as my org's billing address" checkbox: the
preview should mirror what will actually happen - if the checkbox is
unchecked, the address won't be saved to Orb, so it shouldn't be used
for the tax estimate either. Otherwise the user sees one price and gets
charged another. The logic for this lives in `PlanUpdateSidePanel`
``` mermaid
flowchart TD
A[User opens upgrade dialog] --> B[Fetch subscription preview]
B --> C[Show payment form + price breakdown]
C --> D[User edits address or tax ID]
D -->|1s debounce| E{Use as billing address?}
E -->|Yes| F[Re-fetch preview with new address]
E -->|No| G[Re-fetch preview without address override]
F --> H[Update breakdown — form stays mounted]
G --> H
H --> C
```
## Test plan
- [x] Open the plan upgrade dialog, verify the payment form and
breakdown load normally on first open
- [x] Change the billing address country - verify the breakdown dims
briefly and updates with new tax amounts without the payment form
unmounting
- [x] Toggle the tax ID on/off and change its value - verify the
preview refreshes after ~1s debounce
- [x] Confirm the upgrade button is disabled while the preview is
refetching
- [x] Uncheck "Use address as my org's billing address" - verify the
preview refetches without address/tax overrides
- [x] Re-check the checkbox - verify the preview refetches again with
the current form address
- [x] Assert that adding a new billing address in the CreditTopUp form
works and saves the address
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Payment and subscription flows now propagate billing address and tax
ID via new callbacks; subscription preview requests include these values
and preserve prior results while fetching.
* Preview updates are debounced to reduce noise; loading state disables
confirm actions and visually dims charge breakdown.
* **UX**
* Address input emits complete normalized address updates (empty second
line cleared).
* Tax ID input emits updates and explicit clears (null).
* “Use address as my org's billing address” is now controlled and
reports changes.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
saltcod