Commit Graph
11 Commits
Author SHA1 Message Date
Danny White ec53175b8a refactor(ui): rename text-brand to text-primary (#50564)
## What kind of change does this PR introduce?

Refactor. Follow-up to #49871.

## What is the current behavior?

Branded (green) text still uses the `text-brand` classname while the
colour comes from `--primary`.

## What is the new behavior?

**Rename-only:** `text-brand` → `text-primary` across callsites and
docs. Leftover `bg-brand` / `border-brand` alias to `brand-default`. No
intentional colour changes in this PR.

This better matches how we treat our green in other components and
props, like `variant="primary"` for green buttons.

## To test

On light mode: smoke-test that branded text still looks like #49871
(readable green, not the bright fill).

-
[Homepage](https://zone-www-dot-com-git-dnywh-depr-316-text-brand-de2380-supabase.vercel.app/):
“Scale to millions” uses `text-primary`
- [Docs
homepage](https://docs-git-dnywh-depr-316-text-brand-to-primary-supabase.vercel.app/docs):
branded links like “More on self-hosting” are still readable
- [Typography
docs](https://design-system-git-dnywh-depr-316-text-brand-to-primary-supabase.vercel.app/design-system/docs/typography):
documents `text-primary`
- [Colour
usage](https://design-system-git-dnywh-depr-316-text-brand-to-primary-supabase.vercel.app/design-system/docs/color-usage):
`text-primary` is visibly darker than `bg-brand-default` _on light mode_
- [Studio auth
providers](https://studio-staging-git-dnywh-depr-316-text-brand-to-60fa6c-supabase.vercel.app/dashboard/project/_/auth/providers):
enabled provider badge text readable; status dot stays bright green

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Style**
* Updated branded text, link hover states, icons, badges, indicators,
and highlighted content across the Design System, Docs, Studio, Learn,
UI Library, and marketing experiences to use the primary theme color.
* Updated syntax highlighting and table-of-contents styling for
consistent primary-color presentation.
  * Refined brand color fallback behavior for bright fills and borders.

* **Documentation**
* Updated color-usage and typography guidance to recommend the primary
text utility.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
2026-09-22 16:19:03 +10:00
Danny White 476d4a5851 refactor(ui): drop redundant Button variant="default" props (#50161)
## What kind of change does this PR introduce?

Mechanical cleanup on top of the Button default-variant change (#50160).

## What is the current behavior?

Many callsites still pass `variant="default"` even though that is now
the component default.

## What is the new behavior?

Removes redundant static `variant="default"` from legacy `Button` and
`ButtonTooltip` callsites. Keeps explicit defaults where they document
the API:

- `button-default.tsx` and `button-sizes.tsx` demos
- `DocsButton`, which pins neutral styling at the wrapper boundary

## To test

Studio:

- [Auth → Rate
Limits](https://studio-staging-2s957kwc4-supabase.vercel.app/dashboard/project/_/auth/rate-limits):
dirty the form so Cancel appears; Cancel stays neutral, Save stays green
- [Project Settings → API
Keys](https://studio-staging-2s957kwc4-supabase.vercel.app/dashboard/project/_/settings/api-keys):
`DocsButton` in the header actions stays neutral

Design system:

- [Design system →
Button](https://design-system-git-dnywh-dc924ac1-supabase.vercel.app/design-system/docs/components/button):
`button-default` / `button-sizes` still show explicit default styling;
Primary (green) is restricted to the Primary section (and `asChild`)

WWW:

- [www → Brand
assets](https://zone-www-dot-com-git-dnywh-dc924ac1-supabase.vercel.app/brand-assets):
Download logo kit / Download button kit stay neutral
2026-09-11 17:05:26 +10:00
Alaister YoungandAlaister Young 0fe2366659 [FE-3790] fix(studio): hide Multigres from user-facing surfaces (#48191)
Hides the "Multigres" term from user-facing surfaces — it's the tech
powering High Availability projects, but "High Availability" is the only
term users should see for now (per Slack discussion with Saxon/Ivan).

**Changed:**
- High Availability badge hover card (project overview) no longer says
"Driven by Multigres"
- Project creation HA toggle description drops the Multigres name +
multigres.com link, keeps the informational copy
- All schema dropdowns now hide the `multigres` schema on HA projects,
by wiring in the previously-unused `filterSchemasForHighAvailability`
helper:
- `SchemaSelector` (shared — Table Editor, Functions, Indexes, Triggers,
Schema Visualizer, etc.)
  - `ExposedSchemaSelector` (API settings → exposed schemas)
- `EnableExtensionModal`, `CreateIndexSidePanel`, `ForeignKeySelector`,
`WrapperTableEditor`, Integrations install sheet `AdvancedSettings`
  - SQL editor schema autocomplete (`useAddDefinitions`)
- Schema list computations in the touched components are now memoized
(incl. stabilizing `SchemaSelector`'s `excludedSchemas` default so the
memo actually holds)

**Added:**
- Unit tests for `filterSchemasForHighAvailability` /
`resolveHighAvailability`
- MSW component test for `SchemaSelector` asserting `multigres` is
hidden on HA projects and still shown on non-HA projects

The filter is HA-gated on purpose: a self-hosted/non-HA user with their
own schema named `multigres` still sees it. The flag-gated Multigres
option in Logs is intentionally untouched — that exposure is kept for
the Multigres team's debugging (separate track).

## To test

- On an HA project (`high_availability: true`): hover the High
Availability badge on project overview — no "Multigres" mention; open
schema dropdowns in Table Editor / Database pages / SQL editor
autocomplete — no `multigres` schema
- Project creation with HA entitlement: toggle description has no
Multigres wording/link
- On a non-HA project: schema dropdowns behave as before

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Improvements**
* Made schema dropdowns and related selectors high-availability aware
across extensions, indexes, integrations, SQL editing, API exposed
schemas, and relationship editors.
* Updated project high-availability UI text and badge hover description
to remove outdated branding and clarify horizontally scalable Postgres
architecture.
* **Tests**
* Added coverage to ensure the schema “multigres” option is hidden/shown
correctly based on high availability, and validated high-availability
value handling.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
2026-07-23 00:08:11 +08:00
Andrey A. a6a04f24cd fix(studio): correct exposed-schema settings for the Data API (#47511) 2026-07-07 16:37:21 +02:00
Gildas GarciaandIvan Vasilov 96d43099bb chore: refactor Button API so that it can be used a standard button (#46880)
## 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>
2026-06-16 23:59:58 +02:00
Joshen Lim ba39e9c387 Adjust Data API exposed schema (#46260)
## Context

Builds on top of the work done previously here:
https://github.com/supabase/supabase/pull/46169

In the Data API settings, only non-protected schemas are allowed to be
exposed - in which `pgmq_public` was labelled as protected, resulting in
an odd situation whereby if users expose the `pgmq_public` schema via
the queue settings, they'll see this UI message
<img width="762" height="238" alt="image"
src="https://github.com/user-attachments/assets/1ccac832-9524-40a9-956d-bbbda8a7e136"
/>

The `pgmq_public` schema was intended to be public, much like how
`graphql_public` schema was, hence we're exposing that schema to be
selectable in the Data API exposed schemas dropdown.

Am also making a couple of changes to adjust the UI a little
- Change missing schema text to be less alarming (reserve red for
destructive actions - otherwise the visual signal is inaccurate and
might cause unnecessary distress)
<img width="465" height="113" alt="image"
src="https://github.com/user-attachments/assets/bdc30d9c-7898-4b25-9c4b-bc5aafa22076"
/>
<img width="488" height="112" alt="image"
src="https://github.com/user-attachments/assets/f3e4459c-c670-4321-9f42-93e7abe69a00"
/>

- Highlight if a protected schema is being exposed with warning colors 
<img width="501" height="105" alt="image"
src="https://github.com/user-attachments/assets/b8bff3b8-9635-4e57-96d2-80b5ad33f53f"
/>

- Adjust text of missing schema in dropdown to text-foreground-lighter
instead of red (It's not necessarily a problem, just a clean up so again
just a visual signal thing)
<img width="461" height="249" alt="image"
src="https://github.com/user-attachments/assets/7f0632df-bee5-4911-bd3c-8a1cd6fb2f1f"
/>
<img width="442" height="207" alt="image"
src="https://github.com/user-attachments/assets/bad266aa-84bf-4de7-b62a-4362f85b9481"
/>



<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
* Inline help text now surfaces schema exposure status directly in the
configuration UI.

* **Bug Fixes**
  * Improved filtering of internal schemas considered exposable.
* Messaging updated to show counts and distinct styling: protected
internal schemas render a warning and should be removed, while
missing/nonexistent schemas show a lighter "safe to remove" note.

<!-- review_stack_entry_start -->

[![Review Change
Stack](https://storage.googleapis.com/coderabbit_public_assets/review-stack-in-coderabbit-ui.svg)](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46260?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)

<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
2026-05-22 16:05:24 +07:00
Gildas Garcia 0283d92505 fix: allow users to remove missing schemas from the data API (#46169)
## Problem

Exposed schemas (from the Data API) that have been deleted manually (for
instance, using the SQL editor) are still present in the Data API
setting, crashing Postgrest clients. However, the Data API setting does
not show them anymore preventing users from fixing the issue.

## Solution

- Detect missing schemas and show users an error message
- Make missing schema visually distinct
- Allow users to unselect them and update the Data API settings

## How to test

- Create a new schema
- Verify that it is exposed (expose it if necessary) in the Data API
settings
- Delete the schema using the SQL editor
- Verify that you can unselect it from the Data API settings

## Screenshots

<img width="470" height="243" alt="image"
src="https://github.com/user-attachments/assets/2a1f7dc5-c9a9-4779-9f26-1d3e0f66fb8f"
/>


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Bug Fixes**
* Dropdown for exposed API schemas now shows selected schemas that no
longer exist and labels them "This schema does not exist", allowing
users to toggle them.
* "Exposed schemas" field now shows an inline validation/error message
when selected schemas are unavailable to help resolve configuration
issues.

<!-- review_stack_entry_start -->

[![Review Change
Stack](https://storage.googleapis.com/coderabbit_public_assets/review-stack-in-coderabbit-ui.svg)](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46169?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)

<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
2026-05-20 17:33:03 +02:00
Gildas Garcia 243e079a2c chore: remove _Shadcn_ suffix from Command components (#46153)
## Problem

The `_Shadcn_` suffix isn't needed anymore on `Command` components

## Solution

- Remove the `_Shadcn_` suffix
- Simplify UI package exports
- Apply prettier

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Refactor**
* Simplified command component imports and exports across the UI library
by removing internal naming aliases and adopting direct component
references. Updated the public UI package barrel export to use wildcard
re-exports for cleaner API surface.

<!-- review_stack_entry_start -->

[![Review Change
Stack](https://storage.googleapis.com/coderabbit_public_assets/review-stack-in-coderabbit-ui.svg)](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46153?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)

<!-- review_stack_entry_end -->

<!-- end of auto-generated comment: release notes by coderabbit.ai -->
2026-05-20 15:45:32 +02:00
Gildas Garcia d0fd4478c0 chore: migrate Popover usages to Shadcn components (#45980)
## Problem

We have multiple Popover components

## Solution

- [x] migrate Popover usages to Shadcn components
- Migrated JSON and text editor in the `TableEditor` (inline row
edition)
  - Migrated the template popover in the logs explorer templates page
- [x] remove `_Shadcn_` suffix from Popover components (renaming +
prettier)

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Refactor**
* Unified popover implementation across the app and design system;
dropdowns, calendars, menus and tooltips now use a consistent popover
API with no visual or interaction changes.

* **Chores**
* Minor prop typing update for the logs date-picker to align with the
consolidated popover content type.

<!-- review_stack_entry_start -->

[![Review Change
Stack](https://storage.googleapis.com/coderabbit_public_assets/review-stack-in-coderabbit-ui.svg)](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45980)

<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
2026-05-15 15:20:28 +02:00
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>
2026-04-30 10:53:24 +00:00
Alaister YoungandNick Babadzhanian 5894e37b40 [FE-2158] – feat(studio): Add exposed tables config to Postgrest settings (#43280)
Adds a feature flagged exposed tables config to postgrest settings:
<img width="1158" height="589" alt="Screenshot 2026-03-02 at 17 04 13"
src="https://github.com/user-attachments/assets/8fa8ab81-0bfa-4781-83bc-80ac52e180f8"
/>

To test:
- make sure the existing (feature flag off) settings work as expected
- make sure exposing and removing schemas works in the new mode
- make sure exposing and removing tables works in the new mode
- ideally try with a lot of tables to check search and infinite scroll
work as expected
- try exposing a schema without any tables (like `graphql_public`) and
make sure it doesn't get removed randomly when editing tables
- try with a table with custom permissions (for example `REVOKE SELECT
ON public.posts FROM anon;`) and make sure the user is informed with the
tooltip

---------

Co-authored-by: Nick Babadzhanian <33933459+pgnickb@users.noreply.github.com>
2026-03-06 20:51:37 +08:00