From 0.21 to 0.22
What to check when upgrading to better-supabase 0.22, where app table write policies refuse read-only support and agent sessions, and Create issues share one Issue type.
0.22 closes a gap in the app tables: their insert, update and delete policies
now carry the actor_may_write() check that every block policy already had.
A read-only support or agent session could write to an app table before; it
can't after the migration.
Regenerate the app table policies
Run the upgrade, then generate and apply a migration:
npx better-supabase upgrade
npx better-supabase db diffThe diff replaces each app table's write policies with ones that add
and better_supabase.actor_may_write(), and defines the function when the
file needs it. Reads are unchanged.
If a job or test writes to an app table inside a read-only support session, it now fails with a row level security error. Run such writes as the service role or in a writable session.
Doctor's BS345 now treats the guard as tenant membership, so app tables that carry it no longer raise a false warning for attachment subjects.
Create and preset API
This affects code that imports better-supabase/create or
better-supabase/create/lite:
checkDesign,designIssuesandvalidateDesignreport oneIssuetype with aseverityand asource. RenameDesignIssuetoIssue, and readissue.fileandissue.tablewhere a lite issue hadpathandmodule.importProject,openSandboxanddesignDataApiare new.better-supabase/presetexports the instance rules (canAddInstance,blockRequires,withInstanceand the rest).
Last updated on
From 0.25 to 0.26
What to check when upgrading to better-supabase 0.26, where the tenant scope becomes one policy per command to public and the none scope refuses anonymous sign-ins.
From 0.20 to 0.21
What to check when upgrading to better-supabase 0.21, where db.$api returns a Result, block dates are Temporal values and every block table can be the app's own.