Compare commits
1 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
344a33805a |
@@ -29,9 +29,22 @@ ALTER TABLE account DROP COLUMN IF EXISTS verified;
|
||||
-- betreiber Ebene 5 — Netcell-IT-Personal, plattformweit
|
||||
-- (Werkzeugkatalog, Regelwerk, Mandantenverwaltung);
|
||||
-- entspricht der alten "admin"-Rolle vor dieser Migration
|
||||
-- Die alten Rollen (creator/agentur/marke/kanzlei) haben im neuen
|
||||
-- Produkt keine Bedeutung mehr.
|
||||
--
|
||||
-- Die alte CHECK-Constraint muss zuerst weg, sonst lehnt sie die
|
||||
-- Datenmigration unten (die neue Rollenwerte wie "betreiber" schreibt)
|
||||
-- sofort ab — die alte Constraint kennt diese Werte ja noch nicht.
|
||||
ALTER TABLE app_user DROP CONSTRAINT app_user_role_check;
|
||||
|
||||
-- Bestehende Zeilen auf gültige neue Werte umstellen, bevor die neue
|
||||
-- Constraint das erzwingt — sonst schlägt sie auf jeder Installation
|
||||
-- mit echten Nutzern fehl. Die alte Rolle "admin" war der Plattform-
|
||||
-- Betreiber (Netcell-IT) — wird zu "betreiber", nicht zum neuen,
|
||||
-- mandantenbezogenen "admin". Alle anderen alten Rollen (creator/agentur/
|
||||
-- marke/kanzlei) waren gewöhnliche Mandanten-Logins ohne Sonderrechte —
|
||||
-- werden zu "mitarbeiter", der schlankesten neuen Rolle.
|
||||
UPDATE app_user SET role = 'betreiber' WHERE role = 'admin';
|
||||
UPDATE app_user SET role = 'mitarbeiter' WHERE role IN ('creator', 'agentur', 'marke', 'kanzlei');
|
||||
|
||||
ALTER TABLE app_user ADD CONSTRAINT app_user_role_check
|
||||
CHECK (role IN ('mitarbeiter', 'verantwortlicher', 'pruefer', 'admin', 'betreiber'));
|
||||
|
||||
|
||||
Reference in New Issue
Block a user