There is no point in trying to wake up a project that is not
`ACTIVE_HEALTHY` as it will always fail.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Improved project wake-up behavior by limiting automatic wake-ups to
hibernating projects with a healthy active status.
* Prevented unnecessary wake-up attempts for projects in other states.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Context
As per PR title - should not have any visual nor functional change
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Changes**
- Standardized infrastructure, region, and database configuration around
AWS-based environments.
- Removed Fly.io-specific region and provider options from project
creation, instance sizing, and infrastructure settings.
- Enabled disk validation, spend-cap eligibility, backup restoration,
and extension setup consistently across supported projects.
- Updated billing and region displays to use the applicable AWS
configuration.
- **Bug Fixes**
- Corrected project-specific restrictions that could incorrectly hide
configuration and billing controls.
<!-- 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?
Chore / build (ESLint config upgrade + lint cleanup).
## What is the current behavior?
`eslint-plugin-react-hooks` v5 (pulled in transitively by
`eslint-config-next` v15) doesn't recognize stable `useEffectEvent`, so
every effect that calls an effect-event handler needs an `eslint-disable
react-hooks/exhaustive-deps` to silence a false positive. There are 30
such dead disables across Studio.
## What is the new behavior?
Bumps `eslint-config-next` to v16, which pulls in
`eslint-plugin-react-hooks` v7 whose `exhaustive-deps` understands
`useEffectEvent`, and removes the 30 now-dead disable directives (and
their orphaned explanatory comments).
Supporting changes:
- **Flat-config migration**: v16 is a native flat-config array (v15 was
eslintrc), so `eslint-config-supabase` now spreads it directly instead
of bridging through `FlatCompat`.
- **React Compiler rules off**: v16 enables react-hooks v7's
`recommended`, which layers the React Compiler lint rules on top of the
two classic rules. These are switched off (derived dynamically from what
next enables) to keep this change scoped to the `exhaustive-deps`
improvement.
- **Plugin-registration fallout** (v16 scopes plugin registration to a
file glob rather than registering globally like FlatCompat did): stop
re-registering `@typescript-eslint` (shared) and `jsx-a11y` (studio);
scope our react / react-hooks / jsx-a11y rule overrides (studio, www) to
v16's plugin glob so they don't error on files outside it (e.g. `.cjs`).
- **Lint surface preserved**: v16's glob newly includes `.mts`/`.cts`
(v15 didn't lint them), which surfaced pre-existing errors in tooling
scripts. The shared config keeps the prior surface by leaving
`.mts`/`.cts` unlinted; linting them is left as a separate change.
- **Ratchet**: rebaselines `@tanstack/query/exhaustive-deps` 9 → 89. v15
forced next's `@babel/eslint-parser` onto `.ts` files, hiding these
deps; v16 parses `.ts` with `@typescript-eslint/parser` and correctly
surfaces the intentional `connectionString`-excluded-from-`queryKey`
pattern. Worth a follow-up to review whether any are real
cache-correctness bugs.
- Drops three now-dead devDeps from `eslint-config-supabase`:
`@eslint/eslintrc`, `@eslint/js`, `@typescript-eslint/eslint-plugin`.
Verified locally: `turbo run lint` → 7/7 packages pass with 0 errors;
Studio `lint:ratchet` passes; Prettier clean on changed files; typecheck
unaffected.
## Additional context
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Refined linting configuration and removed outdated lint suppressions
across Studio.
* Updated Next.js linting support and refreshed related development
configuration.
* Expanded lint baseline coverage for query-related code.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Shows the restore deadline as a date on the paused-project screens, and
offers backup downloads while a paused project is still restorable
(previously only after the restore window ended).
Depends on a backend change — keep as draft until that is live.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Extended the paused-project restore window from 90 days to up to 1
year.
* Added clearer, downloadable options for database backups and storage
objects while a project is paused.
* Paused-project screens now show an “available until” date when
applicable (and updated resume guidance).
* **Documentation**
* Updated platform and troubleshooting guides to reflect the new 1-year
restore window and post-window recovery limitations.
* **Bug Fixes**
* Standardized restore-window wording across the pause confirmation and
paused-state UI.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
How to test:
1. Have multiple free orgs
2. Open the "create new project" page in those orgs (no need to create a
project), notice the `/members/reached-free-project-limit'` API call
3. Delete any project in any of the orgs you have
4. Go to any of orgs and open the "create new project" page, the request
should be sent again (it was purged from the cache)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Improved project deletion behavior so free project limit checks are
refreshed across all organizations, reducing the chance of stale
availability data.
* Continued to refresh the deleted project’s details and, when
applicable, the project list and organization details after deletion.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
The free-plan paused project notice was a dense paragraph, so the key
points (data is safe, resume window, download-after-expiry, upgrade)
were easy to skip.
## Fix
Present those points as a scannable bullet list, keeping the dynamic
day-count tooltip, restore-deadline timestamp, and the existing
Pro-wording variant.
Also adds a "Project Status" tab to the dev toolbar (local and staging
only) with a select for forcing the current project's status, so the
paused state and other statuses are easy to preview without touching the
backend. It overrides the status in the React Query cache and reverts on
close, project navigation, or reset.
## How to test
- Run Studio locally against the platform API
- Open the dev toolbar, go to the Project Status tab, and select
INACTIVE
- Navigate to a project page and confirm the paused screen renders
- On a free-plan org, confirm the notice now shows the details as bullet
points with the day-count tooltip and restore-deadline date intact
- Click "Reset to real data" (or close the toolbar) and confirm the
status reverts
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added a development toolbar “Project Status” tab to simulate project
status and pause states in non-production environments.
* Status and pause-state overrides persist locally, can be reset, and
are reflected across project detail and paused-state views.
* **Style**
* Refined paused-project messaging: updated the heading and reworked the
free-plan explanation into bullet points, while keeping paid-plan
messaging paragraph-based for readability.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Fixes a batch of production Studio crashes from Sentry (all caught by
the global error boundary). Most are missing array/null guards where an
endpoint typed as an array — or with a nested array field — returned a
non-array body in production; a few are one-off render crashes.
Resolves FE-3748.
## Issues fixed
| Sentry | Error | Fix |
| --- | --- | --- |
| [J7R](https://supabase.sentry.io/issues/7492997940/) | Maximum update
depth exceeded | Disable RadialBar animation in disk-cooldown countdown
|
| [JR5](https://supabase.sentry.io/issues/7548484681/) |
resourceWarnings.find is not a function | Guard in
ResourceExhaustionWarningBanner |
| [JCJ](https://supabase.sentry.io/issues/7506024989/) |
resourceWarnings.find is not a function | Guard in ProjectLayout +
normalize query |
| [K1Y](https://supabase.sentry.io/issues/7584792331/) | snippet.name on
undefined | Optional-chain SQL editor download filename |
| [B3K](https://supabase.sentry.io/issues/7141649636/) |
pagination.count on undefined | Guard pagination in projects infinite
query |
| [JVP](https://supabase.sentry.io/issues/7560437621/) | schemas.some /
extensions.find | Coerce pg-meta lists to arrays in
useInstalledIntegrations |
| [JR2](https://supabase.sentry.io/issues/7548339272/) | extensions.find
is not a function | (same fix as JVP) |
| [JQR](https://supabase.sentry.io/issues/7547163939/) | lints.filter is
not a function | Normalize project lints query |
| [JR3](https://supabase.sentry.io/issues/7548433501/) |
entitlements.find is not a function | Guard call sites + normalize
entitlements query |
| [JQS](https://supabase.sentry.io/issues/7547557098/) |
selected_addons.find is not a function | Normalize addons query arrays |
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Improved stability across several Studio screens by handling missing
or unexpected data more safely.
* Downloads now use a fallback name when a snippet name isn’t available.
* Project, entitlement, schema, addon, warning, and extension views are
less likely to break when data is missing or not in the expected format.
* Pagination and countdown visuals now behave more consistently, with
reduced chance of runtime errors or animation-related glitches.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>
## Context
Opting to keep the prefetching behaviour on Project cards from the home
page, but skip waking the project if its hibernating
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Optimized project loading to skip unnecessary wake operations during
prefetch, reducing latency when browsing project lists.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
Our `<Button>` component breaks the default `button` contract by
redefining the `type` prop to set its variant (`primary`, `default`,
etc) instead of the button type (`submit`, `button`, etc).
This is confusing and forces to write more code when using it with
shadcn components that expect/inject the standard button props.
## Solution
- rename the `type` prop to `variant`
- rename the `htmlType` prop to `type`
- propagate the changes where necessary
- format code
## How to test
As this is just prop renaming, if it builds it's ok
---------
Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>
## Context
We're currently fetching _all_ database policies when landing on the
Table Editor which is unnecessarily since only the table in view matters
in that moment.
## Changes involved
- Ensure that fetching policies is filtered by the current schema in the
table editor to avoid fetching all policies in the DB
- ^ Applied the same fix on the Auth Policies page as well since it
faces the same issue
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Improved database policy fetching so it respects the currently
selected schema and won’t run when the table context is missing.
* Enhanced project status updates by aligning cached updates with the
infinite-list query structure.
* **Refactor**
* Streamlined auth policy schema handling by deriving exposed schemas
via shared utilities and requesting only the needed configuration field
for subsequent policy queries.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
As part of hibernation (suspend and wake), wakes via PostgREST happen
automatically. However, if a user goes straight to the dashboard, we
want to ensure the project wakes up from it's slumber. I've decided to
add this logic at a very central point that will prevent most
project-ref related pages to load (purposely).
The project ref details endpoint returns whether the project is
hibernating or not - so for any regularly running project, none of the
added logic will be invoked and there is no extra network calls, so no
negative perf impact for these checks.
Eventually with v3 architecture none of this is needed as wakes are done
at the proxy/network layer, but this is a necessary change for v2 for
more graceful wakes.
Adjusted network restrictions as it would query before the project loads
and potentially time out while still loading
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
* **New Features**
* Automatic wake-up for hibernating projects restores functionality
without manual intervention.
* **Platform API Enhancements**
* New conversation management endpoints for escalation, synchronization,
and resolution.
* New project wake endpoint for managing dormant project states.
* Updated read-replica operation response codes for improved API
consistency.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Swap the project-creation revoke from custom `db_sql` over to the new
`data_api_revoke_default_privileges` API field. Same behaviour, just
delegated to the platform so non-studio flows (branches, CLI, terraform)
can apply the same revoke logic — addresses
[FE-3145](https://linear.app/supabase/issue/FE-3145/swap-frontend-to-use-revoke-default-privileges-flag).
Backend support landed in supabase/platform#32158 and
supabase/platform#32493 (FUP that decoupled the flag from
`data_api_use_api_schema`).
**Changed:**
- `apps/studio/data/projects/project-create-mutation.ts` — accepts
`dataApiRevokeDefaultPrivileges` and forwards it as
`data_api_revoke_default_privileges`
- `apps/studio/pages/new/[slug].tsx` — drops the inline
`buildDefaultPrivilegesSql('revoke')` injection in `dbSql`, passes the
flag instead
-
`apps/studio/pages/integrations/vercel/[slug]/deploy-button/new-project.tsx`
— same swap on the Vercel deploy-button flow
- `packages/api-types/types/platform.d.ts` — adds the new field to
`CreateProjectBody`
**Preserved:**
- The `dataApiRevokeOnCreateDefault` PostHog flag still gates the
default checkbox state and telemetry — only the SQL application changes
- `data_api_use_api_schema: false` stays as-is — projects keep `public`
+ `graphql_public` exposed, no project-shape change
## To test
- Project creation form (`/new/<org>`):
- With PostHog flag off: "Automatically expose new tables" defaults to
checked → request body has `data_api_revoke_default_privileges: false`
- Manually uncheck the box → request body has
`data_api_revoke_default_privileges: true`, project ends up with revoked
default grants on `public`
- With "Enable Data API" off → `data_api_revoke_default_privileges:
false` (no point revoking when nothing's exposed)
- Vercel deploy-button flow
(`/integrations/vercel/<slug>/deploy-button`):
- Same checkbox behaviour as above
- Migration SQL from the GitHub repo still runs as `db_sql` separately
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added support for a dedicated `dataApiRevokeDefaultPrivileges` option
during project creation.
* **Refactor**
* Simplified Data API privilege configuration by using a dedicated
parameter instead of SQL-based management across project creation flows.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
<img width="1289" height="863" alt="image"
src="https://github.com/user-attachments/assets/d661f107-b358-4894-8531-80441d60ab91"
/>
GitHub integration is now available on the free plan and so we'd like to
start promoting code-first workflows as much as possible. One way to do
that is to set the tone straight away by asking a user to connecting
their GitHub repository to a project as part of project creation.
This PR:
- decouples GitHub connection and repo selection into a separate
component we can make use of in integration settings and project
creation.
- Adds new GitHub fields to project creation form and sends them off to
project creation endpoint
- Pre-fills project name based on repo selection
To test locally:
- Ensure you have GitHub integration set up locally (using ngrok etc)
- Ensure you are on the connected platform branch
- Open create a new project page
- Connect GitHub as part of the creation form and select a repo
- Create the project and wait for status to be healthy
- Check project settings integrations page and ensure repo is connected
Note:
- this requires changes on the management api end to accept new GitHub
fields
- it might make sense to pull out GitHub connection/authorization from
GitHub repository selection but in the current state they are tied
together.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
* **New Features**
* GitHub repository selection now available during project creation with
integrated authorization flow
* GitHub connection status and compute availability indicators now
displayed on project dashboard
* Project name auto-populates from selected GitHub repository name when
available
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Gildas Garcia <1122076+djhi@users.noreply.github.com>
## 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>
The Fly login/auth endpoints were removed from the management API
(supabase/platform#30987). This cleans up the associated studio code and
regenerates the API types.
Note: existing Fly projects are still running, so all `cloud_provider`
guards and Fly-specific UI (disk management, billing, pg_cron warnings,
etc.) are intentionally kept in place.
**Removed:**
- `sign-in-fly-tos.tsx` page
- `organization-by-fly-organization-id-mutation.ts`
- `project-by-fly-extension-id-mutation.ts`
**Other:**
- Regenerated API types to reflect removed endpoints
- Removed stale Fly-related comments in `InstanceConfiguration`,
`ObservabilityMenu`, `ReportsMenu`
- Fixed unrelated optional chaining bug in `SSOConfig.tsx`
## To test
- Check project creation flow still works
- Verify `/sign-in-fly-tos` no longer resolves
---------
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Feature enhancement — smarter incident banner targeting logic
## What is the current behavior?
Displaying the incident banner requires toggling a flag or environment
variable. Banners are shown to all users regardless of whether their
projects are in affected regions or whether the incident affects project
creation.
## What is the new behavior?
Banner visibility is now driven by `show_banner` metadata from the
StatusPage API — no manual flag or env var toggle needed. Per-user
targeting is then applied:
- Users with projects only see the banner when they have a database in
an affected region
- Users without projects only see the banner when the incident affects
project creation
Incident responses are enriched with cache data (`affected_regions`,
`affects_project_creation`) fetched from a Supabase table. Visibility
logic is extracted into a dedicated hook and pure utility function,
backed by unit tests.
## Additional context
Resolves FE-2562
* 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.
* 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.
* CmdK OrgProjectSwitcher to swap useProjectsQuery with useProjectsInfiniteQuery
* Remove usage of useProjectsQuery in ProjectDropdown
* Remove usage of useProjectsQuery in NotificationsPopover
* Remove usage of useProjectsQuery in NotificationsFilter
* Remove usage of useProjectsQuery from LoadingState
* Clean
* Remove usage of getProjects from org-ai-details and fix missing key props in AIOnboarding
* Remove useAutoProjectsPrefetch from org/[slug]/index
* Fix TS + clean up
* Clean
* Remove usage of useProjectsQuery in NewOrgForm
* Remove usage of useProjectsQuery in SupportForm -> AIAssistantOption
* Remove usage of useProjectsQuery in PlanUpdateSidePanel
* Remove usage of useProjectsQuery in NoProjectsOnPaidPlan
* Remove useProjectsQuery in IntegrationPanels
* Remove useProjectsQuery from IntegrationPanels 2
* Remove useProjectsQuery from IntegrationConnection
* Remove console log
* Small change
* CmdK OrgProjectSwitcher to swap useProjectsQuery with useProjectsInfiniteQuery
* Remove usage of useProjectsQuery in ProjectDropdown
* Remove usage of useProjectsQuery in NotificationsPopover
* Remove usage of useProjectsQuery in NotificationsFilter
* Remove usage of useProjectsQuery from LoadingState
* Clean
* Remove usage of getProjects from org-ai-details and fix missing key props in AIOnboarding
* Remove useAutoProjectsPrefetch from org/[slug]/index
* Fix TS + clean up
* Clean
* Remove usage of useProjectsQuery in NewOrgForm
* init
* Infinite scrolling pagination for projects in table view
* Infinite scrolling pagination for projects in cards view
* Shift searching projects to URL state + to server side
* Shift status filter to URL state
* opt to use local storage query for view moe
* update wildcard project route
* add created at value, and shift filter status to server side
* Nit
* final nit
* Address comments
* Fix
* Prettier
* Raise page limit to 96
* chore: use /available-regions endpoint for project creation
* fix types
* make postgres version selection work
* Small nit refactors
* Feature flag changes + fix icons for flags in various places
* Fix creating projects when selecting a smart region
* Fix sending region selection to create project endpoint
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
* Validate the aiOptInLevel on the server
* Fix another issue when the project and mismatched org.
* Fix a type error.
---------
Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>
