You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Part 2 of the split of #41 (see that issue for background). Depends on #465 (slugify non-empty fallback) — land that first.
Goal
The DB is the single owner of slug generation on insert. sets and artists already have BEFORE INSERT dedupe triggers (supabase/migrations/20260804101202_add_slug_dedupe_triggers.sql) that derive a slug via public.slugify() when none is supplied. Extend the same pattern to the remaining tables and stop the client from computing slugs on create.
Work
Migration — add the same trigger pattern (derive from name when NEW.slug is empty/NULL, advisory-lock + -2 suffix dedupe within the relevant uniqueness scope) to:
groups
stages (scope: per festival_edition_id, matching its unique constraint)
festivals and festival_editions (check the actual table/constraint names and slug scoping in existing migrations, e.g. 20250808000001_add_festival_slugs.sql)
Make slug columns nullable-on-insert if they currently have NOT NULL without default in a way that blocks trigger-filled inserts (triggers run BEFORE, so likely fine — verify).
Client — remove generateSlug from the create paths so no slug is sent on insert:
src/api/groups/useCreateGroup.ts:20
src/api/stages/useCreateStage.ts:17
Festival create paths in src/pages/admin/festivals/FestivalDialog.tsx / FestivalEditionManagement.tsx (the create flows only; the slug edit field on update flows is Edit views: explicit slug field instead of silent re-slugging on rename #467's scope — keep any explicit user-entered slug pass-through working, since the triggers trust a caller-supplied slug)
Acceptance
Creating a group/stage/festival/edition without a slug gets a DB-generated, deduped, non-empty slug — including for non-Latin names.
Creating with an explicit slug (admin festival dialogs allow one) keeps that slug.
No generateSlug import remains in any create-path hook.
Integration tests cover a trigger-generated slug and a dedupe collision for at least one of the new tables.
Part 2 of the split of #41 (see that issue for background). Depends on #465 (slugify non-empty fallback) — land that first.
Goal
The DB is the single owner of slug generation on insert.
setsandartistsalready have BEFORE INSERT dedupe triggers (supabase/migrations/20260804101202_add_slug_dedupe_triggers.sql) that derive a slug viapublic.slugify()when none is supplied. Extend the same pattern to the remaining tables and stop the client from computing slugs on create.Work
Migration — add the same trigger pattern (derive from
namewhenNEW.slugis empty/NULL, advisory-lock +-2suffix dedupe within the relevant uniqueness scope) to:groupsstages(scope: perfestival_edition_id, matching its unique constraint)festivalsandfestival_editions(check the actual table/constraint names and slug scoping in existing migrations, e.g.20250808000001_add_festival_slugs.sql)Make slug columns nullable-on-insert if they currently have NOT NULL without default in a way that blocks trigger-filled inserts (triggers run BEFORE, so likely fine — verify).
Client — remove
generateSlugfrom the create paths so no slug is sent on insert:src/api/groups/useCreateGroup.ts:20src/api/stages/useCreateStage.ts:17src/pages/admin/festivals/FestivalDialog.tsx/FestivalEditionManagement.tsx(the create flows only; the slug edit field on update flows is Edit views: explicit slug field instead of silent re-slugging on rename #467's scope — keep any explicit user-entered slug pass-through working, since the triggers trust a caller-supplied slug)Acceptance
generateSlugimport remains in any create-path hook.