## Problem
As part of having `None / No Access` available to customers, we need to
start providing this role entry in `/platform/organization/:ref/roles`
endpoint. However, when making it available, the role will show up
prematurely on all the components that relies on
`useOrganizationRolesV2Query` function.
## Solution
This change is to allow us to test the behavior of the new role without
having to turn the API on/off. The UI will show only the "predefined"
entries and ignore the "extras" sent by API.
After this is merged, we will do the following
1. Unhide the None role from the API
https://github.com/supabase/platform/pull/39137 -- this will not have
any effect on the frontend as we already ignore it in this PR
2. Work and continue testing on
https://github.com/supabase/supabase/pull/50922 -- which will be easier
to verify as we no longer need to change the API side
## Review instructions
1. Modify the items in the `FIXED_ROLE_ORDER` list, remove some roles
from there
2. You will see that the role will disappear from the components like
the invitation form or managed access form.
## Checklist
Check all before review:
- [x] I have read
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
- [x] If I wrote a new docs topic or edited an existing topic, I used
the `/write-the-docs` or `/edit-the-docs` skill, which applies the docs
[style
guide](https://github.com/supabase/supabase/tree/master/apps/docs/style-guide)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Summary by CodeRabbit
* **Bug Fixes**
* Organization role lists now show only supported roles, in the expected
order. Roles outside the supported set are no longer displayed. This
keeps the list consistent and focused on recognized roles, making
available organization roles easier to review.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Context
Follow up to https://github.com/supabase/supabase/pull/50238 which
addressed some rendering issues for organization team settings. The
changes in 50238 improved the performance of searching members, but
there's still a bit of client side latency. There shouldn't be any
functional changes from the changes here, just refactoring
- `MemberRow` wrapped in `memo` so unaffected rows skip re-rendering
- Memoized a number of variables in `MembersView` so they only recompute
when filtered members/user/role actually change, not on every render
- In `MemberRow`, replaced per-role `.find()` chains with Map-based
lookups and memoized the whole per-role derivation
- Fixed a mutating in-place `.sort()` in `organization-roles-query.ts`'s
select that was silently rewriting the shared RQ cache entry
- Added `TeamSettingsDataContext` + reduce prop drilling for `MemberRow`
+ `MemberActions`
- Removed an any cast on member.metadata?.origin in MemberRow, replaced
with explicit Boolean(...) coercion
Organization team settings page should work as per status quo including
searching. The searching was the main issue so these are hoping to
alleviate the performance issues. It's quite hard to test unless you've
got an organization with a 150 + members though (< 100 you don't really
see any issues).
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Improvements**
- Improved the Team Settings member list for more consistent role and
project information.
- Member role links now provide more direct navigation to associated
projects.
- Improved performance when displaying and sorting team members.
- Added an accessible label to the member actions menu.
- **Bug Fixes**
- Prevented organization role data from being unexpectedly changed while
it is sorted.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
platform, v1 and v2 have been already completely migrated and introduced
some changes.
Some types have been renamed, some outputs and inputs updated.
## Solution
- Update the API types
- Fix the TS errors
## Update
Taking this over to unblock #50134, which needs the new scoped token
permission ids from the regenerated types.
- Merged `master`.
- Regenerated `api-v2.d.ts` from the production spec. The previous files
came from a local API that exposed a webhook events endpoint production
doesn't have yet. Production has since added standardized 400 error
responses on the v2 organization endpoints. `api-v1.d.ts` and
`platform.d.ts` already matched production.
- Fixed `verify-production-types`. It formatted the regenerated files in
a temp directory outside the repository, so Prettier fell back to its
defaults and the comparison could never match the committed files. It
now passes the repository config explicitly. `pnpm api:verify-types`
passes on this branch.
- Verified locally: `pnpm typecheck`, `pnpm api:verify-types`, Studio
unit tests.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Preserved descriptions when saving, sharing, moving, or unsharing
notebooks, reports, SQL snippets, and saved queries.
* Improved handling of empty or null values across notebook
descriptions, billing usage, pooler settings, and infrastructure fields.
* Improved read-replica connection handling, including read-only
connection strings.
* Updated storage configuration and capability handling to match current
settings.
* **API and Compatibility**
* Updated organization, project, storage, OAuth, billing, and
infrastructure data handling to match current API responses.
* OAuth app creation and updates now require scopes.
<!-- 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?
Code clean-up following #48470, #48471, #48472, #48473, and #48474.
## What is the current behavior?
Mutation hooks provide fallback error toasts, so callers that already
render errors inline must suppress those toasts with empty `onError`
handlers.
## What is the new behavior?
The affected callers own their error presentation. Inline interstitial
errors remain unchanged, API authorisation retains its state-reset
handlers, and Project Claim retains its combined caller-owned toast.
## To test
There is no useful before-and-after visual check for this PR: the
rendered error states should be identical on `master` and this branch.
The change only removes the default-toast and no-op-handler pair
underneath the UI.
The existing [Organisation
Invite](https://github.com/supabase/supabase/pull/48470), [API
authorisation, AWS
Marketplace](https://github.com/supabase/supabase/pull/48471), and
[Stripe Projects](https://github.com/supabase/supabase/pull/48472)
failure tests cover the inline errors and confirm that no duplicate
toast appears.
- Add `invalidatePermissionsQuery` helper to `permissions-query.ts`
- Invalidate it alongside organizations and projects in
`useOrganizationAcceptInvitationMutation`'s `onSuccess`, so permissions
are refetched before the redirect to the org.
## Testing
1. Invite a user to an org.
2. Accept the invite via the invite link.
3. Navigate to the org's Billing page.
4. Verify the Subscription and Cost Control sections load without "you
need additional permissions" errors (no manual reload needed).
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Fixed an issue where user permissions were not properly synchronized
after accepting organization invitations.
<!-- 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?
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>
## 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>
* Use version 2 organization roles endpoint and fix all affected files + unit tests
* Update API codegen
* Replace all usage of old useProjectsQuery with useOrgProjectsInfiniteQuery
* Swap access callout for project roles to use collapsible instead
* Deprecate useProjectsQuery and clean up
* Update apps/studio/components/interfaces/Organization/TeamSettings/UpdateRolesPanel/UpdateRolesPanel.tsx
Co-authored-by: Alaister Young <alaister@users.noreply.github.com>
---------
Co-authored-by: Alaister Young <alaister@users.noreply.github.com>
* Add custom types for queries, mutations and infinite queries.
* Migrate all queries to use the new type.
* Migrate all infinite queries to useCustomInfiniteQueryOptions.
* Migrate all mutations to use useCustomMutationOptions.
* Add type to all imports in `types` folder.
* Migrate all uses of invalidateQueries to use object syntax.
* Migrate the remainder of useInfiniteQuery.
* Migrate all setQueriesData.
* Migrate all fetchQuery uses.
* Migrate some leftover functions from RQ.
* Fix issues found by Charis.
* Update the design of the sonner toasts. Add the close button by default.
* Migrate studio and www apps to use the SonnerToaster.
* Migrate all toasts from studio.
* Migrate all leftover toasts in studio.
* Add a new toast component with progress. Use it in studio.
* Migrate the design-system app.
* Refactor the consent toast to use sonner.
* Switch docs to use the new sonner toasts.
* Remove toast examples from the design-system app.
* Remove all toast-related components and old code.
* Fix the progress bar in the toast progress component. Also make the bottom components vertically centered.
* Fix the width of the toast progress.
* Use text-foreground-lighter instead of muted for ToastProgress text
* Rename ToastProgress to SonnerProgress.
* Shorten the text in sonner progress.
* Use the correct classes for the close button. Add a const var for the default toast duration. Remove the custom width class from sonner.
* Set the position for all progress toasts to bottom right. Set the duration for all toasts to the default (when reusing a toast id from loading/progress toast, the duration is set to infinity).
* Fix the playwright tests.
* Refactor imports to use ui instead of @ui.
* Change all imports of react-hot-toast with sonner. These components were merged since the last commit to this branch.
* Remove react-hot-toast lib.
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
Co-authored-by: Jonathan Summers-Muir <MildTomato@users.noreply.github.com>
* fix: update Permission params
* fix: upgrade check permission hook to support project level role
* fix: usePermissionsLoaded
* fix: Permission params can be undefined
* Scaffold new access management UI
* Add validation
* Update roles view
* Add tooltip
* Add button to apply role to all projects
* Update UI to select projects first instead of roles
* Merge master update UI
* Midway trying to implementation project level perms API
* First pass implementating updating project level permissions
* Add client side validation for assigning/removing roles
* Midway implementing new invites
* Integrate most of the project level permissions functionality
* fix: filter out org-level permissions before checking
* Add relevant UI guards in org level pages for project role POV
* Minor refactors
* Small refactors
* More fixes
* Moar refactors
* More fixes
* More fixes
* Refactor update role logic and smack some test cases on it
* Fixes
* Fix type issue
* Fix type
* more fixes, refactors, adding checks...
* MORE fixes
* Add perms checking for replicas
* Add ButtonTooltip component and use them to prevent repetition of pointer events auto for buttons with tooltips
* Convert all buttons with tooltips to use ButtonTooltip
* refactor
* PRettier
* Small fix
* Remove commented out code in organization-invitation-accept-mutation
* fix: switch to use the platform oauth authorizations routes
* Add perms checking for org audit logs and org oauth apps
* PRettier
* Fix incorrect URL for oauth app flow
* Fix incorrect URL for oauth app flow
* Fix
* Add perms checking for warehouse related UI
* Update roles helper icon
* remove unused lib
* Update package lock... again
* Update package lock... again
* Smalllll update
* Update some checks
* Add gate for project level permissions
* Last fix
* update codegen
* Update warehouse endpoint routes
* Fix
---------
Co-authored-by: phamhieu <phamhieu1998@gmail.com>
Co-authored-by: Alaister Young <a@alaisteryoung.com>
Tanun Turbo Chalermsinsuwan