Abteilungen als Ebene über der Personalakte
Punkt 3 der Wünsche. Die Abteilung stand als Freitext in der Personalakte. Damit liess sich nichts fragen: „SHD", „Shd" und „Sicherheitsdienst" waren drei Abteilungen. Sie ist jetzt ein eigenes Modell, im Adminbereich verwaltbar, und die drei vorhandenen Freitexte sind in der Migration zu Abteilungen geworden. **Eine Fallakte trägt keine Abteilung.** Sie gehört zu einer, wenn eine beteiligte Person ihr angehört — abgeleitet über CaseParticipant und die Personalakte. Eine eingetragene Zuordnung wäre nach zwei Wochen falsch: Leute wechseln, Beteiligte kommen dazu, und niemand pflegt das nach. Dasselbe gilt für die Dokumente: ein Dokument unmittelbar an der Abteilung wäre halb verdrahtet, weil die Vorlagen über TemplateUse nur Fall- und Personalakte kennen. Die Abteilungsseite zeigt Mitglieder, abgeleitete Fälle und Dokumente, Vermerke, Chat und ein Kreisdiagramm der Fallarten; die Übersicht eines über alle Abteilungen. Das Diagramm ist serverseitig gerendertes SVG — eine Bibliothek wäre das Teuerste auf der Seite gewesen. Die Segmente sind Abstufungen von --steel und nicht die Stufenfarben: ein Tortenstück in Oxidrot würde als „streng geheim" gelesen. Die Zusammenfassung ist die gefährliche Stelle. Eine Abteilungsseite fasst zusammen, was einzeln längst geschützt ist, und eine Zusammenfassung, die nicht filtert, verrät mehr als jede Einzelansicht. Deshalb läuft hier jede Liste und jede Zahl durch dieselben Fragmente wie überall; ein Test prüft, dass die Summe der Diagrammanteile mit der Länge der Liste übereinstimmt. Wo jemand Personalakten gar nicht sehen darf, steht null und keine Null. Vermerke erben Regel 2 unverändert: kein DELETE, Version bei jeder Änderung, Grabstein bei jeder Zurücknahme, als Regel und Trigger in der Datenbank. Ohne Korrekturkette, Anhänge und Karenzzeit — was Beweiswert hat, gehört in eine Fallakte. Nebenbei: das Zugriffsprotokoll hängt jetzt am dafür vorgesehenen Recht audit.read statt an admin. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 5
parent
970be0e320
commit
1d637bc85e
@@ -1145,3 +1145,54 @@ diese Akten herausgibt, nicht in der Seite.
|
||||
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. Der Reiter fehlt dann
|
||||
ganz.
|
||||
|
||||
### Die Abteilung ist eine Ebene, kein weiteres Feld
|
||||
|
||||
Die Abteilung stand als **Freitext** in der Personalakte. Damit liess sich nichts fragen: jede
|
||||
Schreibweise war eine eigene Abteilung, und „SHD", „Shd" und „Sicherheitsdienst" waren drei.
|
||||
Sie ist jetzt ein eigenes Modell, im Adminbereich verwaltbar, und die Akte zeigt darauf.
|
||||
|
||||
Die wichtigste Festlegung dabei: **eine Fallakte trägt keine Abteilung.** Sie gehört zu einer,
|
||||
wenn eine beteiligte Person ihr angehört — abgeleitet über `CaseParticipant` und die
|
||||
Personalakte. Eine eingetragene Zuordnung wäre nach zwei Wochen falsch: Leute wechseln die
|
||||
Abteilung, Beteiligte kommen dazu, und niemand pflegt so etwas nach. Abgeleitet stimmt sie
|
||||
immer, und sie kostet eine Verknüpfung mehr in der Abfrage.
|
||||
|
||||
Dasselbe gilt für die Dokumente einer Abteilung. Ein Dokument unmittelbar an der Abteilung
|
||||
wäre eine halbe Sache — die Vorlagen kennen über `TemplateUse` nur Fall- und Personalakte, und
|
||||
ein Besitzer, für den es keine Vorlage gibt, ist ein Feld, das nichts füllen kann. Die Liste
|
||||
zeigt deshalb, was an den Personalakten der Mitglieder und an den Fällen der Abteilung hängt.
|
||||
|
||||
**Die Zusammenfassung ist die gefährliche Stelle.** Eine Abteilungsseite fasst zusammen, was
|
||||
einzeln längst geschützt ist, und eine Zusammenfassung, die nicht filtert, verrät mehr als
|
||||
jede Einzelansicht. Deshalb läuft hier jede Liste **und jede Zahl** durch dieselben Fragmente
|
||||
wie überall: die Mitgliederzahl durch `visiblePersonnelWhere`, die Fälle und die Werte im
|
||||
Diagramm durch `visibleCaseWhere`. Ein Test prüft ausdrücklich, dass die Summe der
|
||||
Diagrammanteile mit der Länge der Liste übereinstimmt.
|
||||
|
||||
Die Abteilung selbst steht auf Stufe 0: dass es den Sicherheitsdienst gibt, ist kein
|
||||
Geheimnis, und eine Abteilung, die niemand findet, kann auch niemand jemandem zuordnen. Die
|
||||
Mindeststufe gibt es trotzdem, und sie gilt dann für das, was an der Abteilung hängt — ihre
|
||||
Vermerke und ihren Chat.
|
||||
|
||||
### Abteilungsvermerke sind Verlauf, nur schmaler
|
||||
|
||||
Für die Vermerke gilt harte Regel 2 unverändert: kein `DELETE`, jede Änderung erzeugt eine
|
||||
Version, jede Zurücknahme lässt einen Grabstein stehen. Die Regeln stehen als Regel und
|
||||
Trigger in der Datenbank, nicht nur in der Anwendung.
|
||||
|
||||
Was fehlt, sind die Teile, die nur eine Ermittlung braucht: Korrekturkette, Anhänge,
|
||||
Karenzzeit. Ein Abteilungsvermerk ist ein laufendes Protokoll — was Beweiswert hat, gehört in
|
||||
eine Fallakte, und die gibt es ja.
|
||||
|
||||
### Das Kreisdiagramm ist SVG vom Server
|
||||
|
||||
Eine Diagrammbibliothek wäre das Teuerste auf der Seite gewesen. Die Rechnung ist ein Dutzend
|
||||
Zeilen Trigonometrie, und serverseitig gerendert kostet das Diagramm **kein Byte
|
||||
JavaScript**.
|
||||
|
||||
Die Segmente sind Abstufungen von `--steel` und **nicht** die Klassifizierungsfarben. Die
|
||||
sechs Stufenfarben sind das einzige Buntsystem der Anwendung und bedeuten dort etwas
|
||||
Bestimmtes; ein Tortenstück in Oxidrot würde als „streng geheim" gelesen. Daneben steht die
|
||||
Aufschlüsselung als Liste mit Zahlen und Prozenten: Farbe allein darf keine Angabe tragen,
|
||||
also ist das Diagramm der Schmuck und die Liste die Auskunft.
|
||||
|
||||
Reference in New Issue
Block a user