From b18a9b9e78a641a110e3f95e0da5f1a36c9cf2b8 Mon Sep 17 00:00:00 2001 From: renee-png Date: Tue, 16 Jun 2026 20:53:19 -0400 Subject: [PATCH] Status updates: restore staff write RLS policy The "Staff full access on status_updates" policy was missing from the live DB (dropped outside migrations), so all inserts/updates failed with "new row violates row-level security policy". Recreate it (admin/manager). Co-Authored-By: Claude Opus 4.8 --- ...10000_status_updates_staff_write_policy.sql | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 supabase/migrations/20260616210000_status_updates_staff_write_policy.sql diff --git a/supabase/migrations/20260616210000_status_updates_staff_write_policy.sql b/supabase/migrations/20260616210000_status_updates_staff_write_policy.sql new file mode 100644 index 0000000..543f4bc --- /dev/null +++ b/supabase/migrations/20260616210000_status_updates_staff_write_policy.sql @@ -0,0 +1,18 @@ +-- Restore the staff write policy on status_updates. The original "Staff full access +-- on status_updates" policy (from 20260315230415) was dropped from the live DB +-- outside of migrations, leaving only SELECT policies — so every INSERT/UPDATE/DELETE +-- failed with "new row violates row-level security policy". Recreate it (admin/manager +-- full access), matching the original design (employees keep read-only via the SELECT policy). +drop policy if exists "Staff full access on status_updates" on public.status_updates; +create policy "Staff full access on status_updates" +on public.status_updates +for all +to authenticated +using ( + has_role(auth.uid(), 'admin'::app_role) + or has_role(auth.uid(), 'manager'::app_role) +) +with check ( + has_role(auth.uid(), 'admin'::app_role) + or has_role(auth.uid(), 'manager'::app_role) +);