Vier Sachen aus der Durchsicht.
**Der Statusfilter zeigte fünf von sieben Zuständen.** DRAFT und SEALED
fehlten - ausgerechnet die beiden, die in der Liste am häufigsten standen; man
konnte nach dem, was man sah, gerade nicht filtern. Das erklärt auch die Frage,
was „In Prüfung" und „Ruhend" bedeuten: die Zustände standen nirgends in der
Oberfläche. Jetzt alle sieben in der Reihenfolge des Lebenszyklus, mit einer
Erklärung als title, und Versiegelt nur für den, der Versiegeltes lesen darf.
Ein Test verlangt zu jedem Zustand einen Namen und eine Erklärung.
**Beliebig viele Beteiligte beim Anlegen.** Das Formular kannte genau eine
„betroffene Person", und die Rolle war auf SUBJECT festgelegt. Jetzt beliebig
viele Zeilen mit je einer Rolle, Konten und Personalakten in einer Auswahl, wie
auf der Aktenseite. Die Zerlegung steht als parseParticipantDrafts in
lib/cases/terms.ts und nicht in der Server Action: seit die Rolle über den
Zugriff entscheidet, darf eine erfundene Rolle nicht durchrutschen.
**Die Filterleisten sind Knöpfe** wie überall sonst, mit gefülltem aktivem
Filter.
**Keine leere Kennungsspalte mehr.** In „Zuletzt geöffnet" stand bei einer
Person nichts, wo sonst das Aktenzeichen steht - jetzt steht dort
„Personalakte". Nebenbei zwei Stellen zurückgenommen, an denen die
Spaltenklasse im Seitenkopf gelandet war statt in einer Zeile.
Punkt 1 und 2 der Wünsche, plus zwei Lücken, die dabei sichtbar wurden.
**Suche.** Wer nach Alvarez sucht, landet auf den Fallakten und erfährt nie,
dass es dazu auch eine Personalakte gibt: die Suche fand sie, aber hinter einem
Reiter, auf den nichts hindeutete. Die Reiter tragen jetzt ihre Trefferzahl,
und ein leeres Ergebnis nennt ausdrücklich, wo etwas liegt.
Dabei fiel auf, dass searchPersonnel das Recht personnel.read nicht prüfte. Die
Kommandopalette tat es, die Aktenseite tat es, die Suche nicht - über
/suche?kind=personnel kam jeder mit ausreichender Stufe an eine Liste aller
Personalakten mit Namen, Dienstgrad und Etiketten. Die Prüfung steht jetzt
dort, wo diese Akten herausgegeben werden. Die Trefferzahl einer Art, die es
für den Nutzer nicht gibt, ist null und nicht 0: eine Null wäre die Auskunft
„hier ist nichts", und die steht ihm nicht zu.
**Täter und Mittäter** als Beteiligtenrollen - und damit wurde eine ältere
Lücke offensichtlich: ein Beteiligter durfte die Akte lesen, gleich in welcher
Rolle. Bei „Betroffener" fiel das nicht auf, bei „Täter" wäre es offensichtlich
falsch. Der Beschuldigte hätte die Ermittlung gegen sich selbst mitgelesen.
Die Beteiligtenliste beantwortet zwei Fragen: wer bearbeitet den Fall, und um
wen geht es darin. Nur die erste ist eine Berechtigung. WORKING_ROLES nennt die
drei, die die Akte öffnen; Zeuge, Betroffener, Täter und Mittäter öffnen
nichts. Das gilt an allen vier Stellen, die auf Beteiligung prüften:
Aktenzugriff, Dokumentzugriff über die besitzende Akte, „meine Fälle" und der
Filter „nur meine".
Zwei bestehende Tests hatten die alte Annahme festgeschrieben und benutzten
WITNESS, um Zugriff zu belegen; sie prüfen jetzt mit INVESTIGATOR.
Die Dokumentebene aus docs/13 ist gebaut, additiv: Document, DocumentSection
und DocumentSectionVersion neben Case, CaseSection und CaseEntry. Ein Dokument
hängt an einer Fallakte, an einer Personalakte oder an nichts, höchstens an
einem - gesichert durch eine CHECK-Bedingung. Es gibt kein DELETE; eine
Zurücknahme lässt einen Grabstein stehen, der auch für den Admin zu ist.
Eine neue Dokumentart ist damit ein Datensatz, kein Deployment. Im Seed stehen
vier: vermerk, vorfallsbericht, sonderarbeitsvertrag (mehrseitiger Vertragstext
mit Platzhaltern und Unterschriftenzeilen) und bussgeld.
Zwei Umbenennungen, beide von Hand migriert, damit die vorhandenen Zeilen und
Zählerstände stehen bleiben:
- CaseTemplate -> DocumentTemplate, plus uses[] und layout
- CaseCounter -> NumberSeries, ein Nummernkreis je Präfix für Aktenzeichen
und Dokumentnummern
Die Regeln für Abschnitte stehen jetzt einmal in lib/sections/render.ts und
gelten für Fallakten und Dokumente gleichermaßen. Die Frage aus docs/13, ob
CaseSection langfristig in die Dokumentebene wandert, ist damit verneint und
begründet.
Rückverweise auf der Personalakte laufen durch visibleCaseWhere, die Zahl
daneben entsteht aus dem gefilterten Ergebnis. Auch die Rollengruppe
verschwindet mit, sonst verriete "Betroffener" ohne Eintrag die Ermittlung.
Die eigene Personalakte ist keine Ausnahme von der Freigabestufe.
Vier neue Rechte: document.create, .edit, .finalize, .retract. Das letzte
steht bei den zurückgehaltenen, es greift in Geschriebenes ein.
91 Tests im Web-Paket, 15 in der Datenbank, 28 e2e. Größte Route 118 kB
gegen das Budget von 120 kB - die Luft wird knapp.
Harlekin