Ikki Nishihara
cba8bc0b30
## Problem The Database Roles page groups `postgres` and the reserved `supabase_privileged_role` alongside custom roles, while labeling the other section as "Roles managed by Supabase." The `postgres` actions menu also offers an enabled Delete action. Fixes #51525. ## Solution - Rename the sections to "Supabase service roles" and "Project database roles," and explain that the latter includes the `postgres` administrator and custom roles. - Include `supabase_privileged_role` among the protected service roles. - Disable Delete for the existing `SYSTEM_ROLES` list, using `DropdownMenuItemTooltip` to explain the restriction. Keep the `postgres` permission editor available. - Add component regressions for grouping, system-role menus, permission editing, and custom-role deletion confirmation. ## Validation - Studio unit suite: 732 files passed; 8,343 tests passed and one expected failure. - `pnpm --filter studio typecheck` passed. - `SKIP_ASSET_UPLOAD=1 pnpm build --filter=studio` passed. - ESLint for changed files, the Studio lint ratchet, monorepo Prettier, and Studio knip passed. - Playwright smoke verification of the production Studio build with synthetic API responses: grouping, disabled Delete and tooltip, keyboard interaction, permission editing/cancellation, read-only service roles, search, and custom-role deletion confirmation/cancellation. ## Review instructions 1. Open Database → Roles. Check the two section names and the administrator description. If present, `supabase_privileged_role` belongs to the protected service section. 2. Open the `postgres` actions menu. Delete is disabled, and hovering it explains why. 3. Expand `postgres`. Its existing editable permission switches remain enabled for a user who can edit roles. 4. Open a custom role's actions menu. Delete still opens the confirmation dialog; cancel the dialog. 5. Run `pnpm --filter studio exec vitest run tests/components/Database/Roles.test.tsx`. ## Checklist - [x] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) - [ ] If I wrote a new docs topic or edited an existing topic, I used the `/write-the-docs` or `/edit-the-docs` skill, which applies the docs [style guide](https://github.com/supabase/supabase/tree/master/apps/docs/style-guide) — not applicable; this changes Studio UI and tests.
UI Testing Notes
Rules
-
All tests should be run consistently (avoid situations whereby tests fails "sometimes")
-
Group tests in folders based on the feature they are testing. Avoid file/folder based folder names since those can change and we will forget to update the tests.
Examples: /logs /reports /projects /database-settings /auth
Custom Render and Custom Render Hook
customRender and customRenderHook are wrappers around render and renderHook that add some necessary providers like QueryClientProvider, TooltipProvider and NuqsTestingAdapter.
Generally use those instead of the default render and renderHook functions.
import { customRender, customRenderHook } from 'tests/lib/custom-render'
customRender(<MyComponent />)
customRenderHook(() => useMyHook())
Mocking API Requests
To mock API requests, we use the msw library.
Global mocks can be found in tests/lib/msw-global-api-mocks.ts.
To mock an endpoint you can use the addAPIMock function. Make sure to add the mock in the beforeEach hook. It won't work with beforeAll if you have many tests.
beforeEach(() => {
addAPIMock({
method: 'get',
path: '/api/my-endpoint',
response: {
data: { foo: 'bar' },
},
})
})
API Mocking Tips:
- Keep mocks in the same folder as the tests that use them
- Add a test to verify the mock is working
This will make debugging and updating the mocks easier.
test('mock is working', async () => {
const response = await fetch('/api/my-endpoint')
expect(response.json()).resolves.toEqual({ data: { foo: 'bar' } })
})
Mocking Nuqs URL Parameters
To render a component that uses Nuqs with some predefined query parameters, you can use customRender with the nuqs prop.
customRender(<MyComponent />, {
nuqs: {
searchParams: {
search: 'hello world',
},
},
})
<Popover> vs <Dropdown>
When simulating clicks on these components, do the following:
// for Popovers
import userEvent from '@testing-library/user-event'
await userEvent.click('Hello world')
// for Dropdowns
import clickDropdown from 'tests/helpers'
clickDropdown('Hello world')