32 lines
1.6 KiB
SQL
32 lines
1.6 KiB
SQL
-- Backfill MANAGE_MEDIA_LIBRARY and MANAGE_REVIEWS (added in Phase 9)
|
|
-- onto every role that already holds MANAGE_STAFF — the app's existing
|
|
-- definition of "owner" (see src/services/staff/staff.service.ts's
|
|
-- countOtherActiveManagers, "A role holding MANAGE_STAFF is this app's
|
|
-- definition of 'an owner'"). syncRolePermissions() only ever runs at
|
|
-- install/seed time, so any business installed before Phase 9 has its
|
|
-- Owner role stuck on the old 15-permission set — confirmed by reading
|
|
-- the actual RolePermission rows on a real installed business before
|
|
-- writing this migration.
|
|
--
|
|
-- This is what silently made /owner/settings/reviews redirect away
|
|
-- (hasPermission(..., MANAGE_REVIEWS) failing, redirecting to /staff,
|
|
-- which then renders the barber calendar — looking exactly like
|
|
-- "Reviews opens Calendar") and made Media Manager deletes silently fail
|
|
-- (MANAGE_MEDIA_LIBRARY). Not a routing bug — a missing data backfill.
|
|
--
|
|
-- Idempotent: a fresh install's Owner role already has both permissions
|
|
-- from syncRolePermissions() at install time, and INSERT IGNORE plus the
|
|
-- existing @@unique([roleId, permission]) constraint make re-running
|
|
-- this migration (or running it against an already-correct database)
|
|
-- a safe no-op.
|
|
|
|
INSERT IGNORE INTO `RolePermission` (`id`, `roleId`, `permission`)
|
|
SELECT UUID(), owner.`roleId`, 'MANAGE_MEDIA_LIBRARY'
|
|
FROM `RolePermission` owner
|
|
WHERE owner.`permission` = 'MANAGE_STAFF';
|
|
|
|
INSERT IGNORE INTO `RolePermission` (`id`, `roleId`, `permission`)
|
|
SELECT UUID(), owner.`roleId`, 'MANAGE_REVIEWS'
|
|
FROM `RolePermission` owner
|
|
WHERE owner.`permission` = 'MANAGE_STAFF';
|