## feat(sso): improve SSO management UX (safe deletion + invitation type
selection)
This PR improves the SSO management experience by introducing a safer
deletion flow for SSO providers and allowing explicit control over
invitation authentication type.
## SSO Provider Deletion Improvements
The SSO provider deletion flow has been redesigned to better communicate
the impact of the action and prevent accidental destructive operations.
### UX Improvements
* Replace `ConfirmationModal` with `TextConfirmModal` in `SSOConfig`
* Require typing the SSO domain to confirm deletion
* Display the number of organization members authenticating via SSO who
will be removed
* Add destructive visual styling and clear warnings about irreversible
consequences
* Update confirmation button label to emphasize impact:
* `I understand, delete SSO provider and members`
### Warning Content
The modal now clearly communicates:
* The domain being deleted
* That SSO authentication will be disabled
* That SSO-authenticated members will be permanently removed
* That those members must be re-invited to regain access
If SSO members exist, a highlighted destructive warning box shows:
```
X organization member(s) who authenticate via SSO will be permanently removed
```
### Implementation Details
* Add `useOrganizationMembersQuery` to fetch organization members
* Calculate SSO members by filtering `is_sso_user === true`
* Only display the member warning when the count > 0
* Modal uses `variant="destructive"` and `size="small"`
This pattern follows the existing **Delete organization** confirmation
flow.
### Initial Delete Support
This PR also introduces the underlying deletion functionality:
* Add `useSSOConfigDeleteMutation`
* Add delete button (trash icon, danger styling) in the SSO config
footer
* Layout mirrors `CustomDomainDelete` pattern:
* delete button on the left
* save/cancel actions on the right
* Success toast shown after deletion
* Form resets to explicit default values after deletion
## Invitation Type Selection
Organizations with SSO configured can now explicitly choose the
authentication method when inviting new members.
Previously, invitations always inherited the inviter's authentication
method. This made it difficult to support mixed authentication
organizations.
### New Invitation Options
When SSO is enabled, the invite dialog now shows an **Invitation type**
dropdown:
* **Automatic (based on your account)**
Default behavior; inherits authentication method from the inviter.
* **Require SSO authentication**
Sends an SSO invitation.
* **Email/password authentication**
Sends a non-SSO invitation.
### Implementation Details
* Add `useOrgSSOConfigQuery` to detect if SSO is configured
* Add `requireSso` field to the form schema with enum:
* `auto`
* `sso`
* `non-sso`
* Only display the dropdown when the organization has an SSO provider
* Transform form values before sending to the backend:
```
sso -> { requireSso: true }
non-sso -> { requireSso: false }
auto -> {} (omit parameter)
```
* Update `OrganizationCreateInvitationVariables` to include optional
`requireSso`
* Preserve backward compatibility by only sending the field when
explicitly set
## Bug Fixes
* Attribute mapping preset buttons (Azure, GSuite, Okta) now properly
mark the form as dirty so the save button becomes enabled
* Form reset after deletion now uses explicit default values instead of
the last saved state
## Problems Solved
This PR addresses several UX issues:
1. Deleting an SSO provider previously used a simple confirmation with
no explanation of impact
2. Users could not see how many members would be affected by deletion
3. The destructive and irreversible nature of the action was not
visually emphasized
4. Invitations always inherited the inviter's auth method
5. Organizations could not intentionally mix SSO and non-SSO users
## Types
TypeScript types in `api-types` were updated to support the new
`require_sso` parameter.
---------
Co-authored-by: Chris Stockton <chris.stockton@supabase.io>
Co-authored-by: Ali Waseem <waseema393@gmail.com>
Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>
(working with @charislam @awaseem on this one)
## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
Per
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md):
- ✅ `pnpm --filter studio build`
- ✅ `pnpm test:prettier`
- ✅ `pnpm format`
## What kind of change does this PR introduce?
Instruments `studio` app's table creation flow with Sentry.
## What is the current behavior?
The table creation flow isn't instrumented in detail, which means we
have less visibility into understanding performance problems or errors
within this specific flow.
## What is the new behavior?
The table creation flow is instrumented in detail. This instrumentation
allows for Sentry dashboards like this one (created based on locally
generated Supabase data), to help monitor anything going wrong with this
critical flow:
<img width="1915" height="1131" alt="image"
src="https://github.com/user-attachments/assets/e2c5380e-7b00-41c1-9109-3ee4e47ff63b"
/>
---------
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?
GitHub action permissions have changed, so because of that We need to
apply permissions on the parent
## Problem
Since the upgrade to NextJS 16.1.6, many e2e tests run fails with
timeout, probably when building or starting the studio
## Solution
- [x] Add dedicated steps for supabase setup and NextJS build to ease
debugging
- [x] Fix flakyness
## 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?
As we now have the internal error code mapping in `shared-data`, thought
it better to move away from the GraphQL endpoint and leave that for
external use. The error code popovers in studio now rely on shared-data,
meaning instant loads and no rate limiting.
When the dashboard hits a DB connection timeout, users currently see a
raw error message with no
path forward. This PR adds an inline troubleshooting system that detects
known error types and
surfaces contextual next steps — restart the DB, read the docs, or debug
with AI.
## Changes
- New ErrorDisplay component (packages/ui-patterns) — styled error card
with a title, monospace error
block, optional troubleshooting slot, and a "Contact support" link that
always renders. Accepts
typed supportFormParams to pre-fill the support form.
- Error classification in handleError (data/fetchers.ts) — on every API
error, the message is tested
against ERROR_PATTERNS. If matched, handleError throws a typed subclass
(ConnectionTimeoutError
extends ResponseError) instead of a plain ResponseError. Stack traces
now show the exact error
class. All existing instanceof ResponseError checks continue to work.
- ErrorMatcher component — reads errorType from the thrown class
instance, does an O(1) lookup into
ERROR_MAPPINGS, and renders the matching troubleshooting accordion as
children of ErrorDisplay.
Falls back to plain ErrorDisplay for unclassified errors.
- Connection timeout mapping — first error type wired up, with three
troubleshooting steps: restart
the database, link to the docs, and "Debug with AI" (opens the AI
assistant sidebar with a
pre-filled prompt).
- Telemetry — three new typed events track when the troubleshooter is
shown, when accordion steps are
toggled, and which CTAs are clicked.
## Adding a new error type
1. Add a class to types/api-errors.ts
2. Add { pattern, ErrorClass } to data/error-patterns.ts
3. Create a troubleshooting component in errorMappings/
4. Add an entry to error-mappings.tsx
## Context
Related to FE-2557
Part of shifting manually written dashboard queries into
packages/pg-meta where
- pg-meta can be code owners of
- we can write tests for the queries
This PR just shifts all the `.sql.ts` files that we previously created
into packages/pg-meta
There's still other areas where we need to shift over as well which I'll
address in subsequent PRs
## Notable changes
- `getTableRowsCountSql` -> Opted to shift `formatFilterValue` logic out
before calling this method (ref `table-rows-count-query`)
- `getDeleteOldCronJobRunDetailsByCtidSql` -> Opted to shift
`validatePageNumber` logic out before calling this method (ref
`CronJobsTab.useCleanupActions`)
## What kind of change does this PR introduce?
Bug fix.
## What is the current behavior?
The file storage routes under `/project/[ref]/storage/files` all use
`Storage | Project | Org | Supabase` as the browser title, even when the
user is on a more specific tab.
## What is the new behavior?
The browser title now reflects the active file-storage tab:
- `/storage/files` -> `Files | Storage | Project | Org | Supabase`
- `/storage/files/settings` -> `Settings | Storage | Project | Org |
Supabase`
- `/storage/files/policies` -> `Policies | Storage | Project | Org |
Supabase`
Ditto for `analytics` and `vector`
## What kind of change does this PR introduce?
Refactor, cleanup, and docs update.
## What is the current behavior?
After the page-title rollout, `ProjectLayout` is still in a transitional
state:
- it accepts a deprecated `title` prop
- it still supports a separate `browserTitle.surface`
- wrapper layouts are split between passing `title` directly and passing
`browserTitle.section`
That makes the API harder to reason about than it needs to be, even
though the rendered titles are already correct.
## What is the new behavior?
This cleanup finishes the API simplification that came out of the
stacked PR review:
- wrapper layouts stay `title`-first for DX
- `ProjectLayout` no longer accepts `title`
- `product` is now the single source of truth for the project-surface
title segment
- `browserTitle` is now only used for extra browser-title metadata
(`entity`, `section`, `override`)
- the remaining project-scoped callers now pass `browserTitle.section`
when they need a section label
- docs now reflect the final pattern instead of the transitional one
Rendered page titles stay the same.
## Additional context
Checks run:
- `pnpm --filter studio exec vitest --run lib/page-title.test.ts
components/layouts/ProjectLayout/index.test.tsx`
- `pnpm --filter studio typecheck`
- `pnpm exec prettier --check ...` on touched files
This is intended as the post-rollout cleanup PR based on Joshen's review
feedback across the stacked title changes.
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
## Context
Small one - while on the database replication page, if you open the
Connect Dialog and change the "type" field, the destination panel opens
up. Happening cause the string for `useQueryState` conflicts here - both
are using `type`
Fix is just to update the string for `useQueryState` for the
DestinationPanel component, changed it to `destinationType`
`/incident-status` and `/incident-banner` are not cached because they
include auth cookies which busts Vercel cache. This PR add `credentials:
omit` since they calls don't need auth cookies and they're same for all
users.
The incident queries have been hammering statuspage and incident.io API
endpoints which has resulted in 429 and 75% of all requests failing.
This PR sets the retry on fail to 4s, 16s, 64s, 256s and 300s.
Previously it was set to 2s, 4s, 8s, 16s and 32s.
TheOtherBrian1