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:
co-authored by
Claude Opus 5
parent
d65cc95eb2
commit
68ad0debd3
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user