Personalakte als Aktenblatt, Status als Etiketten, Verknüpfen von beiden Seiten

Das Formular der Personalabteilung ist übernommen, nicht durch eine
Bildschirmansicht ersetzt: schwarzer Rahmen, Kopf mit Kennung und
Klassifizierungsbalken, Raster aus fünf Spalten, Unterschriftenzeilen,
Fußzeile. Es steht bewusst außerhalb des Design-Systems — es wird gedruckt und
muss auf Papier aussehen wie das Blatt daneben.

Datengetrieben bleibt es trotzdem. Kein Feld steht im Programm: sheetTitle und
sheetSubtitle an der Vorlage, span für die Zellbreite, rows für das Lichtbild,
dateKey für das Datum unter einer Unterschrift, slot für den
Klassifizierungsbalken. Eine weitere Dokumentart mit layout = DOSSIER braucht
keine Zeile Code.

Der Balken zeigt die Foundation-Stufe aus der neuen Tabelle
FoundationClearance. Sie ist Inhalt, kein Zugriff — was jemand sehen darf,
entscheidet weiterhin allein die interne Stufe. Ohne Auswahl bleibt der Balken
neutral, statt eine Einstufung zu behaupten.

Die Dienstnummer ist entfallen, es gibt sie nicht. Der Status ist zu mehreren
Etiketten geworden: "Gekündigt" und "Verhaftet" schließen einander nicht aus.
Unbekannte Schlüssel werden verworfen und die Reihenfolge kommt aus der
Konfiguration, nicht aus der Eingabe.

PersonnelAssignment hängt AfiS-Mitglieder an eine Person — Aktenführung,
Ermittler, Ansprechpartner — und ist zugleich der ausnahmsweise Zugang, wie
CaseParticipant bei der Fallakte. Betroffen zu sein gibt weiterhin keinen
Zugang: das ist eine Eigenschaft der Person, die Zuordnung eine Entscheidung
der Abteilung.

Fall und Person lassen sich von beiden Seiten verknüpfen und schon beim
Anlegen einer Fallakte. Alle drei Wege laufen in addParticipant zusammen.

Noch offen: das Lichtbild. Feldtyp und Platz stehen, hochladen kommt mit der
Prüfkette in Phase 5 — ein Bild als Data-URL im Abschnittswert verstiesse
gegen harte Regel 4.

