Refactors our help sidebar within Studio to include the actual support
form itself when contact is selected. This PR also cleans up the initial
state of the sidebar and the options within.
## To test:
- Open an org and click the help icon top right
- Click contact support
- Submit a support ticket
- Click done to return to support sidebar state
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Support form V3 and support sidebar with status button; direct-email
helper and URL prefill
* Success screen supports onFinish callback and customizable finish
label
* AI Assistant and Help options accept optional click callbacks;
resource items gain keyboard/accessibility support
* **Refactor**
* Help panel split into home/support views with back navigation
* Support components accept flexible align/className props and
layout/styling tweaks
* Initial URL params loader added for support form
* **Tests**
* New/updated tests for support flows, success screen, and help options
interactions
<!-- 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?
Bug fix — copy + visibility logic on the org Usage page.
## What is the current behavior?
On `/org/<slug>/usage` during a grace period, customers see two banners
that read as contradictory:
1. *"Organization plan has exceeded its quota — grace period until
{date}."*
2. *"You have not exceeded your Pro Plan quota in this billing cycle."*
<img width="1680" height="372" alt="image"
src="https://github.com/user-attachments/assets/13826260-55dd-4b55-a3dc-5afc51e6436e"
/>
Both are individually correct. The first is sticky from the previous
cycle's overage (`org.restriction_status`); the second is a live scan
over the current cycle. Neither anchors to which cycle it's talking
about, so together they read like the dashboard contradicting itself.
Surfaced by support off SU-368527 and SU-368395.
## What is the new behavior?
- Top chrome banner copy: *"Organization exceeded its quota in the
previous billing cycle / You have a grace period until {date} to bring
usage back under quota."*
- Inline `<Restriction />` grace-period alert switches from "is over its
quota" to "went over its quota in the previous billing cycle." Same
temporal anchor.
- The "…in this billing cycle" summary line in `<TotalUsage>` is hidden
whenever `restriction_status` is set. Mirrors the precedence rule
`<Restriction />` already applies internally — backend status flag wins
over the live cycle scan.
<img width="1678" height="937" alt="CleanShot 2026-05-06 at 12 58 02"
src="https://github.com/user-attachments/assets/df55eaed-1029-4f39-bea0-df77bcc5151e"
/>
## Additional context
Left the `gracePeriodOver` copy alone on purpose — it doesn't make a
current-overage claim, so there's nothing to contradict, and adding
"previous cycle" would muddy which cycle "previous" refers to.
**Verified**
- Lint and typecheck pass on `apps/studio`.
**Before merge**
- [ ] Load a grace-period org locally: confirm new copy on top banner
and inline `<Restriction />`, and that the "not exceeded in this billing
cycle" line is gone.
- [ ] Copy review with support — happy to workshop wording.
GROWTH-823
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Updates**
* Updated grace period alert messaging to clarify organization quota
status
* Refined date formatting in billing restriction notifications
* Modified usage display to conditionally hide certain information when
account restrictions are active
<!-- 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
* **Documentation**
* Updated UI labels and descriptions across the Data API settings to
clarify that default privileges apply to new tables only (removed
references to functions).
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Cleans up the `tableEditorApiAccessToggle` PostHog flag now that the
gated UI is shipping to everyone. Follow-up to #45034 — the new
project-creation checkbox makes the management UI a prerequisite, so no
reason to keep it behind a flag.
**Removed:**
- `useDataApiGrantTogglesEnabled` hook
- Old schemas-only multi-selector branch in the Data API settings page
(the rich per-table / per-function toggles + default-privileges switch
become the only UI)
- Flag gate around the `<ApiAccessToggle>` section in the table editor
side panel
- Flag gates around `updateTableApiAccess` calls in the save pipeline
(create / duplicate / update)
- `tableEditorApiAccessToggleEnabled` telemetry property + stale JSDoc /
docs references
**Changed:**
- `createTableApiAccessHandlerParams` no longer takes an `enabled` param
— it was always `true` after removal
## To test
- Integrations → Data API settings page: exposed tables, exposed
functions, default-privileges toggle all render and save correctly
- Table editor: creating, duplicating, and editing a table all run the
expected Data API privilege updates
- Project creation flow still works end-to-end (unchanged, but the
submit telemetry no longer includes `tableEditorApiAccessToggleEnabled`)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Improvements**
* API access configuration is now always available in the table editor
and PostgreSQL settings, removing previous conditional gating.
* Simplified the "Automatically expose new tables and functions"
interface by consolidating UI branches.
* **Documentation**
* Updated telemetry guidance and examples with current feature-flag
references.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
<img width="783" height="414" alt="Screenshot 2026-04-20 at 3 02 37 PM"
src="https://github.com/user-attachments/assets/a353c35a-3de5-4bfa-ab31-829c79c43165"
/>
Adds a "Default privileges for new entities" checkbox under "Enable Data
API" in both the main create flow and the Vercel deploy-button flow.
Default checked (current behaviour). When unchecked, runs
`buildDefaultPrivilegesSql('revoke')` after the base init script so new
entities in `public` aren't auto-granted to `anon` / `authenticated` /
`service_role`.
This PR decouples the two surfaces:
- **`tableEditorApiAccessToggle`** — unchanged; still gates only the
integrations → Data API settings UI.
- **`dataApiRevokeOnCreateDefault`** (new) — controls only the default
state of the new checkbox at project creation. `true` → checkbox
unchecked by default (revoke runs); `false`/absent → checkbox checked by
default (no behaviour change).
The new flag is already live in PostHog at **0% rollout, off for
everyone**, so shipping this PR changes nothing until the flag is
explicitly flipped.
## Added
- `apps/studio/hooks/misc/useDataApiRevokeOnCreateDefault.ts` — reads
the new PostHog flag. Returns `false` in `IS_TEST_ENV` so existing E2E
flows don't silently change default behaviour.
- Checkbox UI in `SecurityOptions.tsx` (main flow) and
`pages/integrations/vercel/[slug]/deploy-button/new-project.tsx` (Vercel
flow), with copy matching the integrations → Data API settings page.
- Tooltip + dimmed state for the main-flow checkbox when "Enable Data
API" is unchecked (can't configure default privileges if Data API is
off).
- Telemetry: `dataApiDefaultPrivilegesGranted` (raw checkbox value) and
`dataApiRevokeOnCreateDefaultEnabled` (raw flag, conditionally included
using the existing raw-flag pattern so undefined flag state → omitted
property, not `false`).
- Vitest unit tests for the new hook.
## Changed
- `pages/new/[slug].tsx`: removed the `false &&` rollback guard. Revoke
SQL now runs only when `dataApi && !dataApiDefaultPrivileges`. Dropped
the now-unused `useDataApiGrantTogglesEnabled` import.
- `pages/integrations/vercel/[slug]/deploy-button/new-project.tsx`: this
flow was **never rolled back** — it still ran revoke whenever
`tableEditorApiAccessToggle` was on for a user. Now correctly gated on
the new flag + checkbox state.
- `packages/common/telemetry-constants.ts`: added the two new properties
and corrected the `tableEditorApiAccessToggleEnabled` docstring (it no
longer claims to control project-creation revoke behaviour).
## Kill switch
Flipping `dataApiRevokeOnCreateDefault` to off in PostHog fully disables
the revoke SQL for new projects without needing a redeploy — the
checkbox just defaults to checked again.
## Follow-ups (not blockers)
- joshenlim's review comments on PR 43704: (1) Auth Policies table row
incorrectly showing "exposed via Data API" based on schema-level check
instead of table-level at
`apps/studio/components/interfaces/Auth/Policies/PolicyTableRow/index.tsx:64`;
(2) Data API integrations page showing zero exposed tables even after
exposing one. Both unrelated to this PR but will be more visible once
the checkbox lands.
- Once this flag fully rolls out, the old `tableEditorApiAccessToggle`
docstring/comments elsewhere should stop claiming it controls project
creation.
## To test
- **Flag off (default state, simulates post-merge):** create a project
with and without "Enable Data API" checked. The new "Default privileges
for new entities" checkbox should default to **checked**. Submitting
should produce an identical result to today — new tables in `public` are
reachable via the Data API.
- **Flag on (simulate rollout):** override the flag locally. The
checkbox should default to **unchecked**. Creating a project with it
unchecked should run the revoke SQL; create a new table in `public`
afterwards and confirm it's not reachable via the Data API until grants
are added.
- **Enable Data API off:** the new checkbox should render disabled +
dimmed with a tooltip reading "Enable the Data API to configure default
privileges." The revoke SQL should not run in this case regardless of
checkbox state.
- **Vercel flow:** repeat at
`/integrations/vercel/<slug>/deploy-button/new-project` — verify both
checkbox states.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added an "Automatically expose new tables and functions" checkbox to
project creation and Vercel deploy flow; enabled only when Data API is
available (disabled with tooltip otherwise) and affects initial project
provisioning.
* **Telemetry**
* Tracks exposure of the default-privileges control and includes
checkbox state and feature-flag status on project-creation submissions.
* **Tests**
* Added tests for flag behavior, exposure tracking, deduplication, and
submission telemetry.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
Co-authored-by: Sean Oliver <882952+seanoliver@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>
## 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?
Advisor dismissals use `useLocalStorageQuery`. When advisor signals
pruning ran, it sometimes invoked `setDismissedKeys` even when nothing
needed to change (no-op updater returning the same array reference).
Separately, `useLocalStorageQuery` would still persist +
`invalidateQueries` even when the computed next value was
reference-equal to the current cached value.
When `useAdvisorSignals` is mounted in two places at once
(`AdvisorSection` + `AdvisorPanel`), those redundant invalidations /
subscriber churn could occasionally cascade into React’s “Maximum update
depth exceeded” error (often surfaced via Radix `composeRefs` in stack
traces). CI saw this as an unhandled error during
`AdvisorSignals.integration.test.tsx`.
## What is the new behavior?
- `useLocalStorageQuery` now **early-returns** when `Object.is(next,
current)` so no-op updates don’t write localStorage or invalidate the
query.
- `useAdvisorSignals` pruning effect now **short-circuits** unless there
is actually a stale banned-IP dismissal to remove.
## Additional context
Follow-up from #44372 (advisor signal items for banned IPs).
Tests run locally:
- `pnpm --filter studio exec vitest run
components/ui/AdvisorPanel/useAdvisorSignals.test.tsx
components/ui/AdvisorPanel/AdvisorSignals.integration.test.tsx
hooks/misc/__tests__/useLocalStorageQuery.test.ts`
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Enhanced handling of dismissed security alerts by preventing
unnecessary state updates for stale dismissals, significantly reducing
overhead and improving overall application performance.
* Optimized local storage operations to skip redundant writes to storage
and prevent triggering unnecessary cache updates and query invalidations
when stored data values remain unchanged from the previous operation.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## 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>
Simplify the Connect modal for Multigres/High Availability projects.
Pooling is always on for these projects, so the connection method
distinction doesn't apply.
**Removed:**
- Connection Method selector (Direct/Transaction/Session) for HA
projects
- IPv4 add-on panel for HA projects
- Pooler badge (Shared/Dedicated) for HA projects
**Changed:**
- "Type" label renamed to "Connection Type" for HA projects
- Default connection method set to `transaction` (instead of `direct`)
for HA projects
Non-HA projects are completely unaffected.
## To test
- Open Connect sheet → Direct tab on a **non-HA project** — verify
everything looks the same as before
- Open Connect sheet → Direct tab on an **HA project** — verify:
- No Connection Method radio selector
- Label reads "Connection Type" instead of "Type"
- No IPv4 status panel
- No pooler badge
- Connection string displays correctly
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Improvements**
* Connection UI now adapts for high-availability projects: hides pooler
options and IPv4 status, and updates the connection type label for
clarity.
* **Tests**
* Added tests covering connection configuration behavior when a project
is high-availability.
<!-- 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?
Bug fix / UX improvement for long-running project transitions. Resolves
DEPR-362.
## What is the current behaviour?
- `PausingState` does not preserve elapsed time across refreshes, so the
stuck escalation can disappear for the same user.
- `RestoringState` relies on weaker frontend heuristics and always
showed a support CTA in the footer even before the restore was clearly
long-running.
## What is the new behaviour?
- `PausingState`
- Persists a per-project pause start time in local storage so the stuck
CTA survives refreshes in the same browser.
- Escalates after 10 minutes.
- Clears the stored timer when pausing succeeds or fails.
- `RestoringState`
- Persists a per-project restore start time in local storage so the
stuck CTA survives refreshes in the same browser.
- Removes the always-visible footer CTA and only escalates once
restoration is genuinely long-running.
- Computes the long-running threshold from volume size using a shared
restore estimate: `max(10, ceil(estimateRestoreTime(sizeGb) * 1.5))`.
- Clears the stored timer when restoration succeeds or fails.
- Shared changes
- Extracts reusable transition timing helpers and restore estimate
helpers with unit tests.
- Reuses the same restore estimate formula for branch restore timing and
restore escalation, so the two do not drift.
| `PausingState` | `RestoringState` |
| --- | --- |
| <img width="1570" height="906" alt="Krosno Toolshed
Supabase-C6D7E29F-C38D-43E1-8AF9-C612B6A2FD8D"
src="https://github.com/user-attachments/assets/e0bd9434-09b6-4cf6-bffa-07a0ddcdf5db"
/> | <img width="1570" height="906" alt="Krosno Toolshed
Supabase-51F4763D-B798-4B41-A92D-43B3CF8ECDAF"
src="https://github.com/user-attachments/assets/d0e47356-dcc3-42aa-b602-802a35249a16"
/> |
## Additional context
- This PR intentionally stays frontend-only.
- We are not exposing backend lifecycle timestamps here; local storage
is the stopgap to improve the same-browser experience now.
- If you need to test the frontend blocker states locally, use
[`dnywh/chore/depr-362-blocker-preview-mocks`](https://github.com/supabase/supabase/tree/dnywh/chore/depr-362-blocker-preview-mocks)
and append one of the following query params to a project URL:
- `?mockProjectBlockingState=pausing`
- `?mockProjectBlockingState=pausing-long-running`
- `?mockProjectBlockingState=restoring`
- `?mockProjectBlockingState=restoring-long-running`
- I know these two views are quite differently stylistically, and will
consolidate later
- References DEPR-434
* **Chores**
* Updated internal module import paths across hook files to use
standardized path aliases for improved code consistency and
maintainability.
## Problem
The Query Performance page loaded all results in a single query with a
fixed limit of 20 rows, giving users no way to browse beyond the first
page. There was also no way to control how many rows were shown at once.
## Fix
adds pagination
## How to test
- Navigate to `/observability/query-performance` in Studio
- scroll to bottom
- should automatically load more results
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Problem
The database observability dashboard flattens critical spikes when
viewing the 7-day window. A spike clearly visible at the 3-hour view
(2-minute resolution) disappears completely at the 7-day view because
the Prometheus query step was 1 hour, averaging each spike into a
60-minute bucket and reducing its apparent magnitude to near zero.
## Fix
Increase the granularity in the 7 day window to prevent spikes from
being flattened.
Data point counts: 7-day view goes from ~168 to ~336 points per series,
more consistent with the existing 12-hour view (~360 points).
## How to test
- Open the observability database dashboard for a project that has had a
recent CPU, RAM, or connection spike
- Select the "Last 3 hours" time window and confirm the spike is visible
- Switch to "Last 7 days" and confirm the same spike is now visible
(previously it would disappear)
- Confirm all other time windows (10m, 30m, 1h, 24h) still load and
display correctly
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
This PR fixes some prettier issues:
- Bump and unify all prettier versions to 3.7.3 across teh whole repo
- Bump the SQL prettier plugin
- When running `test:prettier`, check `mdx` files also
- Run the new prettier format on all files
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
### Summary
This PR adds a dismissable modal that prompts paid org users to fill in
their billing address. We need billing addresses for tax compliance and
the existing banner hasn't been as effective (~10k orgs still missing).
The modal shows on page load when all of these are true:
- ConfigCat flag `enableBillingAddressModal` is on
- Org is on a paid plan (not free)
- Org does not have billing address set
- Org is not partner-managed
- User has BILLING_WRITE permission on stripe.customer
The modal can be dismissed via the close button, but re-opens on every
page navigation.
Once the user saves a valid address, the organizations query is
invalidated and organization_missing_address flips to false - the modal
stops appearing permanently.
<img width="1256" height="703" alt="Screenshot 2026-03-05 at 4 22 11 PM"
src="https://github.com/user-attachments/assets/57e7d1b8-b3b6-4366-ad23-60910a0defe8"
/>
### Testing
#### Automated Tests
I've added unit tests in this PR
#### Manual testing
Manual test cases:
- Free org - modal does not appear
- Partner-managed org - modal does not appear
- User with "developer role" modal does not appear
- Configcat Flag disabled - modal does not appear
- Dismiss modal, navigate to another page - modal re-opens
- Fill form and save - modal closes and does not reappear
- API failure loading billing data - shows error state with Retry button
---------
Co-authored-by: Ignacio Dobronich <ignacio@dobronich.com>
## 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
### 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"
/>
### Changes
- Remove maybeShowUpgradePrompt (plan-based) in favor of
maybeShowUpgradePromptIfNotEntitled (entitlement-based)
- Replaced the `maybeShowUpgradePrompt` with a `hasAccessToHelper`
callback to default the date selection to a safe default so pages don't
load with an out-of-range date.
### Testing
- With an Org on the Free Plan, head to
`/project/_/observability/api-overview?its=2026-03-04T15:06:50.704Z&ite=2026-03-20T15:06:50.704Z`.
Notice that the end date in the URL is 16 days after the start date.
- Assert that the actual range defaults to the entitled range of 1 day.
<img width="467" height="483" alt="image"
src="https://github.com/user-attachments/assets/e17c6957-3ece-4956-87aa-30cf62c84acd"
/>
## Context
Follow up from https://github.com/supabase/supabase/pull/43329, but
mutually exclusive
Just cleaning up feature flags that have been toggled on for all users
and unchanged for the past 2 months
- edgefunctionreport
- storagereport
- realtimeReport
- postgrestreport
- authreportv2
- newEdgeFunctionOverviewCharts
- apiReportCountries (Already not used)
- SentryLogDrain
- reportGranularityV2
- storageAnalyticsVector
- ShowIndexAdvisorOnTableEditor
## What kind of change does this PR introduce?
UI improvement
## What is the current behavior?
The session expired dialog is quite hard to parse when, for most people,
the ask is simple.
## What is the new behavior?
Improved session expired dialog:
- Refactored to use AlertDialog
- Clarified copywriting
- Uses the new AlertCollapsible to hide all the complicated debugging
steps under a toggle
- This component is documented in the design-system
| Before | After |
| --- | --- |
| <img width="1024" height="563"
alt="Supabase-B1728A05-DDD2-4A50-AED4-D62EAA2E7D7C"
src="https://github.com/user-attachments/assets/771f85d8-21ea-42b5-99f5-b9b05f5617dd"
/> | <img width="1024" height="563" alt="Storage Supabase"
src="https://github.com/user-attachments/assets/b2fcab68-fb29-4cb9-bd42-aecc57b9fa32"
/> |
| <img width="1024" height="563"
alt="Supabase-B1728A05-DDD2-4A50-AED4-D62EAA2E7D7C"
src="https://github.com/user-attachments/assets/771f85d8-21ea-42b5-99f5-b9b05f5617dd"
/> | <img width="1024" height="563" alt="Storage Supabase"
src="https://github.com/user-attachments/assets/babd3711-5fdf-43b9-be06-d96268a191fd"
/> |
## To test
In apps/studio/hooks/misc/withAuth.tsx:
```diff
- const [isSessionTimeoutModalOpen, setIsSessionTimeoutModalOpen] = useState(false)
+ const [isSessionTimeoutModalOpen, setIsSessionTimeoutModalOpen] = useState(true) // Mocked as true for UI testing
```
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
Adds the Realtime max message size entitlement
### Testing
- Head to `project/_/realtime/settings` with an Org on the Pro with the
Spend Cap disabled
- Assert that the `Max payload size in KB` cannot exceed 3000
- Repeat the steps for max concurrent users and max presense events per
second
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Realtime settings now automatically reflect your subscription
entitlements with dynamic maximums for payload size, concurrent user
limits, and event rates.
<sub>✏️ Tip: You can customize this high-level summary in your review
settings.</sub>
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Feature
## What is the current behavior?
Data API settings live under Project Settings.
## What is the new behavior?
Data API settings are moved to the Integrations page, treating Data API
as a platform integration. Includes security checks when toggling on the
Data API to prevent unintended exposure of project data.
## Additional context
Towards FE-2517
## Summary by CodeRabbit
* **New Features**
* Added a Data API integration with Overview and Settings pages,
endpoint display, and enable/disable toggle with safety checks and
confirmation flow.
* **Navigation Changes**
* Data API moved from Project Settings into the Integrations area and
routes now redirect to the new Overview page.
* **Documentation**
* Added an overview doc describing Data API endpoints and configuration.
* **Tests**
* Added unit tests for endpoint resolution and schema parsing utilities.
Cleanup / chore — removing a feature flag that has been at 100% rollout
with no issues.
## What is the current behavior?
The `dataApiExposedBadge` feature flag is checked at runtime via
ConfigCat, even though it has been set to 100% for a while with no
issues.
## What is the new behavior?
The feature flag check is removed and the gated behavior is now
unconditionally enabled. A reminder has been set to delete the flag from
ConfigCat in a month.
## Summary by CodeRabbit
**Refactor**
* Simplified API access status indicators in the studio editor, ensuring
security-related tooltips now display consistently based on actual
access conditions.
* Updated component interfaces and consolidated internal hook
dependencies for improved code maintainability and organization.
Problem:
- new filters are creating an infinite fetch loop of ph.supabase.io
# Before:
snap.filters change → effect → setParams() → router.push()
→ URL updates → filters/sorts recalc → setParams recreated
→ effect re-runs → INFINITE LOOP 🔄
# After:
snap.filters change → effect → comparison shows change → timeout
scheduled
→ setParams() → router.push(shallow: true) → URL updates
→ filters/sorts recalc → setParams recreated → effect runs
→ comparison check: no content change → early return → LOOP BROKEN ✓
The deep comparison prevents the effect from re-executing when only the
dependency references change
(due to URL updates), not the actual filter content. Test it out and the
PostHog spam should stop!
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Bug Fixes
* **Prevented unnecessary URL updates** when filter state remains
unchanged, improving application responsiveness.
* **Optimized filter and sort parameter handling** with enhanced
callback efficiency and routing behavior.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Context
Related prior work was making edge functions page accessible while
project is restoring - however the status of the project gets flipped to
COMING_UP while it's restoring hence why the functions page was still
inaccessible.
## Changes involved
- Update `NavigationBar.utils` to have edge functions link to
`/functions` irregardless of project status
- (Unrelated) Disable (with tooltip) deploy new function CTA on edge
functions page if project is not active
<img width="403" height="108" alt="image"
src="https://github.com/user-attachments/assets/88479247-999b-4d41-a444-6705f8c3993e"
/>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Deploy Edge Function button now disables and shows a tooltip when the
project is inactive to make deployment status clear.
* **Bug Fixes**
* Edge Functions link now points consistently to the functions view
regardless of project build state.
* **Refactor**
* Consolidated project-active check and reorganized related UI wiring to
standardize inactive-state handling across settings and controls.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Context
The Integrations -> Cron overview page renders a list of cron jobs by
doing a join on both `cron.jobs` and `cron.job_run_details` in order to
pull the data for "Latest run" and "Status" ("Next run" is just derived
from "Latest Run" and the job's schedule)
In the past, we've had users run into issues where this query would time
out, likely due to the join on `job_run_details` especially if that
table is really big (and the columns on that table aren't indexed), and
our solution was to inform users to clear out that table + schedule a
job to clean the `job_run_details` table on a certain cadence. This CTA
however blocks the UI from rendering the cron jobs overview entirely
<img width="1644" height="590" alt="image"
src="https://github.com/user-attachments/assets/1a0458e9-f686-452b-88bc-44459bc7c615"
/>
## Changes involved
Am opting to use the new preflight check introduced
[here](https://github.com/supabase/supabase/pulls?q=is%3Apr+author%3Ajoshenlim+is%3Aclosed)
- Attempt to fetch the data for the cron jobs overview normally
- If preflight check rejects (due to high cost), then opt to fetch the
data while omitting the join
- Show a banner instead to inform the user accordingly
- So that way users can still view their cron jobs (the latest run
column is a nice to have convenience really)
<img width="1151" height="379" alt="image"
src="https://github.com/user-attachments/assets/72cfaafb-e951-4601-b54e-c36a6f36332d"
/>
- Clicking learn more will then open a dialog to explain what this is
all about
- The steps to clear the `job_run_details` table + schedule a clean up
job still remains
<img width="450" height="484" alt="image"
src="https://github.com/user-attachments/assets/4491e766-64a1-40c9-9703-2e8b0da11c3f"
/>
<img width="450" height="610" alt="Screenshot 2026-02-05 at 12 56 39"
src="https://github.com/user-attachments/assets/644c9a7b-5afb-46bb-8c1e-9ece3986c2fb"
/>
<img width="450" height="507" alt="Screenshot 2026-02-05 at 13 01 37"
src="https://github.com/user-attachments/assets/9f0f40f2-7376-4c28-90f1-0b21a1a4560a"
/>
- Non-UI related changes include
- Automatically refresh cron jobs after scheduling a job, remove manual
CTA to refresh the jobs after scheduling the clean up job
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Previous Runs tab on cron job pages
* Interactive "Learn more" cleanup dialog with guided delete and
schedule steps
* Close-confirmation modal when editing cron jobs
* High-cost banner that enables a lightweight "minimal" list mode
* **Bug Fixes**
* Clearer placeholder (minus icon/message) when a job has no runs
* **Performance**
* Safer, more efficient fetching and pagination for large cron job
lists; reduced retries on high-cost queries
* **Tests**
* Expanded end-to-end tests covering high-cost flows and the cleanup
dialog
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Summary
Removes two concluded A/B experiments that didn't produce positive
results:
- **tableQuickstart**: Tested AI-powered table generation, template
selection, and assistant integration for new table creation
- **realtimeButtonVariant**: Tested hiding the realtime button or
replacing it with a triggers button
## Changes
- Delete `TableQuickstart/` folder with AI widget, templates widget, and
generation hooks
- Delete `useRealtimeExperiment` hook and remove variant-conditional
logic
- Delete `/api/ai/table-quickstart/generate-schemas` endpoint
- Remove telemetry event definitions for both experiments
- Remove local storage exposure tracking key
- Remove API endpoint from proxy whitelist
- Clean up eslint baseline references
## Testing
- [x] Tested locally - Table Editor renders correctly without experiment
widgets
- [x] TypeScript compiles without errors
- [x] No remaining references to removed experiment code
**Quick test:**
1. Navigate to Table Editor → New Tab shows only "Create a table" card
(no AI/Templates/Assistant variants)
2. Open table create panel → Realtime checkbox shows unconditionally
when realtime is enabled
## Linear
fixes GROWTH-609
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Removed Features**
* AI-powered table generation and quickstart assistance (templates, AI
widget, generation hook, templates data, and related utilities)
* Quickstart templates widget and predefined table templates
* Database triggers management interface
* Realtime experiment gating and related experiment variants
* **API & Storage**
* Hosted AI quickstart API endpoint removed
* Local storage key for quickstart exposure tracking removed
* **Telemetry**
* Quickstart- and realtime-experiment telemetry events removed
* **UI Changes**
* Simplified realtime toggle control in the table editor
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Summary
Adds session-based deduplication for experiment exposure events.
Previously, exposure events used `useRef` which reset on page refresh,
causing duplicate events. Now events dedupe by PostHog session ID using
`sessionStorage`, firing once per session even across page refreshes.
## Changes
- Add `captureExperimentExposure()` method to `PostHogClient` with
session-based dedupe
- Add `getSessionId()` method to retrieve PostHog session ID
- Create `useTrackExperimentExposure` hook for clean usage
- Migrate existing experiments to new hook:
- RLS option experiment (`/new/[slug]`)
- Realtime button experiment
- Table create generate policies experiment
## How it works
1. Event triggered → if PostHog not ready, queue to `pendingExposures[]`
2. PostHog `loaded` → flush queue through `fireExposureIfNew()`
3. `fireExposureIfNew()` checks
`sessionStorage['ph_exposed:{experimentId}']`
4. If value matches current session ID → skip (already fired)
5. If differs or missing → fire event, store session ID
## Testing
- [x] Tested locally and on preview - verified on project creation page
- [x] PostHog events sent successfully (200 responses)
- [x] Session deduplication working (no duplicate events on page refresh
or org switch)
- [x] Lint passes with 0 errors
**Quick test:**
1. Go to `/new/<org-slug>` project creation page
2. Check `sessionStorage` for `ph_exposed:project_creation_rls_option`
key
3. Refresh page - event should not fire again (same session ID)
## Linear
Resolves GROWTH-608
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* More reliable experiment exposure reporting with session-aware
deduplication, queued delivery, and consent respect to ensure events are
recorded when available.
* **Bug Fixes**
* Prevents duplicate exposure events within a session and avoids firing
exposures without a valid session.
* **Refactor**
* Consolidated disparate exposure-tracking logic into a unified
hook-based approach, simplifying tracking across the app.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
* fix(studio): check job_run_details size in cron display
When cron.job_run_details grows too large (200k+ rows), loading the
cron jobs overview can timeout and affect other queries by pulling
excessive data into shared buffers.
This change:
- Estimates table size using pg_stat before fetching cron jobs data
- Shows a cleanup notice when the table exceeds the threshold
- Provides batched deletion using ctid ranges to avoid buffer pollution
- Allows scheduling an automated daily cleanup cron job
- Handles timeout errors gracefully with a "suspected overflow" state
The useCronJobsData hook now returns a discriminated union status that
tracks loading, estimate-error, overflow-confirmed, overflow-suspected,
and ready states, allowing the UI to respond appropriately to each case.
* fix(studio): use index when querying cron.job_run_details
cron.job_run_details is only indexed by runid, not by start_time. Change
the query to use the runid index (which gives the same result, since
runid is auto-incrementing).
* feat(studio): add mutation to update table access privileges
Adds a mutation to update table grants for `anon` and `authenticated`
roles.
* feat(studio): add data api toggles
Add toggles to the Table Editor, allowing fine-grained grants to the
anon and authenticated roles.
* fix(studio): don't show rls policies warning if table not exposed
RLS policies warning was showing in Table Editor side panel even if
table was not exposed due to no grants to anon/authenticated.
* fixup! feat(studio): add data api toggles
* fixup! feat(studio): add data api toggles
* fix(studio): revalidate rls lints when table grants are toggled
---------
Co-authored-by: Charis Lam <26616127+charislam@users.noreply.github.com>
* Add shimmering-loader CSS to ui-patterns.
* Import the shimmering-loader classes from the ui-patterns component.
* Remove ShimmeringLoader from studio.
* Migrate studio to use ui-patterns/ShimmeringLoader.
* Migrate away from using default import for ShimmeringLoader.
* Fix the css imports in docs and studio.
## Summary of changes
Buckets policies page at /project/_/storage/files/policies now uses the
paginated buckets endpoint to fetch buckets.
## Before
Used a non-paginated query.
## After
To support a paginated query, we now have:
- Infinite scroll loading behavior
- Fixed some of the buckets utilities to account for policy references
to buckets that haven't loaded yet
* Bump the deps, refactor deprecated code.
* Migrate keepPreviousData usage.
* Migrate all uses of InfiniteQuery.
* Fix refetchInterval in queries.
* Migrate all use of isLoading to isPending in mutations.
* Fix accessing location in claim-project.
* Fix a bug in duplicate query keys.
* Migrate all queries to use isPending.
* Revert "Fix accessing location in claim-project."
This reverts commit 2a07df64b5.
* Revert the rss.xml file to master.
Saxon Fletcher