## What kind of change does this PR introduce?
Docs update. Aligns documentation and style guides with the **Sign in /
Sign out / Sign up** platform standard.
Closes DOCS-1328. Related to
[#49874](https://github.com/supabase/supabase/pull/49874).
## What is the current behavior?
Docs style guides prefer _login_ / _log in_. Guide prose uses mixed
login and sign in wording.
## What is the new behavior?
- [WORD_LIST.md](apps/docs/WORD_LIST.md) and
[copywriting.mdx](apps/design-system/content/docs/copywriting.mdx)
document the sign in standard
- Design-system auth examples updated
- Guide prose and API reference spec descriptions updated
### Terminology
**Standard:** Use _sign in_, _sign out_, and _sign up_ as verbs. Use
_sign-in_, _sign-out_, and _sign-up_ as nouns and adjectives. Match
Studio UI labels (**Sign in**, **Sign out**, **Sign up**).
**Preserved intentionally:**
| Category | Keep as-is | Example |
| -------- | ---------- | ------- |
| Feature name | social login | `/social-login`, `features.mdx` heading,
OAuth provider section |
| URL slugs | `login` in paths | `/phone-login`, `/login-flows`,
`choosing-login-flow` |
| CLI | `supabase login` / `supabase logout` | Reference ids
`supabase-login` / `supabase-logout`; executable commands unchanged |
| SDK methods | `logout()` | Kotlin/Swift method names in API reference
titles and examples |
| Third-party UI | Provider product labels | Facebook Login, Kakao
Login, portal **Login** buttons |
| Postgres | Database terminology | login privileges, login credentials,
login via role |
| Audit/logging | Log prose | "Generates the following **log** in the
Postgres Logs" |
| Code and routes | Paths and filenames | `app/login/`, `Login.tsx`,
`demos/android-login` |
| External URLs | Third-party login pages | `dash.cloudflare.com/login`,
`console.neon.tech/login`, `vercel.com/login` |
| API identifiers | Event and field names | Audit actions
`login`/`logout`, `should_logout_user` |
## To test
- Run `pnpm lint:mdx` in `apps/docs`
- Spot-check `features.mdx`, `social-login.mdx`, and a provider guide
(e.g. Facebook, Kakao)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Standardized authentication terminology across guides, reference
material, CLI documentation, and copywriting guidance using “sign in,”
“sign out,” and “sign up.”
* Updated authentication instructions, headings, link text, examples,
and SSO guidance for clearer, more consistent wording.
* Corrected related grammar, spelling, hyphenation, and documentation
links while preserving established product names and implementation
commands.
* **Style**
* Refined code examples with consistent import ordering and spacing.
* **Examples**
* Updated authentication button and menu labels to “Sign in” and “Sign
out.”
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Ref DOCS-1274
Follow-up to #49017, now merged.
This is the go-to-green piece: everything aimed at the three failing
eval checks, and nothing else. Technical corrections follow in the PR
stacked on this one.
## Problem
`build-docs-002-rls-guide` points an agent at this guide with a
vibe-coder prompt that never says RLS, policy, role, or test. Grants,
policies, access probes, indexes, and security-definer placement all
pass. Three checks fail, and have failed on every recorded run:
| Check | What it measures | Why it failed |
| --- | --- | --- |
| `pgTAP test file(s) written under supabase/tests/` | Any `.sql` file
exists | The agent never wrote one. |
| `supabase test db runs at least 8 assertions and all pass` | Suite
runs, ≥8 assertions, none failing | Nothing to run. The only example was
`plan(4)`, under the floor even if copied perfectly. |
| `tests assert allow and deny per operation … for anon and
authenticated` | LLM judge on coverage | Never reached the judge: "no
test files to review". |
The guide already had a `Test your policies` section, so this isn't a
strength problem. Agents don't read the page. They fetch it through an
LLM extraction guided by their own query, and that query asked for
enabling RLS, policy syntax, `auth.uid()`, indexes, and security definer
functions. It never mentioned tests. A section about testing never
enters the extract, so more testing prose cannot reach the agent.
There was also a plain documentation bug underneath it: `Secure a table
with RLS` said a table isn't secured until the suite passes, but the
procedure beneath it ran 1–3 and ended on `grant`. A reader following
the numbered steps finished without ever being told to write a test.
## Solution
Put the tests where the procedure and the examples already are.
- **`Secure a table with RLS`** opens with the four steps that finish a
table, ending on `supabase test db`. Until the suite passes, you don't
know whether the policies do what you intended.
- **`Enable RLS and set the grants` gains step 4** — `supabase test new
<table>_rls.test`, then `supabase test db`. The procedure ends on a
passing suite instead of a grant.
- **The public-read example** gains its policy and
`announcements_rls.test.sql`, so a test file rides along in the
enable-RLS extract.
- **The four policy examples** are followed immediately by
`profiles_rls.test.sql`, so one rides along in the `create policy`
extract too.
- **`Run the test suite` shrinks** to creating and running the files. It
no longer carries content that has to survive extraction.
- Each file leads with its own path as a comment, so it survives if the
fence metadata is dropped.
### How that maps to the three checks
| Check | Addressed by |
| --- | --- |
| Test files written | A complete test file now sits inside both
extracts an agent's own query pulls, and step 4 of the procedure names
the command that creates one. |
| ≥8 assertions, all passing | `announcements_rls.test.sql` is
`plan(10)`, `profiles_rls.test.sql` is `plan(14)`. Either alone clears
the floor; together, 24. |
| Coverage judge | `profiles` asserts allow **and** deny for all four
operations. Allowed writes use `returning` + `results_eq`, proving state
changed rather than that nothing raised. `using`-filtered denials use
`is_empty`, asserting the row is unchanged rather than that an error was
raised — the case the rubric explicitly fails suites for getting wrong.
Both files switch role with `set local role` and identity with `set
local request.jwt.claim.sub`, and cover `anon` as well as
`authenticated`. |
## Manual testing
1. Open the [Row Level Security
guide](https://docs-git-docs-rls-tests-in-procedure-supabase.vercel.app/docs/guides/database/postgres/row-level-security)
on the preview. `Secure a table with RLS` opens with a four-step
definition of done ending on `supabase test db`.
2. Read `Enable RLS and set the grants`. The procedure runs 1–4 and ends
on writing and running the test, not on the grant.
3. Scroll to `DELETE policies`. The four policies are followed
immediately by `profiles_rls.test.sql`, not a pointer to a later
section.
4. Open the [markdown
version](https://docs-git-docs-rls-tests-in-procedure-supabase.vercel.app/docs/guides/database/postgres/row-level-security.md),
which is what agents fetch. Both test files are present, each leading
with its path.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Documentation
- Updated database security guidance for enabling row-level security and
configuring grants.
- Added per-table pgTAP testing requirements and revised `supabase test
db` examples.
- Expanded examples for permitted and denied access across public and
authenticated roles.
- Added dedicated guidance for profile testing and security-definer
member/non-member cases.
- Documented recursive-policy `42P17` failures and the security-definer
workaround.
- Clarified indexing, denial diagnosis, returned-row verification, and
table-hardening links.
- Streamlined the general policy-testing guidance.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
## Problem
The guide alternated between context, procedure, and reference on almost
every heading. A reader who wanted to write a policy passed through four
context or reference sections to reach one. A reader who wanted the
model had to skip three procedures.
## Solution
- Group into three sections by information type: `Understand Row Level
Security`, `Secure a table with RLS`, and `RLS reference`, with a
navigation intro.
- Merge the four policy sections. They repeated the same setup block,
burying the clause that differed. One setup block now precedes four
short policy examples.
- Move the auto-enable recipe into `event-triggers.mdx`, whose stub
section's entire body was a link back here.
- Relocate the stranded `auth.uid()` caution into the `auth.uid()`
reference.
- Lift the revoke-and-grant procedure out of the danger admonition and
merge it with the two other places that taught `enable row level
security`.
- Point the Grafana IO chart entry at the performance guide. Its
`#rls-performance-recommendations` anchor went away when tuning split
out in #49016.
765 lines to 582. 30 headings to 25.
Headings are demoted rather than renamed wherever anything links to
them. Every inbound anchor in the repo still resolves; the only one
removed, `#auto-enable-rls-for-new-tables`, was referenced solely by the
`event-triggers.mdx` stub this PR replaces.
## Note on the history
Rebuilt from `master` after #49011, #49015, and #49016 merged. The
branch previously carried those 10 commits plus rebase churn against
them.
Rebasing naively would have reverted review feedback from #49016
(`70fa812`), which removed the benchmarks table and the "This guide"
opener from the performance guide. Those are deliberately not restored
here. The only changes to that file are two missing `await`s and a join
predicate that was a tautology while unqualified.
The three PRs stacked on this one (#49268, #49269, #49270) have been
rebased onto the new base.
## Manual testing
1. Open the [Row Level Security
guide](https://docs-git-docs-rls-restructure-supabase.vercel.app/docs/guides/database/postgres/row-level-security)
on the preview. Three top-level sections appear in the table of
contents.
2. Select each link in the intro. All three jump to their section.
3. Open [Event
triggers](https://docs-git-docs-rls-restructure-supabase.vercel.app/docs/guides/database/postgres/event-triggers).
The auto-enable section holds the full recipe instead of a link.
4. Open the [performance
guide](https://docs-git-docs-rls-restructure-supabase.vercel.app/docs/guides/database/postgres/row-level-security-performance).
No benchmarks table, and the three bullets at the top link into the RLS
guide.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Reworked the Row Level Security guide with clearer guidance on grants,
policies, permissions, performance, testing, views, and secure
functions.
* Added a complete example for automatically enabling RLS on newly
created public tables.
* Improved SQL examples and clarified table references in RLS
performance guidance.
* Corrected grammar in the Grafana chart troubleshooting documentation.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Stacked on #49015, which is stacked on #49011. Review those first.
## Problem
The Row Level Security guide spent 225 lines and 5 benchmark tables on
performance, 29% of the page. The `RLS Performance and Best Practices`
troubleshooting entry already covers the same six tips with the same
numbers, from the same source. Neither page tells you how to check
whether RLS is your bottleneck in the first place.
Four of the six tips are not tuning advice. Indexes, `select`-wrapping,
role scoping, and `security definer` safety change whether a policy is
correct and safe, not just fast.
## Solution
- Add `guides/database/postgres/row-level-security-performance`. It
carries the client-filter rule, the join-rewrite rule, all 5 benchmark
tables merged into one, and a new `Diagnose whether RLS is the
bottleneck` section: toggle RLS off to confirm it's the cost, then read
the plan under an impersonated role. That diagnostic exists in the
troubleshooting entry and has never been in the guide.
- Keep every rule that affects correctness on the RLS guide, grouped
under `Write policies that scale`. These are also the four the
`build-docs-002-rls-guide` eval grades, and an agent reads the guide
top-down.
- Repoint the Grafana IO troubleshooting entry at the new page.
- Rewrite `More resources` as `Related content`. Every link now says
what it is and when to use it. Adds `Advanced pgTAP testing`, the
deepest RLS testing content in the docs, which nothing here linked.
Drops discussion 14576: locked, mislabeled here as "RLS Guide and Best
Practices" when it is "RLS **Performance** and Best Practices", and
superseded by the troubleshooting entry and this new page.
**Ownership rule** so the two pages don't drift: the RLS guide owns the
rule and the correct form. The performance page owns the measurement and
the optimizer explanation. If a sentence on the performance page tells
you what to write, it belongs on the guide.
Scoped out of this PR: `More resources` was assigned to the restructure
PR in the plan, but the 14576 link is what this PR supersedes, so
leaving it would ship a stale pointer.
## Manual testing
1. Open the [RLS performance
guide](https://docs-git-docs-rls-performance-split-supabase.vercel.app/docs/guides/database/postgres/row-level-security-performance)
on the preview. It appears in the left nav under Database, Access and
security, directly below Row Level Security.
2. Select the three rule links in its intro. Each lands on the matching
section of the RLS guide.
3. Open the [Row Level Security
guide](https://docs-git-docs-rls-performance-split-supabase.vercel.app/docs/guides/database/postgres/row-level-security)
and go to `Write policies that scale`. It holds indexes,
`select`-wrapping, and role scoping, with one link out to the
performance page.
4. Open the [Grafana IO troubleshooting
entry](https://docs-git-docs-rls-performance-split-supabase.vercel.app/docs/guides/troubleshooting/interpreting-supabase-grafana-io-charts-MUynDR)
and select the RLS performance guide link. It lands on the new page.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Added a dedicated guide for diagnosing and improving PostgreSQL Row
Level Security performance.
* Expanded guidance on indexing, query filters, role targeting, function
usage, and avoiding costly policy joins.
* Updated the Row Level Security guide with streamlined, scalable policy
recommendations and links to related resources.
* Added the new performance guide to the Database documentation
navigation.
* Updated troubleshooting guidance to reference the dedicated
performance guide.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Stacked on #49011. Base is `docs/rls-revision`, so review that one
first.
## Problem
An audit of the Row Level Security guide against
`apps/docs/CONTRIBUTING.md` and `WORD_LIST.md` turned up 4 lint warnings
and 3 things that are wrong rather than just untidy.
- Two SQL examples contradict the guide's own advice. The own-profile
`SELECT` policy has no `TO` clause. The `security definer` example has
no `set search_path`.
- `## Bypassing Row Level Security` says Service Keys bypass RLS, then a
note says Supabase adheres to the signed-in user's policy anyway. The
condition that separates the two is never stated.
- `#using-functions` is linked twice from the RBAC guide and has never
existed on the RLS page.
## Solution
Copy and correctness only. No section moves, no heading renames.
- Replace the italic emphasis on `never` with bold. CONTRIBUTING permits
**bold** for a term the reader must not miss, not italics for general
emphasis. The matching fix for `must` lives in #49011, which rewrites
that line anyway.
- Drop marketing language from the opener, the Supabase intro, and the
policies and performance leads. Removes the idiom "get the hang of them"
and the filler `just`.
- Replace `we` with second person in two places.
- Scope the own-profile `SELECT` example with `to authenticated`.
- Pin `search_path = ''` on the `security definer` example,
schema-qualify its body to match, and state the requirement in prose.
- State when a Service Key actually bypasses RLS.
- Repoint the two RBAC links to `#use-security-definer-functions` and
`#helper-functions`.
`supa-mdx-lint` on the RLS guide goes from 4 warnings to 0.
## Manual testing
1. Open the [Row Level Security
guide](https://docs-git-docs-rls-copy-fixes-supabase.vercel.app/docs/guides/database/postgres/row-level-security)
on the preview. The own-profile SELECT example shows `to authenticated`,
and the security definer example shows `set search_path = ''`.
2. Open the [RBAC
guide](https://docs-git-docs-rls-copy-fixes-supabase.vercel.app/docs/guides/api/custom-claims-and-role-based-access-control-rbac)
and select the "RLS helper functions" link near the end. It lands on the
Helper functions section instead of the top of the page.
3. From `apps/docs`, run `pnpm lint:mdx`. The RLS guide reports no
warnings.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Documentation**
- Updated access-control guidance with clearer links for
security-definer functions and RLS helper functions.
- Clarified that exposed tables require Row Level Security (RLS), while
table grants and row policies provide separate controls.
- Added least-privilege and grant-revocation examples, plus explanations
for authorization errors.
- Expanded testing guidance for CRUD policies, identity switching, and
denied operations.
- Improved recommendations for service keys, policy performance,
indexing, and secure function configuration.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Closes DOCS-1274
## Problem
The `build-docs-002-rls-guide` eval points an agent at the Row Level
Security guide with a vibe-coder prompt that never says RLS, policy,
role, or test. It failed 6 of 35 checks. Each failure traces to
something the guide doesn't say.
- **Grants.** `anon` kept insert, update, and delete on all four to-do
tables. Both client roles kept writes on the weather feed. 24 privileges
untouched.
- **Indexes.** Missing on `list_members.user_id`. The agent indexed the
other three, so it missed the composite-primary-key case specifically.
- **Tests.** No pgTAP files. `Result: NOTESTS`, so the coverage judge
never ran.
## Solution
- **Add a `Grants and policies` section.**
- **Rewrite the opening danger admonition around revoke-then-grant.** It
previously showed `grant` only, which reads as though privileges start
from nothing.
- **Drop the `(or primary keys)` carve-out from `Add indexes`.** A
column counts as indexed only when it leads a `btree` index, shown with
a composite-primary-key example.
- **Add a `Test your policies` section.** Covers file location under
`supabase/tests/`, `supabase test db`, role and identity switching,
which assertion matches which denial, and an 11-assertion example
spanning allow and deny for all four operations across `anon` and
`authenticated`.
Used the supacademy RLS course as a second reference. Its framing of
grants running before RLS shaped the new section.
## Manual testing
1. Open the [Row Level Security
guide](https://docs-git-docs-rls-revision-supabase.vercel.app/docs/guides/database/postgres/row-level-security)
on the preview. `Grants and policies` and `Test your policies` appear in
the table of contents.
2. Select the `Grants and policies` link at the end of the first
admonition. It jumps to the new section.
3. Open the [markdown
version](https://docs-git-docs-rls-revision-supabase.vercel.app/docs/guides/database/postgres/row-level-security.md),
which is what agents fetch. Both new sections and the revised `Add
indexes` text are present.
4. From `apps/docs`, run `pnpm lint:mdx`. The 4 warnings on this file
match `master`, with no new ones.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Documentation
* Clarified that exposed tables must enable row-level security.
* Explained the distinction between database grants and row-level
security policies.
* Added least-privilege examples for client roles, including read-only
access.
* Added pgTAP testing guidance with a complete `profiles` example.
* Clarified that composite indexes support policy filters only on their
leading columns.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Closes DOCS-1057
Contributes to DOCS-1052
## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
## Problem
We have hundreds of MDX lint warnings in our docs going against style
best practices.
## Solution
Remove and replace in context the following:
- PostgreSQL. There was only one. There was concern about exceptions,
but I found none.
- Just
- Quickly
- Actually
### What changed
Edits follow the [Google developer documentation style
guide](https://developers.google.com/style): concise, direct, active
voice. The flagged words were removed when the sentence still read well,
or replaced when meaning needed to be preserved.
### Common patterns
| Flagged word | Approach | Example |
|---|---|---|
| **just** (filler) | Removed | "you just installed" → "you installed" |
| **just** (limiting) | **only** | "just one row" → "only one row" |
| **just like** | **like** / **the same as** | "function just like
regular users" → "function like regular users" |
| **not just** | **not only** | "not just errors" → "not only errors" |
| **quickly** (performance) | **efficiently** or removed | "find rows
quickly" → "find rows efficiently" |
| **quickly** (time) | **soon** / **rapidly** / removed | "expires too
quickly" → "expires too soon" |
| **actually** (filler) | Removed | "actually execute" → "execute"; "is
actually the most common" → "is the most common" |
## Tophatting
1. See the diff.
2. See that content continues to make sense in context.
3. Locally, `cd apps/docs` and run `pnpm run lint:mdx`.
4. Search for "just," "actually," "quickly", and "PostgreSQL" and see
there are 0 warnings.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Updated wording across quickstarts, guides, and troubleshooting
articles for grammar, clarity, and consistent step-by-step phrasing.
* Clarified key concepts including Row Level Security policy evaluation
across Supabase products, deferred foreign key constraint behavior, and
when `EXPLAIN ANALYZE` executes queries (and related side effects).
* Refined several troubleshooting instructions and added guidance to cap
log payload size to reduce billed Logs Ingest volume.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Nik Richers <nrichers@gmail.com>
Co-authored-by: Chris Chinchilla <chris.ward@supabase.io>
Contributes to DOCS-1052
Contributes to DOCS-1057
## 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?
Resolves linting warning for "let's" and adds an exception for product
name.
## Tophatting
1. Read the diff and see if changes make sense in context.
2. Run `pnpm lint:mdx`, search for "let's" and see no instances.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Updated instructional copy across multiple AI, authentication,
database, functions, realtime, storage, and troubleshooting guides to
improve clarity and consistency.
* Replaced conversational phrasing (for example, “Let’s…/Let’s see…”)
with direct imperatives, tightened example lead-ins, and adjusted a few
step explanations for readability.
* Refreshed some tutorial text and code-sample presentation in guides
(no behavioral changes).
* Added/adjusted minor MDX lint guidance in a couple of documents.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Nik Richers <nrichers@gmail.com>
## What kind of change does this PR introduce?
Docs update. Related to DEPR-551.
## What is the current behavior?
Docs MDX still uses the legacy `label` prop for Admonitions, even though
#45618 added `title` and kept `label` only as a backwards-compatible
alias after #45302 was reverted in #45535.
## What is the new behavior?
Migrates Docs-owned Admonitions from `label=` to `title=` without
changing rendered copy, component APIs, Studio callsites, design-system
examples, or the legacy `label` alias.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Standardized admonition headings across the docs by switching how
admonition headings are provided (preserving all visible guidance and
examples). Content and instructions remain unchanged; this ensures
consistent rendering of callouts and improves uniformity across guides
and reference pages.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46053?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 -->
---------
Co-authored-by: Chris Chinchilla <chris.ward@supabase.io>
## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Instructed granting least-privilege table permissions for anon,
authenticated, and service roles prior to enabling Row Level Security
across multiple guides and quickstarts.
* Clarified SQL examples and inline comments, added explicit GRANT steps
and RLS SELECT policies, rephrased policy guidance, and adjusted example
ordering and section numbering for clearer setup and testing.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Updated SDK initialization examples to reflect current authentication
patterns across multiple Supabase integration guides
* Enhanced security documentation with expanded guidance on protecting
sensitive credentials like secrets and service role keys in frontend and
Edge Function environments
* Clarified Row-Level Security access patterns and data availability
considerations when using publishable keys
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: fadymak <dev@fadymak.com>
Summary
- move the auto-enable RLS trigger SQL example from the event trigger
guide into the row-level-security guide with a full example
- keep a reference in the event trigger guide that points to the
row-level-security section instead of duplicating the SQL snippet
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Reorganized PostgreSQL Row Level Security documentation with a new
dedicated guide section on automatically enabling RLS for newly created
tables
* Note: Auto-enable RLS applies only to tables created after
installation; existing tables require manual enabling
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
* fix: rewrite relative URLs when syncing to GitHub discussion
Relative URLs back to supabse.com won't work in GitHub discussions, so
rewrite them back to absolute URLs starting with https://supabase.com
* fix: replace all supabase urls with relative urls
* chore: add linting for relative urls
* chore: bump linter version
* Prettier
---------
Co-authored-by: Chris Chinchilla <chris.ward@supabase.io>
Seems like at some point surrounding the security definer function private.has_good_role() with a select (like all functions should have for RLS) was changed. I can't find the PR doing it though.
* Add caution on Update Policy section for need to create Select Policy
* Update apps/docs/content/guides/database/postgres/row-level-security.mdx
---------
Co-authored-by: bulut yerli <bulut@buluts-Mac-mini.local>
Co-authored-by: Charis <26616127+charislam@users.noreply.github.com>
Unless there is some new SQL I'm not familiar the code shown:
`grant bypassrls on "table_name" to "role_name";`
Will not work and instead should be:
`alter role "role_name" with bypassrls;`
Danny White
