Florian WildeandClaude Opus 5
abacad1cb7
Eine veroeffentlichte Vorlagen-Version ist fuer immer unveraenderlich — daran haengt, dass ein archivierter Lauf in zehn Jahren noch genau die Schritte zeigt, mit denen er gestartet wurde. Die Regel steht deshalb zweimal: im Service, der die verstaendliche Meldung gibt, und in der Datenbank, die die Garantie gibt. Vier Trigger fangen Schreibzugriffe ab, die nicht durch den Service kommen — Migrationen, psql, der Seed und ab Phase 4 die Connectoren — und versperren den Rueckweg nach ENTWURF, der alles andere ausgehebelt haette. - Service: anlegen, Kopfdaten bearbeiten, Entwurf als tiefe Kopie der letzten veroeffentlichten Version, speichern, veroeffentlichen, verwerfen, duplizieren, archivieren - Hoechstens ein Entwurf je Vorlage, durchgesetzt vom partiellen Index; zwei gleichzeitige Klicks auf „Bearbeiten“ bekommen denselben Entwurf statt eines Fehlers - Optimistisches Sperren ueber geaendertAm: wer auf einem ueberholten Stand speichert, wird abgewiesen statt die Arbeit des anderen spurlos zu ersetzen - JSON-Export und -Import samt Format-Dokumentation; der Export ist nachsichtig, der Import streng - src/lib/validierung.ts als einzige Zod-Quelle mit deutschen Meldungen, per ESLint-Regel erzwungen Der unabhaengige Review fand drei Blocker, alle an der Mandantengrenze: der Suchfilter brachte ein zweites OR mit und ueberschrieb die Kundenbedingung, Historie und Aufbau einer Version filterten gar nicht. Zu queries/vorlagen.ts gab es keinen Test — jetzt gibt es tests/vorlagen-sicht.test.ts. 428 Tests gruen (vorher 336). Schliesst #009 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
95 lines
3.9 KiB
PL/PgSQL
95 lines
3.9 KiB
PL/PgSQL
-- ---------------------------------------------------------------------------
|
||
-- HANDGESCHRIEBEN. Prisma hatte hier zusaetzlich sieben Loeschbefehle erzeugt:
|
||
-- vier zusammengesetzte Fremdschluessel (Mandantengrenze) und drei
|
||
-- Trigramm-Indizes (Archivsuche) aus der ersten Migration. Prisma kennt sie
|
||
-- nicht, weil sie sich im Schema nicht ausdruecken lassen, und will sie deshalb
|
||
-- bei jeder Migration entfernen. Die Loeschbefehle sind bewusst gestrichen.
|
||
--
|
||
-- tests/datenbankregeln.test.ts prueft, dass alle diese Objekte vorhanden sind –
|
||
-- ein versehentlich stehengelassener Loeschbefehl faellt dort sofort auf.
|
||
-- ---------------------------------------------------------------------------
|
||
|
||
-- Stand des Entwurfs, gegen den der Editor beim Speichern prueft.
|
||
ALTER TABLE "VorlagenVersion"
|
||
ADD COLUMN "geaendertAm" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP;
|
||
|
||
-- ---------------------------------------------------------------------------
|
||
-- Eine veroeffentlichte Version ist unveraenderlich.
|
||
--
|
||
-- Diese Regel traegt die Nachvollziehbarkeit des ganzen Archivs: ein Lauf zeigt
|
||
-- auch in zehn Jahren genau die Schritte, die damals abgearbeitet wurden.
|
||
-- Bisher stand sie nur in der Service-Schicht — Migrationen, psql, Skripte und
|
||
-- ab Phase 4 die Connectoren schreiben daran vorbei. Deshalb steht sie jetzt
|
||
-- auch hier.
|
||
--
|
||
-- TRUNCATE loest Zeilen-Trigger nicht aus; das Leeren der Testdatenbank bleibt
|
||
-- also moeglich.
|
||
-- ---------------------------------------------------------------------------
|
||
|
||
CREATE OR REPLACE FUNCTION laufzettel_version_unveraenderlich() RETURNS trigger AS $$
|
||
DECLARE
|
||
betroffene_version TEXT;
|
||
aktueller_status TEXT;
|
||
BEGIN
|
||
betroffene_version := COALESCE(NEW."versionId", OLD."versionId");
|
||
SELECT status::TEXT INTO aktueller_status
|
||
FROM "VorlagenVersion" WHERE id = betroffene_version;
|
||
|
||
IF aktueller_status = 'VEROEFFENTLICHT' THEN
|
||
RAISE EXCEPTION
|
||
'Version % ist veroeffentlicht und unveraenderlich (%).',
|
||
betroffene_version, TG_TABLE_NAME
|
||
USING ERRCODE = 'integrity_constraint_violation';
|
||
END IF;
|
||
RETURN COALESCE(NEW, OLD);
|
||
END;
|
||
$$ LANGUAGE plpgsql;
|
||
|
||
CREATE TRIGGER "VorlagenAbschnitt_unveraenderlich"
|
||
BEFORE INSERT OR UPDATE OR DELETE ON "VorlagenAbschnitt"
|
||
FOR EACH ROW EXECUTE FUNCTION laufzettel_version_unveraenderlich();
|
||
|
||
CREATE TRIGGER "VorlagenVariable_unveraenderlich"
|
||
BEFORE INSERT OR UPDATE OR DELETE ON "VorlagenVariable"
|
||
FOR EACH ROW EXECUTE FUNCTION laufzettel_version_unveraenderlich();
|
||
|
||
-- Schritte haengen ueber den Abschnitt an der Version, brauchen also den Umweg.
|
||
CREATE OR REPLACE FUNCTION laufzettel_schritt_unveraenderlich() RETURNS trigger AS $$
|
||
DECLARE
|
||
aktueller_status TEXT;
|
||
BEGIN
|
||
SELECT v.status::TEXT INTO aktueller_status
|
||
FROM "VorlagenAbschnitt" a
|
||
JOIN "VorlagenVersion" v ON v.id = a."versionId"
|
||
WHERE a.id = COALESCE(NEW."abschnittId", OLD."abschnittId");
|
||
|
||
IF aktueller_status = 'VEROEFFENTLICHT' THEN
|
||
RAISE EXCEPTION
|
||
'Der Abschnitt gehoert zu einer veroeffentlichten Version und ist unveraenderlich.'
|
||
USING ERRCODE = 'integrity_constraint_violation';
|
||
END IF;
|
||
RETURN COALESCE(NEW, OLD);
|
||
END;
|
||
$$ LANGUAGE plpgsql;
|
||
|
||
CREATE TRIGGER "VorlagenSchritt_unveraenderlich"
|
||
BEFORE INSERT OR UPDATE OR DELETE ON "VorlagenSchritt"
|
||
FOR EACH ROW EXECUTE FUNCTION laufzettel_schritt_unveraenderlich();
|
||
|
||
-- Der Weg zurueck von VEROEFFENTLICHT nach ENTWURF waere die Hintertuer, durch
|
||
-- die sich alles Obige aushebeln liesse.
|
||
CREATE OR REPLACE FUNCTION laufzettel_version_status_einbahn() RETURNS trigger AS $$
|
||
BEGIN
|
||
IF OLD.status = 'VEROEFFENTLICHT' AND NEW.status <> 'VEROEFFENTLICHT' THEN
|
||
RAISE EXCEPTION
|
||
'Eine veroeffentlichte Version laesst sich nicht wieder zum Entwurf machen.'
|
||
USING ERRCODE = 'integrity_constraint_violation';
|
||
END IF;
|
||
RETURN NEW;
|
||
END;
|
||
$$ LANGUAGE plpgsql;
|
||
|
||
CREATE TRIGGER "VorlagenVersion_status_einbahn"
|
||
BEFORE UPDATE ON "VorlagenVersion"
|
||
FOR EACH ROW EXECUTE FUNCTION laufzettel_version_status_einbahn();
|