Restore the auth.users trigger and storage policies lost in the dev2 move - #327
Merged
Merged
Conversation
…move The 2026-09-25 move to the self-hosted stack on dev2 dumped DDL for the app schemas only, so on_auth_user_created and both storage.objects policies were dropped. This re-creates them idempotently and backfills profiles for users who signed up while the trigger was missing. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
ThreatCrush Security Scan49 finding(s) HIGH/CRITICAL: 2 | MEDIUM: 32 | LOW: 15
Snippets are redacted; ThreatCrush never prints matched credential material. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Cause
On 2026-09-25 the database moved from Supabase cloud to the self-hosted stack on dev2. Objects that live on
auth.*andstorage.*tables did not come across: theon_auth_user_createdtrigger ONauth.usersand both RLS policies ONstorage.objects. The public functions they call and the buckets (data) survived. Without the trigger, a signup gets nopublic.profilesrow, so everything keyed on profiles (projects, audits, credit_purchases, organizations) fails its foreign key for that user. Without the policies, owners cannot read their audit artifacts / PDF reports through RLS andsp-imagesis not readable through the API. The cloud project is deleted, so the migrations are the only source of truth.What this restores
supabase/migrations/20260926210000_restore_auth_storage_lost_in_dev2_move.sql, idempotent (DROP ... IF EXISTSthenCREATE), final state after replaying every migration in order:on_auth_user_createdAFTER INSERT ONauth.users→public.handle_new_user()(from0001_init.sql; function last redefined in0005_credits.sql, which still exists inpublic)storage.objectspolicy "artifact owner read" (0002_storage.sql)storage.objectspolicy "sp-images public read" (20260528210000_sp_project_social_config.sql)Backfill
public.profilesfor everyauth.usersrow without one, mirroring thehandle_new_user()INSERT exactly:(id, email, display_name, credits_balance)withdisplay_name = coalesce(full_name, email)and the function's literalcredits_balance = 3.ON CONFLICT (id) DO NOTHING; profiles has no other unique column, so no collision handling is needed. The function sends no email and calls no webhook.Note: the function hardcodes 3 credits while the column default has been 20 since
20260608010000_signup_grant_20_credits.sql, so real signups have been getting 3 as well. This PR keeps that behaviour rather than changing it silently; worth a separate fix.Not yet applied to dev2; will be dry-run and applied from the operator session.
🤖 Generated with Claude Code