mirror of
https://github.com/supabase/supabase.git
synced 2026-10-07 18:35:07 +03:00
chore/function-recent-errors
1336
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Joshen Lim
|
88c43b31b9 |
Support optionally remove custom domain addon when deleting custom domain after activated (#45880)
## Context Related BE PR: https://github.com/supabase/platform/pull/32693 Add support to remove the custom domain add-on when deleting a custom domain after the custom domain is activated. <img width="411" height="310" alt="image" src="https://github.com/user-attachments/assets/23d57fc0-f760-42d4-8383-480ff2b2ec5a" /> We previously had this behaviour by default to address some customer feedback RE confusion that they were still being charged for custom domain add-on despite deleting the custom domain, but not removing the add-on. However this was a bit of confusing UX (RE deleting the add-on implicitly), so this makes the deleting of the custom domain add-on an explicit action instead. ## To test - [ ] Set up custom domain on a project - [ ] Trying deleting the custom domain after activating _without_ removing the add-on - [ ] Trying deleting the custom domain after activating _with_ removing the add-on |
||
|
Charis
|
d79a276824 |
studio: ColumnTypeRef cascade + FK type comparison fixes (2/7) (#45903)
## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## What kind of change does this PR introduce? Refactor + bug fixes (part of the SafeSql migration stack — PR 2 of 7, stacks on top of #45897). ## What is the current behavior? - `pgMeta.columns.create` and the table-editor SQL builder take column type as a string with array suffix and schema baked in (e.g. `'private.test_enum'`, `'int4[]'`). - The studio table-editor SQL emits the legacy schema-embedded `format` string for enums in non-public schemas, while the pg-meta columns SQL already returns the new shape (bare `format` + separate `format_schema`). The two queries disagree on how to represent the same column, surfacing as a false-positive type mismatch in the FK selector when both ends are an enum from a non-public schema. - The FK selector compares column types by `format` alone — same-named enums in different schemas appear equal, and arrays vs. scalars of the same base type pass the family check. - `displayColumnType` renders arrays as the raw `_typname` pg-meta emits (e.g. `_int4` instead of `int4[]`). ## What is the new behavior? **pg-meta** - Introduce `ColumnTypeRef` (`{ schema?, name, isArray? }`) for column type input, replacing the legacy string-with-array-suffix format. `pgMeta.columns.create` and the table-editor SQL builder consume the new shape. - Add `format_schema` to the column zod schema; pg-meta SQL emits the type's schema for the table editor's ColumnType dropdown. - `pgMeta.columns.create` returns a `SafeSqlFragment`. - Studio table-editor SQL now emits bare `format` + `format_schema`, matching pg-meta's columns SQL. **Studio** - `SafePostgresColumn`/`SafePostgresTable` extend the new `PG*` types (master dropped postgres-meta). - Pipe `ColumnTypeRef` through `SidePanelEditor` → `ColumnEditor` → `TableEditor`, along with the column-create mutation, table retrieve/list queries, and the `TableList`/`ColumnList` surfaces. - `displayColumnType` helper renders arrays as `type[]` (or `schema.type[]`) and handles non-implicit schemas. - FK selector now carries `sourceIsArray`/`targetIsArray` and compares the full `(format, format_schema, isArray)` triple. Family checks for numeric/text/uuid skip when either side is an array (FKs across array boundaries are never compatible). - Type-mismatch and type-notice alerts pass `isArray` to the display helper. - Bundle `Policies.utils` + `Policies.types` + `sql-policy-mutation`, `PolicyEditorModal`, and `SchemaGraph` here because `SidePanelEditor` consumes `acceptGeneratedPolicy`/`AcceptedGeneratedPolicy` — splitting requires temporary overloads with no architectural payoff. ## Additional context Part of the SafeSql migration stack. Stacks on top of #45897. ### Manual test checklist Surfaces touched by this PR — please exercise each: **Table editor** - [x] Create a new table with a mix of column types (scalar, array, enum, foreign key) - [x] Add a column to an existing table; verify the type dropdown lists scalars + arrays separately and shows schema-qualified names for non-public enums - [x] Edit an existing column's type (scalar ↔ array, switch between enums in different schemas) and save - [x] Verify enum types from a non-public schema (e.g. `private.my_enum`) display as `private.my_enum` in the column list **Foreign key selector** - [x] Open the FK selector for a column and pick a target column with a matching type — no mismatch warning - [x] Pick a target column whose type differs only by schema (two same-named enums in different schemas) — should show a type-mismatch alert - [x] Pick a target column where one side is an array and the other is a scalar of the same base type — should show a type-mismatch alert (no auto-cast across array boundary) - [x] When FK target sets the column type, verify `format_schema` and `isArray` are preserved on the source column - [x] Type-mismatch and type-notice alert messages render array types as `type[]` (not `_type`) **Column list / table list** - [x] Schema-qualified type names display correctly for columns whose type lives in a non-public schema - [x] Array columns display as `type[]` (or `schema.type[]`) **Policies (bundled due to import dependency)** - [x] Open the Policies page; create/edit/delete a row-level policy via the modal - [x] Generate a policy via the AI assistant and accept it through `SidePanelEditor` — verify the accepted policy lands in the editor correctly **Schema visualizer** - [x] Open the Schemas → Schema Visualizer page; verify it renders without type errors and shows tables/relationships <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Improvements** * Support for column types in non-public schemas and richer column type presentation (includes schema and array info). * Stronger SQL safety around policies and constraints; draft policy SQL is now promoted explicitly on save. * Improved foreign-key type validation and compatibility checks using enhanced type metadata. * **Tests** * Updated snapshots and tests to reflect new column metadata and SQL fragment handling. <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45903) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Charis
|
ec21e68eee |
studio(logs): use safe sql escaping for new logs queries (#45887)
<!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Introduced a safe SQL fragment system and helpers to build composable, validated log queries and aggregations. * **Refactor** * Rewrote unified log query builders and inspection flows to use the new safe fragments and identifier/literal validators. * **Bug Fixes** * Improved validation and error handling for filter keys and literal escaping to prevent malformed or injectable queries. * **Tests** * Added tests covering identifier quoting, value escaping, and rejection of invalid filter inputs. <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45887) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Raminder SinghandJoshen Lim
|
897043952a |
feat: add edge function secret installation method (#45826)
Adds a new method of installation detection for partners like Doppler. Doppler creates edge function secrets with specific names (`DOPPLER_CONFIG`, `DOPPLER_ENVIRONMENT`, and `DOPPLER_PROJECT`). This method allows the dashboard to check for the presence of such a secret to show the installation status. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Support for edge-function-secret-based OAuth identification and verification. * Installation checks adapt to the selected installation method and only fetch required credentials when needed. * Integration detection can validate installations via API key prefixes or matching edge-function secret names. * **Chores** * Shared helper utilities and types exported to streamline installation checks and mappings. <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45826) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Joshen Lim <joshenlimek@gmail.com> |
||
|
Jordi Enric
|
19e0b36650 | feat(logs): migrate unified logs queries to OTEL endpoint DEBUG-71 (#45642) | ||
|
Charis
|
d4079083fc |
chore(studio): drop @supabase/postgres-meta in favor of @supabase/pg-meta (#45844)
## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## What kind of change does this PR introduce? Refactor / dependency cleanup. ## What is the current behavior? `apps/studio` lists both `@supabase/pg-meta` (workspace package) as a runtime dep and `@supabase/postgres-meta` (external npm package, `^0.64.4`) as a devDependency. The external package is used only for type imports across 44 files — there is no runtime usage and no codegen pipeline that needs it. ## What is the new behavior? Every `Postgres*` type import (`PostgresTable`, `PostgresColumn`, `PostgresPolicy`, `PostgresTrigger`, `PostgresView`, `PostgresMaterializedView`, `PostgresForeignTable`, `PostgresSchema`, `PostgresPublication`, `PostgresRelationship`, `PostgresPrimaryKey`) is replaced with its `PG*` counterpart from `@supabase/pg-meta`, and the external dep is removed from \`apps/studio/package.json\`. Top-level type re-exports were added to \`packages/pg-meta/src/index.ts\` so consumers can import directly from the package root. Two latent issues surfaced by the stricter pg-meta types are also fixed: - \`data/foreign-tables/foreign-tables-query.ts\` was casting foreign-table results as \`PostgresView[]\`; corrected to \`PGForeignTable[]\`. - \`pg-meta\`'s \`PGTrigger\` Zod schema declared \`orientation\`/\`activation\` as \`z.string()\`, inconsistent with pg-meta's own \`getDatabaseTriggerUpdateSQL\` helper that requires the narrow literal unions; tightened to \`z.enum\`. ## Additional context <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Chores** * Updated internal TypeScript type definitions across the codebase to use the latest type system from `@supabase/pg-meta`. * Removed `@supabase/postgres-meta` dependency. * Enhanced type validation for database triggers and schemas to enforce stricter constraints. [](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45844) <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Matt Rossman
|
d143571586 |
feat(assistant): trace-level scorers + server-side tool execution with needsApproval (#45654)
## Motivation When Assistant runs a potentially destructive tool like `execute_sql`, it stops the LLM request and prompts for client-side approval and execution of the tool. After approval, a second request kicks off under a separate trace. This has made scoring and [Topics](https://www.braintrust.dev/blog/topics) classification challenging, as the generated `output` is split across stateless requests. The [span-level scoring](https://www.braintrust.dev/docs/evaluate/custom-code#score-spans) approach we've used thusfar (after the LLM call, we massage the result into an `output` payload that's stuck onto the root span) has been cumbersome and led to invalid scores / topics where only part of the assistant response is considered. It's also inefficient, as we're duplicating potentially large info (like the `search_docs` output) that already exists within the trace. An alternative to scoring spans is to [score traces](https://www.braintrust.dev/docs/evaluate/custom-code#score-traces). Braintrust [best practices](https://www.braintrust.dev/docs/evaluate/score-online#best-practices) advise: > Use span scope for evaluating individual operations or outputs. Use trace scope for evaluating multi-turn conversations, overall workflow completion, or when your scorer needs access to the full execution context. We've also received [direct guidance](https://supabase.slack.com/archives/C05QYJBLX89/p1777925770927149?thread_ts=1777905716.911979&cid=C05QYJBLX89) from their team to use this approach. ## Changes Migrates eval scorers from custom `AssistantEvalOutput` shape to trace-level scoring via `trace.getThread()` / `trace.getSpans()`, with thread parsing that scores the full latest Assistant turn and passes prior conversation separately where relevant. Moves `execute_sql` and `deploy_edge_function` from client-side execution after approval to AI SDK `needsApproval` + server-side `execute()`. SQL results returned to the model are gated by AI opt-in level, so row data is only included with `schema_and_log_and_data`; otherwise the tool returns the no-data-permissions sentinel. Adds `metadata.isFinalStep` to disambiguate multiple LLM requests within an "assistant" turn due to tool call requests/responses. For online evals, this means we should configure automations to only score traces with `metadata.isFinalStep = true` to ensure we're judging the complete generated response. Other minor kaizen changes: - Renamed `promptProviderOptions` to `systemProviderOptions` to clarify that this is associated with the "system" message and disambiguate from the root `providerOptions` - Adds `evals/trace-utils.ts` to handle Zod validation of the `unknown` span shapes from Braintrust, to more easily access typed inputs/output on tool spans. - Bumps AI SDK floor version `^6.0.116` → `^6.0.174` - Tweaked the "Conciseness" scorer to not unfairly dock points for the new `[called tool_name]` labels in serialized assistant response ## Verification In the studio staging build, I asked Assistant to create a todos table with 3 sample todos. I manually approved the `execute_sql` call and saw Assistant generate text before & after the call. In Braintrust I verified two traces were produced (see [filtered logs](https://www.braintrust.dev/app/supabase.io/p/Assistant/logs?v=Staging&tvt=trace&search={%22filter%22:[{%22text%22:%22metadata.environment%2520%253D%2520%27staging%27%22,%22label%22:%22metadata.environment%2520%253D%2520%27staging%27%22,%22originType%22:%22btql%22},{%22text%22:%22%2560Chat%2520ID%2560%2520%253D%2520%25221cb2ac45-e5e7-458c-9da4-3bf6863b8842%2522%22,%22label%22:%22Chat%2520ID%2520equals%25201cb2ac45-e5e7-458c-9da4-3bf6863b8842%22,%22originType%22:%22form%22}]})), the first with `metadata.isFinalStep = false` and the second with `metadata.isFinalStep = true`. In the Braintrust staging scorers, I ran the preview Completeness scorer on the second trace and verified it sees the complete Assistant response including markers for tool calls ([link to trace](https://www.braintrust.dev/app/supabase.io/p/Assistant%20(Staging%20Scorers)/trace?object_type=project_logs&object_id=b5214b62-ad1e-4929-9d5b-40b1daebe948&r=0ed0a4f8-8aff-4a34-bb1d-1df1d88a5070&s=ff9015f8-6bf7-4ab3-83a9-ca4e69e27e82)) <img width="1193" height="960" alt="CleanShot 2026-05-07 at 11 27 10@2x" src="https://github.com/user-attachments/assets/509d4858-c3a1-4068-986d-3aa4d5617d1a" /> I also tested the `deploy_edge_function` workflow and verified it still prompts for permission and warns on deployment of existing functions. **References** - https://www.braintrust.dev/docs/evaluate/custom-code#score-traces - https://ai-sdk.dev/docs/ai-sdk-core/tools-and-tool-calling#tool-execution-approval Supercedes https://github.com/supabase/supabase/pull/45556 and https://github.com/supabase/supabase/pull/45339 Closes AI-473 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Tool actions (SQL execution, edge-function deploy) now require explicit user Approve/Deny before proceeding. * **Improvements** * Assistant pauses for approval responses before sending follow-ups, giving clearer control over risky actions. * Deploy/replace flows show confirmation and clearer replace warnings. * Evaluation/scoring updated to use richer trace data for more accurate assistant performance signals. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Jordi EnricandClaude Opus 4.7
|
420d4d0b5a |
feat(studio): add Disk IO Burst Balance chart to DB Report (#45516)
## Problem When users hit a disk IO exhaustion notification, they open the Database Observability report and find IOPS and throughput charts, but no view of the metric that actually fired the warning: the EBS burst credit balance. That signal is currently only available behind Custom Reports, so the warning feels disconnected from the visible data. > "The Dashboard actually shows them their burst budget, not their normal disk usage. It leads to a lot of confusion." — support > "Customers may receive an 'exhausting multiple resources' warning and it's confusing because all the charts are 'fine', but it's the burst credits exhaustion that fails them." — Maksym Reported in [Linear DEBUG-60](https://linear.app/supabase/issue/DEBUG-60). ## Fix Add a clearly-labeled "Disk IO Burst Balance" chart to [getReportAttributesV2](apps/studio/data/reports/database-charts.ts) plotting `disk_io_budget` (% remaining) on a 0-100 axis. Tooltip and titleTooltip explain the 5 MB/s throttle floor so users can correlate this chart with the exhaustion banner copy (also being updated in [supabase#45514](https://github.com/supabase/supabase/pull/45514)). The chart is hidden for compute variants that have dedicated I/O resources (4XL and above) since the burst credit pool does not apply there. Burstable variants (nano through 2XL) see the chart inline next to the existing IOPS and throughput charts. DEBUG-61 ("replace Disk IO Usage % chart with disk throughput") was already addressed in the V2 migration (the report only renders `disk-iops` and `disk-throughput`; the old burst-percentage chart is gone). I'll close that issue as completed once this lands. ## Test plan - [ ] Visit `/project/{ref}/observability/database` on a project running `nano`/`micro`/`small`/`medium`/`large`/`xlarge`/`2xlarge` compute. Confirm the new "Disk IO Burst Balance" chart appears between throughput and connections. - [ ] On a project running `4xlarge` or larger compute, confirm the chart is hidden (chart is omitted by `hide: !hasBurstableIO`). - [ ] Hover the chart and a data point. Confirm the title tooltip and inline attribute tooltip both surface the 5 MB/s throttle behaviour. - [ ] Series renders 0-100 on the Y-axis. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added a Disk IO Burst Balance chart to monitor remaining burst credits; displays percentage (0–100%) with tooltip referencing baseline throughput. Shown only for supported compute variants and when the feature flag is enabled. * **Bug Fixes / UI Improvements** * Improved chart header tooltip presentation: uses a unified tooltip, includes inline docs links when available, and avoids duplicate docs icons. [](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45516) <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com> |
||
|
Ali Waseem
|
920571fcf7 |
feat(studio): rewrite secret key reveal flow without react-query [FE-3206] (#45792)
## Summary
Rewrites the secret API key reveal flow in `ApiKeyPill` to remove its
dependency on React Query, replacing it with a lightweight custom hook.
## Changes
- **`useRevealedSecret` (new hook)**
A simple, reusable hook that:
- Fetches the unmasked secret key via `getAPIKeysById`
- Exposes `data`, `isLoading`, `reveal()`, and `clear()`
- Keeps sensitive data in local component state (no global cache)
- **`ApiKeyPill` (refactored)**
- Removes all React Query imports (`useQueryClient`, `useAPIKeyIdQuery`,
`apiKeysKeys`)
- Uses `useRevealedSecret` for reveal / copy operations
- Preserves existing UX:
- 10-second auto-hide timer
- Permission-based gating (`canManageSecretKeys`)
- Loading states on toggle / copy
- **`api-key-id-query.ts` (cleaned up)**
- Removes the now-unused `useAPIKeyIdQuery` hook
- Retains the `getAPIKeysById` fetcher for direct use
## Motivation
The previous React Query–based flow had to aggressively disable caching
(`staleTime: 0`, `gcTime: 0`) and manually purge queries from the cache
on every interaction, which was cumbersome and leaked implementation
details into the component. A plain fetch + local state is simpler and
safer for transient, sensitive data.
## Testing
- [x] Toggle reveal on a secret API key
- [x] Verify 10-second auto-hide
- [x] Copy a secret key (both revealed and unrevealed states)
- [x] Verify restricted users cannot reveal/copy
---
Resolves [FE-3206](https://linear.app/supabase/issue/FE-3206)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Improved API key reveal/copy flow: uses a dedicated reveal/clear
mechanism, preserves permission checks and 10s auto-hide, and shows
reveal/copy failures via user-facing toasts. Copy now falls back to
masked key when needed and the reveal toggle behavior is more reliable.
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45792)
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
|
||
|
|
b934e148a3 |
fix(reports): replace explicit any with number in tickFormatter callbacks (#45794)
## Problem Recent database report PRs introduced `(value: any)` type annotations in recharts `tickFormatter` callbacks, pushing the `@typescript-eslint/no-explicit-any` ESLint ratchet from baseline 1014 to 1017 and blocking all PR merges. ## Fix Replace `(value: any)` with `(value: number)` in all affected `tickFormatter` callbacks across the three flagged files. Recharts always passes a number to tick formatters, so this is a safe and accurate type. ## How to test - Run `pnpm lint --filter=studio` and confirm no new `@typescript-eslint/no-explicit-any` violations appear in the three changed files - Check the ESLint ratchet count is back at or below baseline 1014 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Refactor** * Improved type safety for Y‑axis tick formatters across observability charts (Memory, Swap, Network throughput, Disk IOPS/throughput/usage, Replication Lag), ensuring tick values are treated as numeric for more consistent chart rendering and reliability. [](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45794) <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> Co-authored-by: Ali Waseem <waseema393@gmail.com> |
||
|
Jordi Enric
|
c29ea9a0fa | feat(reports): add swap usage chart to database report (#45746) | ||
|
Jordi EnricandClaude Opus 4.7
|
52fccc7b3b |
feat(reports): add network throughput chart to database report (#45747)
## Problem The Database report in Observability has no view of network traffic. Inbound/outbound throughput is useful for spotting saturation, large unexpected egress, or correlating spikes with disk I/O. Closes [FE-3193](https://linear.app/supabase/issue/FE-3193/add-network-in-and-out-charts). ## Fix Add a new \`network-throughput\` chart entry to \`getReportAttributesV2\` in [apps/studio/data/reports/database-charts.ts](apps/studio/data/reports/database-charts.ts), placed right before \`disk-iops\`. Uses the existing \`network_receive_bytes\` and \`network_transmit_bytes\` infra-monitoring attributes (series already exist, no backend work needed). Pattern mirrors the \`disk-throughput\` chart: bytes-per-second Y-axis, \`stackedAreaLine\` default, same \`syncId\`. \`showMaxValue\` is \`false\` because there is no provisioned network max to render as a reference line. ## Test plan - [ ] Open \`/project/<ref>/observability/database\` and confirm a "Network throughput" chart renders with two series (Network in / Network out) and a \`bytes/s\` Y-axis. - [ ] Switch the date range and confirm the chart respects it (auto-wired via \`REPORT_ATTRIBUTES.flatMap\`). - [ ] Use the global refresh button and confirm both series invalidate with the rest. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added a network throughput chart that visualizes inbound and outbound network throughput metrics with real-time speed data visualization. [](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45747) <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com> |
||
|
Alaister YoungandAlaister Young
|
409a38a4ea |
[FE-3145] feat(studio): use data_api_revoke_default_privileges flag (#45683)
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> |
||
|
Saxon FletcherandGildas Garcia
|
ae66a6a9c0 |
Connect GitHub during project creation (#44884)
<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> |
||
|
K-Dog (Kevin)
|
5082c9b35d |
chore(billing): use new balance endpoint (#45481)
New billing credits balance endpoint for improved transparency |
||
|
Charis
|
116faefcda |
studio: convert more executeSql callers to SafeSqlFragment (#45645)
## Summary - Converts ~27 `executeSql` call sites in `apps/studio/data/**` to build SQL through `safeSql` / `ident` / `literal` / `keyword` / `joinSqlFragments` instead of raw template-string interpolation. - Tightens the `useDatabaseCronJobCreateMutation` and `useDatabaseEventTriggerCreateMutation` `sql`/`query` parameter types from `string` to `SafeSqlFragment` (callers already produce one). - Updates `getDeleteEnumeratedTypeSQL` in `packages/pg-meta` to return `SafeSqlFragment`. - Fixes a bug noticed while testing where Queues integration does not correctly handle queues with uppercase names. ## Pages to manually test - Integrations > Cron Jobs - Integrations > Queues - Database > Triggers > Event Triggers - Database > Indexes - Reports > Query Performance - Storage <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Release Notes * **Bug Fixes** * Queue lookups now correctly handle case-insensitive queue names. * Queue table references are now properly managed and consistently applied throughout the queue management interface. * Improved queue name display normalization in the user interface. * **Chores** * Enhanced SQL query safety across the database layer through parameterized query construction and safer templating approaches. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Ivan Vasilov
|
35905e70d5 |
feat: Add a logo picker for OAuth app creation sheet (#44995)
<!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Logo field now accepts/editable logo URL, plus a new storage-based Logo Picker to select or remove images from project storage. * Full storage picker: browse buckets, columns/list views, search, drag‑and‑drop uploads, file previews (image/audio/video), and single-file selection with responsive mobile/desktop layouts. * **Refactor** * Logo submission streamlined to send the provided URL directly (legacy file-read/upload flow removed). <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Wen Bo Xie
|
f648c0c274 | feat: restore a physical backup by id only (#45631) | ||
|
Joshen LimandGildas Garcia
|
f7ea722b35 |
Consolidate grid header actions in table editor into a single row (#45504)
## Consolidate Table Editor grid header actions into a single row https://github.com/user-attachments/assets/1020c385-8fa9-4ef1-b5e7-03983111508b ## Changes involved - Index advisor, Realtime, and API docs are now behind a dropdown menu button (Treated as secondary actions) - Grid header actions shifted into the same row as filter bar (more space for data grid) - Header actions will hide while filter bar is in focus (remove distractions, more space for filter bar) ## Changes to filter bar - Filter bar will refocus when deleting a filter - Clicking on the search icon will focus on the free form input of the filter bar <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added a “More” dropdown in grid actions to access Realtime, API docs, and Index Advisor. * New dialogs for enabling Index Advisor and toggling Realtime are now consistently managed. * **Improvements** * Improved filter focus handling with auto-refocus when conditions change and responsive header behavior. * Adjusted popover alignment, separator visuals, header/footer/pagination layout and sizing. * Filter bar now supports programmatic focus; Connect button supports icon-only mode. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Gildas Garcia <1122076+djhi@users.noreply.github.com> |
||
|
Charis
|
3f97eeea5a |
feat(studio): extend safe SQL model to policy editor and related interfaces (#45560)
## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## What kind of change does this PR introduce? Refactor / security improvement ## What is the current behavior? SQL fragments across Studio are built from plain `string` values with no type-level distinction between developer-authored SQL, DB-sourced identifiers, and user-typed or externally-influenced content. ## What is the new behavior? Extends the safe SQL model to additional Studio interfaces, using `SafeSqlFragment`, `safeSql`, `ident()`, `literal()`, `untrustedSql()`, and `acceptUntrustedSql()` from `@supabase/pg-meta/src/pg-format`: - **Policy editor**: template constants typed as `SafeSqlFragment` via `safeSql` tagged literals; Monaco editor `onInputChange` emits `untrustedSql()`; `acceptUntrustedSql()` called only at the Save gesture; roles selector emits a composed `SafeSqlFragment` via `ident()` + `joinSqlFragments()` - **Auth hooks**: grant/revoke SQL statements use `ident()` for schema and function names - **Docs description editor**: `COMMENT ON` queries use `ident()` and `literal()` for table/column/function names and values - **Cron jobs**: `cron.schedule()` call and HTTP request builder use `literal()` for all user-provided values - **GraphQL linter CTA**: `REVOKE` statement uses `ident()` for schema, table, and role - **Storage public bucket warning**: `DROP POLICY` uses `ident()` for policy name - **View security autofix modal**: `ALTER VIEW` uses `ident()` for schema and view name - **API settings**: `CREATE SCHEMA` mutation uses `safeSql` tagged literal - **Database event trigger delete**: `DROP EVENT TRIGGER` uses `ident()` for trigger name - **Database queues query**: queue list query uses `safeSql` tagged literal - **Role impersonation**: function invocation SQL uses `ident()` and `literal()` ## Manual testing checklist - Authentication > Policies - Authentication > Hooks - Integrations > Queues - Database > Event Triggers - Integrations > Cron Jobs - Table Editor > View entity security autofix - API Settings > expose schema - Linter > GraphQL exposure CTA - Docs > table/column description editor - Role impersonation (user impersonation panel) ## Additional context <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Refactor** * Replaced ad-hoc SQL string building with a safer, fragment-based SQL construction across auth, policies, integrations, storage, and DB operations to improve SQL safety while preserving behavior. * **Bug Fixes / UX** * Policy editor and code editor now propagate role and input changes more reliably, improving editor responsiveness and policy handling without UI changes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Joshen Lim
|
e98a302428 |
Refactor merge page into smaller components + add admonition if branch cannot be merged via dashboard (#45515)
## Context Main fix is actually just the disabled check on the "Merge branch" button We're preventing merging of branches via the dashboard if the project has GH integration + "Deploy to production" enabled (the latter we're checking via if the `git_branch` property from the main branch exists, from the GET branches API endpoint) However, the `git_branch` property persists even after disabling the GH integration (by design), and hence we were incorrectly disabling the "Merge branch" button if the user removed the GH integration. Hence the fix is to also check if the project has an active GH integration ## Other changes - Refactored the merge page into smaller components - Added an admonition to callout the "Deploy to production" + what steps to take (otherwise it's not clear at all what to do in this scenario) <img width="1451" height="524" alt="image" src="https://github.com/user-attachments/assets/9df7d432-b220-4f71-b8f4-5ed0fd426afc" /> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Redesigned merge request page interface with dedicated components for title, subtitle, and merge actions, improving user clarity and experience. * Added GitHub production deployment restriction messaging—users cannot proceed with merge requests when this integration deployment method is enabled. * **Refactor** * Enhanced GitHub integration connection query patterns and overall code organization. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Joshen Lim
|
aab3924eef |
Refactor Invoice estimate tooltip in plan update confirmation dialog (#45446)
## Context Main fix is to ensure that the tooltip here is scrollable - but also adding some refactors This is the org billing page when downgrading an org ### Before <img width="400" alt="image" src="https://github.com/user-attachments/assets/6094c2e6-c1bb-460f-a2d2-347c1d7d2e77" /> ### After <img width="400" alt="image" src="https://github.com/user-attachments/assets/9d0ac9a6-6e89-4758-af14-8144a8a86469" /> ## Changes involved - Use HoverCard for invoice estimate in plan confirmation dialog - Also nudge the UI a little, e.g use a separate column for the compute prices + adjust text color to improve clarity - Refactor usage of `any` for some of the TS declarations <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added an invoice estimate tooltip in subscription settings showing monthly charges with plan fees, combined compute rows, per-project compute costs, optional compute credits, and a total monthly estimate. * **Refactor** * Simplified the plan update flow by consolidating subscription preview handling and extracting the invoice UI into the new tooltip component. * **Chores** * Improved internal type definitions for subscription preview data and pricing tier identifiers. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Samir Ketema
|
ee5d4a9314 |
chore: remove format param from audit log query (#45466)
## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## What kind of change does this PR introduce? Cleanup after shipping https://github.com/supabase/supabase/pull/45389, the backend is now defaulting to the new v2 `format`, and made `format` param optional. So this: - removes references to `v2` naming, as this is the only format - removes the `format` query param from the audit logs API calls ## What is the current behavior? Same audit log functionality shown in https://github.com/supabase/supabase/pull/45389 ## What is the new behavior? Functionally the same behavior for audit logs. - [x] Manual test in staging ## Additional context ⚠️ Will leave the `do-not-merge` tag on until: - [ ] backend `format` optional PR lands in production. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Refactor** * Consolidated audit log type definitions and updated internal API request formatting for audit endpoints across Account and Organization audit log components. No changes to user-facing functionality or audit log display. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Alex Hall
|
baaf07002f |
chore(studio): add method property to integration installation events (#45473)
Add new `method` property to existing event to distinguish from server-side emitted events |
||
|
Charis
|
0433eeb5f5 |
feat(studio): mark sql provenance for safety (#45336)
Mark provenance of SQL via the branded types SafeSqlFragment and UntrustedSqlFragment. Only SafeSqlFragment should be executed; UntrustedSqlFragments require some kind of implicit user approval (show on screen + user has to click something) before they are promoted to SafeSqlFragment. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Editor and RLS tester show loading states for inferred/generated SQL and include a dedicated user SQL editor for safer edits. * **Refactor** * Platform-wide SQL handling tightened: snippets and AI-generated SQL are treated as untrusted/display-only until promoted, improving safety and consistency. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Jordi EnricandClaude Opus 4.7
|
4a702c4429 |
fix(studio): show effective Max IOPS in DB observability (#45363)
## Problem The Max IOPS reference line in the Database Observability report displays the provisioned disk IOPS, but its tooltip claims it shows the "Maximum IOPS for your current compute size". The real effective ceiling is `min(compute IOPS limit, provisioned disk IOPS)`. Users who upgrade their disk IOPS without upgrading compute see an inflated number and may draw incorrect conclusions about their IO headroom. Reported in [Linear DEBUG-63](https://linear.app/supabase/issue/DEBUG-63) (originally [FE-2856](https://linear.app/supabase/issue/FE-2856)). ## Fix In [apps/studio/data/reports/database-charts.ts](apps/studio/data/reports/database-charts.ts), use the existing `mapComputeSizeNameToAddonVariantId` + `COMPUTE_MAX_IOPS` lookup (already used in DiskManagement) to compute the effective ceiling and pass it as the `disk_iops_max` reference line value. Tooltip rewritten to match. ```ts const provisionedDiskIops = diskConfig?.attributes?.iops const computeIopsLimit = COMPUTE_MAX_IOPS[mapComputeSizeNameToAddonVariantId(project?.infra_compute_size)] const effectiveMaxIops = typeof provisionedDiskIops === 'number' && typeof computeIopsLimit === 'number' ? Math.min(provisionedDiskIops, computeIopsLimit) : provisionedDiskIops ``` ## Test plan - [ ] On a project where compute IOPS limit < provisioned disk IOPS (e.g. Micro compute with upgraded disk), confirm the Max IOPS reference line on `/project/{ref}/observability/database` reflects the compute limit, not the disk IOPS. - [ ] On a project where provisioned disk IOPS < compute IOPS limit, confirm the reference line still shows the disk IOPS. - [ ] Hover the line and confirm the tooltip reads "Effective maximum IOPS for your current compute and disk configuration..." 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Release Notes * **Bug Fixes** * Enhanced IOPS limit calculations in database reports to account for both compute size and disk provisioning constraints, resulting in more accurate Max IOPS reference values. Improved chart tooltips to better reflect the effective combined compute and disk IOPS constraints. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com> |
||
|
Samir Ketema
|
d666b950ff |
feat: update audit log schema & UI (#45389)
## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## What kind of change does this PR introduce? - Update to the audit log schema (changes were already applied in staging) - Updates the org & project audit log page to reflect the changes to the schema - The schema should be agnostic to whether logs were emitted to logflare with the old & new schema format - the backend adjusts old logs to the new format. ## What is the current behavior? Currently, the frontend is parsing the legacy schema as the backend returns this by default. It also doesn't show some of these new fields yet. ## What is the new behavior? ### Org Audit Logs - Table View <img width="1810" height="1310" alt="CleanShot 2026-04-29 at 18 27 22" src="https://github.com/user-attachments/assets/47fec068-1ffa-4e52-bc46-3bffdef55adb" /> ### Org Audit Logs - Single log View <img width="1842" height="1494" alt="CleanShot 2026-04-29 at 18 27 37" src="https://github.com/user-attachments/assets/3cff3bdf-4a6a-4981-acaa-7f95bb3ae9cf" /> Note that the `Target` field is no longer there. We just show the `metadata` JSON. <img width="1842" height="1494" alt="CleanShot 2026-04-29 at 18 27 40" src="https://github.com/user-attachments/assets/d2e681f0-41a6-4bc7-a3d7-ec7e8101616c" /> ### Account (Profile) Audit Logs - Table View <img width="1810" height="1310" alt="CleanShot 2026-04-29 at 18 25 20" src="https://github.com/user-attachments/assets/c72e19df-9b82-4611-8889-7af463769550" /> ### Account (Profile) Audit Logs - Single log View <img width="1810" height="1310" alt="CleanShot 2026-04-29 at 18 25 32" src="https://github.com/user-attachments/assets/46f8d3b6-4f2f-4944-b891-431a93e5f3c3" /> ## Additional context ⚠️ currently leaving the `do not merge` tag on, until: - [x] I have verified it works in staging - [x] We've deployed the new schema to production <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Audit logs now use the v2 format with microsecond-accurate timestamps, improved ordering, and a revamped details panel showing clearer actor/action/request/project/org fields and fallback labels. * Page/header layout updated so audit logs render at top level with adjusted spacing. * **Refactor** * Shared sorting and filtering utilities added for consistent user/project filtering and non-mutating log sorting. * **Tests** * Added tests for timestamp conversion, sorting, filtering, and date-range formatting. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Ivan Vasilov
|
688834f1eb |
fix: Fix infinite loading in the Cron jobs table (#45421)
This PR fixes an issue where the infinite list doesn't work for cron
jobs. If the initial data (20 cronjobs) renders and you have a tall
monitor to fit the entire table, the `react-data-grid` can't `onScroll`
event which fetches the next page.
To test:
1. Add 40-50 cron jobs by running `SELECT cron.schedule('test 30', '0 2
* * 1', 'select 1');` repeatedly.
2. Open the /project/_/integrations/cron/jobs
3. See if you can scroll and trigger the second page.
Fixes
https://linear.app/supabase/issue/FE-3117/cron-job-is-not-scrollable
|
||
|
Ivan VasilovandJordi Enric
|
56de26fe22 |
chore: Migrate the monorepo to use Tailwind v4 (#45318)
This PR migrates the whole monorepo to use Tailwind v4: - Removed `@tailwindcss/container-queries` plugin since it's included by default in v4, - Bump all instances of Tailwind to v4. Made minimal changes to the shared config to remove non-supported features (`alpha` mentions), - Migrate all apps to be compatible with v4 configs, - Fix the `typography.css` import in 3 apps, - Add missing rules which were included by default in v3, - Run `pnpm dlx @tailwindcss/upgrade` on all apps, which renames a lot of classes - Rename all misnamed classes according to https://tailwindcss.com/docs/upgrade-guide#renamed-utilities in all apps. --------- Co-authored-by: Jordi Enric <jordi.err@gmail.com> |
||
|
Coenen Benjamin
|
151a1792d9 | feat(studio): add support for new ducklake destination in replication UI (#45370) | ||
|
Alex Hall
|
c8781c885e |
chore(studio): use new publish_dashboard column for marketplace db query (#45345)
Updates the marketplace DB query to use the new `publish_dashboard` column that was added in https://github.com/supabase/marketplace/pull/49 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Chores** * Updated internal marketplace integration query and database type definitions to streamline listing management logic. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Danny White
|
05fc4aca13 |
chore(studio): clean up temporary access response typing (#45354)
## What kind of change does this PR introduce? Cleanup. ## What is the current behavior? Temporary access still has a couple of leftover JIT fallback messages and an unnecessary local unavailable-reason type after the Platform response types were split into `JitAccessResponse` and `JitStateResponse`. ## What is the new behavior? Studio relies on the generated `JitStateResponse` discriminated union for the toggle warning and uses temporary access copy consistently in the remaining fallback toasts. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Improvements** * Refined error messaging for temporary database access grant and revoke operations. * Enhanced condition detection for toggle failure warnings in database access configuration. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
bedb2efb87 |
chore(studio): JIT access UI improvements (#44161)
## What kind of change does this PR introduce? UI and copywriting improvements for temporary access. ## What is the current behavior? The temporary access UI still used older JIT/ephemeral naming in some places, did not clearly explain the setup requirements, and had to infer unavailable states from Platform error message text. ## What is the new behavior? The settings UI now uses temporary access naming consistently, explains that temporary access uses short-lived tokens for manual database connections, and renders clearer unavailable states for projects that require either a Postgres upgrade or a platform migration. The Studio query now consumes Platform’s structured `unavailableReason` contract instead of parsing human-readable error strings, so the UI owns the copy while Platform owns the eligibility reason. Validation: - `pnpm eslint components/interfaces/Settings/Database/JitDatabaseAccess/JitDbAccessConfiguration.tsx data/jit-db-access/jit-db-access-query.ts` - `pnpm tsc --noEmit --pretty false` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * IP range input now supports one CIDR range per row with add/remove rows and form integration. * **Documentation** * Replaced “JIT” wording with “Temporary” / “Ephemeral token-based” access across UI, dialogs, toasts, and help links. * Added minimum PostgreSQL version requirement (17.6.1.081+). * **Improvements** * Per-row CIDR validation with precise nested error messages. * Refined layout spacing and moved the temporary-access configuration earlier in Database settings. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Etienne Stalmans <etienne@supabase.io> Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> Co-authored-by: Joshen Lim <joshenlimek@gmail.com> |
||
|
Joshen Lim
|
5f867e5f6c |
Feature Preview: RLS Tester (#45121)
## Context Resolves FE-3077 Related discussion: https://github.com/orgs/supabase/discussions/45233 Verifying the correctness of your RLS policies set up has always been a gap, as highlighted by a number of GitHub discussions like [here](https://github.com/orgs/supabase/discussions/12269) and [here](https://github.com/orgs/supabase/discussions/14401). As such, we're piloting a dedicated UI for RLS testing (using role impersonation as the base), in which you'll be able to - Run a SQL query as a user (not logged in / logged in - this is the role impersonation part) - See which RLS policies are being evaluated as part of the query - And hopefully be able to debug which policies are not set up correctly Changes are currently set as a feature preview - and we'll iterate as we get feedback from everyone 🙂 🙏 <img width="613" height="957" alt="image" src="https://github.com/user-attachments/assets/83c37f8a-28fc-43b3-b0ff-e28571d8710c" /> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * RLS Tester: run queries as anon or authenticated users, view inferred SQL, per-table policy summaries, and data previews of accessible rows. * UI preview: new RLS Tester preview card and modal with opt-in toggle; RLS Tester sheet with role/user selector and query editor. * SQLEditor: “Explain” tab is always visible. * **Chores** * Added supporting API endpoints, background checks for table RLS status, and a local-storage flag to persist the preview opt-in. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
67deabf67e |
fix: create etl publication as postgres (#45043)
## What kind of change does this PR introduce? Bug fix ## What is the current behavior? Creating a schema only branch fails because ETL publication is owned by `supabase_etl_admin` which users have no access. ## What is the new behavior? Since ETL supports user managed publications, create them through pgmeta so it's owned by `postgres` role instead. ## Additional context mirrors [upstream etl](https://github.com/supabase/etl/blob/main/etl-api/src/db/publications.rs#L22-L51) implementation <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Added guards to prevent creating publications when project or connection info is missing, with clearer error logging. * Ensure the project connection string is explicitly passed so publications target the correct database. * **Refactor** * Publication creation now executes generated SQL directly against the database, with correct handling of empty or selected table lists and proper identifier quoting for reliability. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Joshen Lim <joshenlimek@gmail.com> Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> Co-authored-by: CodeRabbit <noreply@coderabbit.ai> |
||
|
Joshen Lim
|
7f5865872a |
Enforce noUnusedLocals and noUnusedParameters in tsconfig.json + fix all related issues (#45264)
## Context Enforce `noUnusedLocals` and `noUnusedParameters` in tsconfig.json + fix all related issues |
||
|
Riccardo Busetti
|
8347877957 | feat(etl): Add UI elements to disable external replication (#45035) | ||
|
Samir KetemaandDanny White
|
8454ec241d |
feat: add batch email org invites (#44832)
## 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> |
||
|
Ignacio Dobronich
|
e6ca2766ff |
feat: show tax preview for credit top-ups (#45005)
## Summary
- Add tax preview to the credit top-up flow by integrating the new `POST
/organizations/{slug}/billing/credits/preview` endpoint
- Show a price breakdown (credit amount, tax line item, total) in the
top-up dialog before the user confirms payment
- Handle all three `tax_status` states: show tax when `calculated`, hide
the line when `not_applicable`, show an inline warning when `failed`
## Behavior
- Preview fires as soon as a valid amount (300–2000) is entered; address
and tax ID are optional and refine the estimate
- Amount and address changes are debounced at 1s to avoid excessive API
calls
## Test plan
- [ ] Open credit top-up dialog - verify preview appears with default
$300 amount
- [ ] Change amount within 300–2000 - verify preview updates after
debounce
- [ ] Enter amount outside range (e.g. 100 or 3000) - verify preview
hides and validation error shows
- [ ] Add a new payment method with a billing address in a taxed region
- verify tax line item appears
- [ ] Add a new payment method with no tax jurisdiction - verify no tax
line, just total
- [ ] Complete a top-up - verify the charge goes through and dialog
closes
<img width="571" height="551" alt="image"
src="https://github.com/user-attachments/assets/d3357752-f913-4a4a-b84a-f78e2f457c7b"
/>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Credit top-up preview with charge breakdown (credit, tax or tax note,
total).
* Onboarding survey endpoint and ISO 27001 certificate availability for
organizations.
* **Updates**
* Improved top-up UX: debounced address/tax inputs, enforced min/max
amount validation, preview-driven form state, and submit disabled while
preview is loading/stale.
* API docs wording changed to “temporary access configuration.”
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
|
||
|
|
1ab7251060 |
chore(studio): clarify partnered orgs and projects (#44328)
## 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> |
||
|
Stephen MorganandJoshen Lim
|
bd55ad23a6 |
feat: iso27001 certificate (#44963)
Edit: Can be merged, mgmt api deployed Dashboard addition to frontend for access to the ISO 27001 certificate. View for Team customers: <img width="1737" height="1151" alt="image" src="https://github.com/user-attachments/assets/cd62d24f-8b6e-4600-9ded-943a170cd124" /> Resolves SEC-799 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * ISO 27001 certificate added to Documents with a Download action, confirmation modal, new-tab open on success, and error toast on failure. * Users without billing permission see a no-permission view; users missing entitlement see an “Upgrade to Team” prompt. * **Refactor** * Upgrade-to-Team flows for SOC2 and related upgrade UI standardized to use the shared upgrade component. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Joshen Lim <joshenlimek@gmail.com> |
||
|
Charis
|
bff92df845 |
convert fdw sql utilities to safesql (#45069)
<!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Improved SQL query handling for vector bucket creation and Foreign Data Wrapper operations <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Alaister YoungandAlaister Young
|
d272c15d8d |
[FE-2792] feat(studio): unify table exposure check on RLS policies page (#45041)
Fixes the RLS policies page showing self-contradictory or wrong
admonitions for tables with partial grants. Classifies each table using
the same `granted / custom / revoked` semantics used by the Data API
settings page so the two views agree on what counts as "exposed".
**Changed:**
- `PolicyTableRow` now uses `useTableApiAccessQuery` (shared cache with
the Table Editor sidebar) instead of a bespoke
`tables-roles-access-query`
- Boolean soup collapsed into a single `TableDataApiStatus`
discriminated union (`schema-not-exposed | no-grants | custom-grants |
publicly-readable | locked-by-rls | secured`) via a pure helper
- Admonition copy for `no-grants` and `locked-by-rls` updated; a table
with no policies but full grants now reads "No data will be returned via
the Data API as no RLS policies exist on this table." instead of the
earlier self-contradictory "can be accessed but no data will be
returned"
- `table-api-access-query.ts` now exposes a `grantStatus: 'granted' |
'custom'` on `access` entries — `granted` = all 3 API roles × all 4 CRUD
privileges (matches `getTableGrantsCTEs` in pg-meta)
**Added:**
- New `custom-grants` admonition: "This table has custom Data API
permissions — access may be restricted for some roles or operations."
- Unit tests for `getTableDataApiStatus`, `getTableAdmonitionMessage`,
and `isFullyGranted`
**Removed:**
- `data/tables/tables-roles-access-query.ts` and the `rolesAccess` key —
no more callers
## To test
On a project with the `public` schema exposed, for each scenario check
the admonition shown on `/project/{ref}/auth/policies`:
1. Table with full standard grants, RLS on, no policies → "No data will
be returned via the Data API as no RLS policies exist on this table."
2. Table with full standard grants, RLS off → yellow warning "can be
accessed by anyone"
3. Table with partial grants (e.g. only `GRANT SELECT ON t TO anon`) →
new "custom Data API permissions" admonition regardless of RLS state
4. Table with no anon/authenticated/service_role grants → "cannot be
accessed via the Data API"
5. Schema not in the exposed list → "schema not exposed" admonition with
link
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Tests**
* Added unit tests covering table Data API/RLS status classification and
API grant validation.
* **Refactor**
* Introduced a unified per-table API/RLS status model and reusable
utilities to derive display status and admonitions.
* Simplified UI logic to drive access indicators and warnings from the
new status.
* **Chores**
* Removed legacy role-based access query and its related keying logic.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
|
||
|
Alaister YoungandAlaister Young
|
45fc609471 |
[FE-3034] feat(studio): render multi-line SQL error HINTs (#45038)
Preserve `formattedError` through the `ResponseError` path and fall back to splitting `error.message` on newlines so enhanced permission-denied HINTs from supabase/postgres#2084 render as separate lines in the SQL editor — users can actually read the GRANT example now. **Context:** postgres#2084 adds a multi-line HINT to SQLSTATE 42501 errors, telling users exactly how to grant access per-table. Today the SQL editor rendered the whole thing on one line because `formattedError` was stripped by the fetchers' error handling and the `message` fallback didn't split on `\n`. This PR fixes both. Blocks [FE-3023](https://linear.app/supabase/issue/FE-3023) — the project-creation toggle that flips default privileges; without readable HINTs users land on RLS debugging rabbit holes when they hit a permission denied. **Changed:** - `ResponseError` now carries an optional `formattedError` field; `ConnectionTimeoutError` / `UnknownAPIResponseError` thread it through. - `handleError` in `data/fetchers.ts` extracts `formattedError` from the raw error body and forwards it to the thrown subclass. - `UtilityTabResults.tsx` uses a new `getSqlErrorLines` helper — prefers `formattedError`, falls back to splitting `message` on newlines when it's multi-line (defense in depth since the exact field pg-meta populates for the HINT depends on the path). Copy button now uses the same lines. **Added:** - `getSqlErrorLines` pure helper + 9 unit tests. - 5 new tests in `handleError.test.ts` covering `formattedError` preservation on classified and unclassified errors. ## To test 1. Pull the branch, run `pnpm dev:studio`, open any project's SQL editor. 2. Run a query that triggers the enhanced HINT (requires postgres#2084 deployed on the DB — currently staging-only). Example: `select * from some_table_you_cant_read;` as a role without grants. 3. Expect the ERROR line, HINT line, and the `GRANT ...` example to each render on their own `<pre>` line, plus the Copy button to copy the full multi-line text. 4. Sanity check existing single-line errors (e.g. `select * from nonexistent_table`) still render as `Error: relation "nonexistent_table" does not exist` in the `<p>` fallback. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Release Notes * **New Features** * Improved SQL error message formatting in the editor for better readability and clarity. * **Refactor** * Centralized error formatting logic for more consistent error presentation across the application. * **Tests** * Added comprehensive test coverage for SQL error message parsing and formatting. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com> |
||
|
Alaister YoungandAlaister Young
|
19027e73f8 |
[FE-3036] feat(studio): runtime env var overrides for enabled features (#45049)
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> |
||
|
|
b721a2d780 |
feat(studio): advisor signal items for banned IPs (#44372)
## 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> |
||
|
Charis
|
b1531545fb |
security: migrate more files to safeSql (#44727)
<!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Refactor** * Overhauled SQL generation across the Studio: queries and helpers now use safer, parameterized SQL construction for more robust and consistent behavior. * **Bug Fixes** * Improved trigger update flow so event values are normalized before saving, reducing errors when modifying webhooks/triggers. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Vaibhav
|
fdf8732727 |
fix: Include security_invoker in definition (#44936)
## TL;DR the table editor definition panel was showing incomplete SQL for views with `WITH (security_invoker = true)` ignoring the reloption and making it easy to accidentally strip it when recreating the view ## prob When viewing a security invoker view in the Table Editor, the Definition panel only showed `CREATE VIEW ... AS ...` without the `WITH (security_invoker = true)` clause which caused two issues: 1. the displayed SQL was incomplete and didn't match the actual view definition 2. users copying the SQL to recreate the view would unintentionally lose the security_invoker setting ## ex: | Before | After | |--------|-------| | `create view public.exposed_api as`<br>`select id, secret from public.rls_protected_table;` | `create view public.exposed_api with (security_invoker = true) as`<br>`select id, secret from public.rls_protected_table;` | ## ref: - closes https://github.com/supabase/supabase/issues/44934 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * View definitions now show the full CREATE statement (including materialized views and WITH (...) options) and preserve security options like security_invoker when viewed or opened in the SQL editor. * **Tests** * Added end-to-end test verifying security option preservation in view definitions and when opening them in the SQL editor. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Raminder SinghandJoshen Lim
|
0cb71a2497 |
feat: new marketplace db (#44574)
This PR integrates with the new marketplace db to allow Grafana (and other partners) OAuth apps to install from the integrations page. A demo of this working locally is available here: https://supabase.slack.com/archives/C01GN60J0BS/p1775551752479709. End to end flow is documented here: https://www.notion.so/supabase/Grafana-Integration-Flow-33a5004b775f80eeaf91c098beb8071f. TODO: - [ ] Make sure `NEXT_PUBLIC_MARKETPLACE_API_URL` variable is set to the new marketplace db. - [x] Test with the `marketplaceIntegrations` enabled and disabled in staging once https://github.com/supabase/platform/pull/31298 is merged and available in staging. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Add OAuth "Install integration" button that detects installed integrations and supports GET/POST install flows * Marketplace listings now include install links, installation method, partner info, and listing assets/logos * **Infrastructure** * Allow marketplace API origin for images and content in security and image config * Centralize marketplace types and switch marketplace data source for more reliable listings <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Joshen Lim <joshenlimek@gmail.com> |
||
|
Joshen Lim
|
71acf22318 |
Skip invalidating auth config when toggling security email notification in template editor page (#44888)
## Context Preferred fix to this PR [here](https://github.com/supabase/supabase/pull/44886) On a security email template page (e.g. Reauthentication), if you edit the Subject or Body without saving, then toggle **Enable notification** in the Configuration card and click **Save changes**, the Content edits are reverted to the last saved values. ## Changes involved Opting to not invalidate the `authConfig` RQ cache on a successful mutation when toggling the security email notification while on the template editor page ## To test - [ ] Open a security email template - [ ] Make some changes to the template without saving - [ ] Toggle the notification and save - [ ] Ensure that the template changes are still present and not reverted <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Refactor** * Optimized query cache handling for authentication configuration updates to reduce unnecessary refresh operations. * Enhanced type safety for form submissions in authentication settings to prevent data validation errors. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