102 Tests im Web-Paket, davon sechs auf dem gerenderten Blatt selbst.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Harlekin
2026-09-02 19:56:28 +02:00
co-authored by Claude Opus 5
parent d65cc95eb2
commit 68ad0debd3
35 changed files with 2346 additions and 91 deletions
+89 -6
View File
@@ -299,15 +299,21 @@ müssen: der Besitzer muss lesbar sein, und das Dokument selbst muss es sein. Ei
Stufe 1 an einer Personalakte der Stufe 4 bleibt verborgen — sonst verriete die
Dokumentenliste die Existenz der Person.
## Die eigene Personalakte ist keine Ausnahme
Eine Fallakte kennt den ausnahmsweisen Zugang über `CaseParticipant`. Eine Personalakte hat
nichts Vergleichbares, und insbesondere darf **die betroffene Person ihre eigene Akte nicht
allein deshalb lesen**, weil sie es ist.
## Betroffen zu sein gibt keinen Zugang, zugeordnet zu sein schon
**Die betroffene Person darf ihre eigene Akte nicht allein deshalb lesen**, weil sie es ist.
Der Gedanke lag nahe: die eigene Akte kennt man doch. Er ist trotzdem falsch. Eine Beurteilung
auf Stufe 4 über einen Mitarbeiter der Stufe 1 wäre sonst genau für den einen Menschen
lesbar, vor dem sie geschützt werden soll. Es zählt allein die Freigabestufe.
lesbar, vor dem sie geschützt werden soll.
Den **ausnahmsweisen Zugang** gibt es trotzdem, nur über einen anderen Weg: `PersonnelAssignment`
trägt ein AfiS-Mitglied als Aktenführung, Ermittler oder Ansprechpartner an einer Person ein,
und wer dort steht, liest die Akte unabhängig von seiner Stufe. Das ist dieselbe Bauart wie
`CaseParticipant` bei der Fallakte: er entsteht nur durch eine bewusste Eintragung von jemandem,
der `personnel.edit` hat, und wird protokolliert.
Die beiden Wege dürfen nicht verwechselt werden. Der eine ist eine Eigenschaft der Person, der
andere eine Entscheidung der Abteilung.
## Rückverweise zählen nur, was sichtbar ist
@@ -386,3 +392,80 @@ Eintragsrechten. Gemeinsames Merkmal: sie greifen in bereits Geschriebenes ein.
Im Auslieferungszustand hat keine Rolle diese Rechte. Bis der Leiter sie im Adminbereich
verteilt, legt nur der Administrator Dokumente an.
## Die Personalakte ist ein Aktenblatt, kein Formular der Anwendung
Die Abteilung führt Personalakten bislang als ausgefülltes Blatt: schwarzer Rahmen, Kopf mit
Kennung und Klassifizierungsbalken, ein Raster aus fünf Spalten, Unterschriftenzeilen,
Fußzeile. Dieses Blatt ist übernommen worden, nicht durch eine Bildschirmansicht ersetzt.
Es steht damit bewusst **außerhalb des Design-Systems** aus `docs/10-design-system.md`. Kein
Farb-Token der Oberfläche kommt darin vor, die Maße stehen in Millimetern, und die Farben sind
fest. Der Grund ist einfach: das Blatt wird gedruckt und weitergereicht, und auf Papier muss es
aussehen wie das Blatt daneben. Ein Formular, das sich dem Bildschirmthema anpasst, ist kein
Formular mehr.
### Es ist trotzdem datengetrieben
Kein einziges Feld steht im Programm. Das Blatt entsteht aus `DocumentTemplate` wie jedes
andere Dokument:
| Was | Woher |
|---|---|
| Überschriften im Kopf | `sheetTitle`, `sheetSubtitle` an der Vorlage |
| Welche Felder, in welcher Reihenfolge | `fields` |
| Breite einer Zelle im Raster | `span`, 1 bis 5 Spalten |
| Zeilen, über die das Lichtbild reicht | `rows` am Feld vom Typ `photo` |
| Datum unter einer Unterschrift | `dateKey` am Feld vom Typ `signature` |
| Inhalt des Klassifizierungsbalkens | Feld mit `slot: 'classbar'` |
Damit trägt dieselbe Bauform später einen Vorfallsbericht oder einen Bußgeldbescheid: eine
neue Vorlage mit `layout = DOSSIER` und passenden Beschriftungen genügt.
Der Umbruch in Zeilen ist keine freie Anordnung, sondern folgt der Reihenfolge der Felder:
solange die Lichtbildzelle mitläuft, ist eine Zeile vier Spalten breit, danach fünf. Genau so
verhält sich das Blatt der Abteilung. `web/tests/aktenblatt.test.ts` schreibt das Raster fest.
### Der Klassifizierungsbalken ist Inhalt, kein Zugriff
Er zeigt die **Foundation-Stufe** (Vertraulich bis Thaumiel) aus `FoundationClearance`, ein
Feld der Vorlage. Was jemand sehen darf, entscheidet allein `Document.classification` gegen die
interne Stufe des Lesers. Das ist die Fortschreibung von „Zwei Freigaben im Kopf, aber nur eine
sperrt" auf das Blatt: die Stufe im Balken ist eine Aussage der Akte über sich selbst, keine
Zugriffsregel. Ohne gesetzte Stufe bleibt der Balken neutral dunkel, statt eine Einstufung zu
behaupten, die niemand vorgenommen hat.
### Das Lichtbild fehlt noch
`photo` ist als Feldtyp vorhanden und das Blatt hat seinen Platz dafür, aber hochladen lässt
sich noch nichts. Der Wert eines Lichtbildfeldes soll die Kennung eines **geprüften** Anhangs
sein, und die Prüfkette — Magic Bytes, ClamAV, Ablage außerhalb der Datenbank — ist Phase 5.
Ein Bild als Data-URL in einem Abschnittswert abzulegen, wie es die Vorlage der Abteilung tut,
verstößt gegen harte Regel 4 und wäre nachträglich schwer wieder herauszubekommen.
## Status als Etiketten, nicht als einzelner Wert
„Gekündigt" und „Verhaftet" schließen einander nicht aus, ein einzelnes Statusfeld zwingt aber
zur Wahl. `PersonnelFile.statusTags` ist deshalb eine Liste von Schlüsseln aus
`PersonnelStatusTag`, einer im Adminbereich pflegbaren Tabelle.
Zwei Eigenschaften sind nicht offensichtlich und deshalb festgeschrieben:
- **Unbekannte Schlüssel werden verworfen.** Ein manipuliertes Formular kann keinen erfundenen
Status setzen, sonst wäre die Liste im Adminbereich nur eine Empfehlung.
- **Die Reihenfolge kommt aus der Konfiguration**, nicht aus der Eingabe. Auf jeder Akte steht
dieselbe Abfolge, und zwei Akten mit denselben Etiketten sehen gleich aus.
Die **Dienstnummer ist entfallen**: es gibt sie in der Abteilung nicht. Sie steckte im
Suchvektor und in einem Trigram-Index, beide sind mit ihr verschwunden.
## Verknüpfen von beiden Seiten
Eine Person an einen Fall zu hängen ist ein Vorgang, aber zwei Blickrichtungen. Auf der
Fallakte sucht man die Person, auf der Personalakte den Fall, und beim Anlegen einer Fallakte
steht die betroffene Person gleich im Formular. Alle drei Wege laufen in `addParticipant`
zusammen — dieselbe Prüfung, derselbe Protokolleintrag.
Der Unterschied liegt in der Auswahl: auf der Fallakte eine Liste der sichtbaren Personen, auf
der Personalakte ein Eingabefeld für das Aktenzeichen. Eine Liste aller sichtbaren Fälle auf
einer Personalakte wäre am falschen Ort — sie beantwortet nicht die Frage, die man dort hat.