diff --git a/TASKS.md b/TASKS.md index 46a75e3..0bb4fd8 100644 --- a/TASKS.md +++ b/TASKS.md @@ -61,6 +61,12 @@ Das ist der schwierigste Teil. Wenn er steht, ist der Rest Formularbau. ## Phase 3 — Vorlagen und Abschnitte +- [ ] **Zuerst entscheiden**: gemeinsame Dokumentebene für Dokumentarten jenseits der + Fallakte (Bußgeld, Vertrag, Beurteilung). Bewertung und Empfehlung in + `docs/13-entscheidungen.md`, Abschnitt „Offen: Dokumentarten über die Fallakte hinaus" +- [ ] Feldtypen für Textkörper-Vorlagen ergänzen: fester Fließtext, Überschrift, + Platzhalter, Unterschriftenzeile — der Sonderarbeitsvertrag ist kein Formular + - [ ] `CaseTemplate` mit Feldtypen aus `docs/05-akten-und-vorlagen.md` - [ ] Aktenzeichen-Muster je Vorlage: Präfix und Stellenzahl, Nummernkreis je Präfix und Jahr - [ ] Feld „Foundation-Freigabe" als gewöhnliches Vorlagenfeld, ohne Wirkung auf den Zugriff diff --git a/docs/13-entscheidungen.md b/docs/13-entscheidungen.md index 5b04aa1..778c3d1 100644 --- a/docs/13-entscheidungen.md +++ b/docs/13-entscheidungen.md @@ -180,6 +180,76 @@ Präfix und ihre Stellenzahl mit, der Nummernkreis läuft je Präfix und Jahr. ` bekommt dafür einen zusammengesetzten Schlüssel aus Präfix und Jahr statt nur dem Jahr. Bestehende Aktenzeichen bleiben, wie sie sind. +## Offen: Dokumentarten über die Fallakte hinaus + +**Noch nicht entschieden, noch nichts gebaut.** Geprüft vor Phase 3, weil die Antwort den +Zuschnitt von Phase 3 und 4 bestimmt. + +Langfristig sollen weitere Dokumentarten dazukommen: Vorfallsberichte, Bußgelder, +Sonderarbeitsverträge, Beurteilungen. Die Frage ist, ob das Modell das trägt, ohne dass für +jede neue Art Code geschrieben wird. + +### Was heute schon trägt + +Eine neue **Fallart** braucht keine Zeile Code. `CaseTemplate.fields` ist ein JSON-Feld, +Vorlagen sind versioniert, und das Rendern der Abschnitte wird datengetrieben gebaut. Eine +neue Vorlage anzulegen ist eine Zeile in der Datenbank, kein Deployment. Mit dem Präfix je +Vorlage bekommt jede Fallart auch ihren eigenen Nummernkreis. + +### Was heute nicht trägt + +`CaseSection` hängt fest an `caseId`. **Alles, was kein Ermittlungsfall ist, hat keinen +Platz.** Ein Bußgeld gegen einen Mitarbeiter ist keine Ermittlung. Ein Sonderarbeitsvertrag +erst recht nicht. + +`PersonnelFile.fields` ist ein nacktes JSON-Feld ohne Vorlage. Ein Vertrag, der dort landet, +hätte nichts von dem, was eine Fallakte selbstverständlich hat: keine Versionierung, keinen +Diff, keine Begründungspflicht, kein `minClearance` je Feld, keinen Eintrag im +Zugriffsprotokoll. Genau die Eigenschaften, um derentwillen das System gebaut wird. + +Würde man Bußgelder und Verträge behelfsweise als `Case` führen, stünden sie in der +Fallliste, in der Fallzählung und in der Suche nach Ermittlungen. Das ist kein Schönheits- +fehler, sondern eine falsche Aussage über den Bestand. + +### Zwei Bauformen von Dokument, nicht eine + +Die beiden vorliegenden Beispiele sind grundverschieden aufgebaut: + +| | Vorfallsbericht | Sonderarbeitsvertrag | +|---|---|---| +| Aufbau | beschriftete Felder, ausgefüllt | fester Vertragstext mit Platzhaltern | +| Vorlage liefert | Feldliste | den Wortlaut selbst, samt Paragraphen | +| Nutzer trägt ein | Werte | `[Name]`, `[Datum]`, `[Tätigkeit]` | +| Ausgabe | eine Seite | mehrere Seiten mit Unterschriftenzeilen | + +Die Feldtypen aus `docs/05-akten-und-vorlagen.md` decken den **Bericht vollständig** ab +(`multiselect` für die Berichtsart, `select` für die Gefahreneinschätzung, `date`, `person`, +`longtext`). Für den **Vertrag reichen sie nicht**: fester Fließtext, Überschriften und +Unterschriftenzeilen sind keine Formularfelder. Dafür braucht die Vorlage einen Textkörper +mit Platzhaltern statt einer Feldliste. + +### Empfehlung + +Eine gemeinsame Dokumentebene, additiv statt als Umbau: + +- `DocumentTemplate` — was heute `CaseTemplate` ist, plus `scope` (Fall, Person, + eigenständig), `numberPrefix`, und `kind` (Formular oder Textkörper) +- `Document` — eine Ausfertigung, mit Vorlage, Klassifizierung, Nummer und einem Besitzer: + Fall, Personalakte oder nichts +- `DocumentSection` und `DocumentSectionVersion` — dieselben Zusicherungen wie bei + `CaseSection`: versioniert, `minClearance` je Feld, Diff, Protokoll + +`Case`, `CaseSection` und `CaseEntry` bleiben unangetastet. Eine Fallakte kann Dokumente +tragen, eine Personalakte auch, und ein Bußgeld steht für sich. + +Damit ist eine neue Dokumentart wieder das, was sie sein soll: **ein Datensatz, kein +Deployment.** + +Zu klären, bevor gebaut wird: ob die Abschnitte einer Fallakte langfristig ebenfalls über +diese Ebene laufen sollen. Dafür spräche, dass es dann nur einen Mechanismus gibt; dagegen, +dass `docs/04` und `docs/05` `CaseSection` ausdrücklich benennen und der Umbau bestehende +Akten anfasst. + ## Prisma 7 Die Dokumente nennen nur „Prisma + PostgreSQL 16". Eingesetzt wird Prisma 7, die diff --git a/packages/db/prisma/schema.prisma b/packages/db/prisma/schema.prisma index 160787a..8c3bc05 100644 --- a/packages/db/prisma/schema.prisma +++ b/packages/db/prisma/schema.prisma @@ -145,6 +145,12 @@ model CaseTemplate { description String? isActive Boolean @default(true) fields Json // TemplateField[] + + /// Muster des Aktenzeichens, siehe docs/13-entscheidungen.md. Die Abteilung + /// fuehrt gewachsene Praefixe wie "AKT-PA"; der Nummernkreis laeuft je + /// Praefix und Jahr, damit zwei Fallarten sich nicht in die Quere kommen. + numberPrefix String @default("AfiS") + numberPadding Int @default(4) createdAt DateTime @default(now()) createdById String? @@ -209,11 +215,14 @@ enum CaseStatus { SEALED } -/// Kollisionsfreie Vergabe des Aktenzeichens. Gelesen mit SELECT ... FOR UPDATE -/// in derselben Transaktion wie das Anlegen des Falls. +/// Kollisionsfreie Vergabe des Aktenzeichens, ein Nummernkreis je Praefix und +/// Jahr. Hochgezaehlt in derselben Transaktion wie das Anlegen des Falls. model CaseCounter { - year Int @id - lastNumber Int @default(0) + prefix String + year Int + lastNumber Int @default(0) + + @@id([prefix, year]) } model CaseSection {