## Context
Missed another case here - RLS tester when retrieving policies
associated with query needs to consider policies with the `ALL`
operation
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Tests**
* Added comprehensive tests for Row-Level Security policy filtering,
covering schema/table matching, role handling (including
public/service-role cases), command/operation semantics, and combined
filter behavior.
* **Refactor**
* Centralized and clarified RLS policy filtering logic used by the
tester for improved maintainability and consistency.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Context
For a table that has RLS enabled, but a policy with just `true` for the
role `public`
The RLS tester was incorrectly reporting that `anon` doesn't have access
Was happening as we weren't considering policies that apply to the
`public` role (which applies to _all_ roles)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* RLS tester now treats explicitly-public policies as applicable
regardless of the impersonated role, improving policy coverage accuracy.
* **Refactor**
* Consolidated RLS test state computation to improve consistency of
access badges and policy messaging.
* **Tests**
* Added comprehensive tests validating RLS scenarios, badge states, and
policy/role messaging.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
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 -->
## Context
As part of RLS testing, adding @awaseem's idea for having "View data as
user" CTAs in the Auth Users's table
<img width="348" height="190" alt="image"
src="https://github.com/user-attachments/assets/855c8f54-0aba-478c-982b-1d9d29e419bd"
/>
## Other changes
Similar from @awaseem's suggestions, am also refactoring the Role
Impersonation UI a little, mainly from a copy writing POV to improve the
clarity of the UI.
- More action-oriented and contextual header for the role impersonation
popover
- e.g Table Editor -> "View data as a role", or SQL Editor -> "Run SQL
query as a role"
- Updated labels to be bit more intuitive from a builder's POV
- The actual database role is still mentioned in the option's
description (so we aren't obfuscating the actual postgres logic)
- Add label descriptors to elaborate what each role implies
- e.g Anon -> "Not logged in"
- Add docs button which points to
[here](https://supabase.com/docs/guides/database/postgres/row-level-security#authenticated-and-unauthenticated-roles)
that explains which roles Supabase uses
- (Nit) Refactor to use Card component
### Before
<img width="647" height="277" alt="image"
src="https://github.com/user-attachments/assets/9ebae084-38b7-4e21-886b-f609bd71976e"
/>
### After
<img width="604" height="309" alt="image"
src="https://github.com/user-attachments/assets/4d797309-1b6b-4fd0-aab3-63d5e144c53c"
/>
<img width="630" height="297" alt="image"
src="https://github.com/user-attachments/assets/ca748635-c5da-4426-a9c3-8cb5aeef47a6"
/>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added "View data as user" and "Run SQL as user" actions to user rows
to impersonate a user and jump to table or SQL views.
* Impersonation now surfaces an identity card in new tabs showing the
impersonated identity and a Stop button.
* **UI/UX Improvements**
* Impersonation panels accept customizable headers, show clearer role
labels (Postgres), richer role descriptions, condensed RLS copy,
in-panel docs link, simplified "Stop" labels, and adjusted
typography/padding for consistent styling.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## 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 -->
Joshen Lim