Suche zeigt alle Arten, nur Arbeitsrollen öffnen die Akte

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.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Harlekin
2026-09-03 19:16:17 +02:00
co-authored by Claude Opus 5
parent 2fb120dd77
commit 970be0e320
15 changed files with 361 additions and 49 deletions
+15 -4
View File
@@ -99,10 +99,21 @@ Für Abschnitte und Verlaufseinträge gilt dasselbe eine Ebene tiefer: `minClear
nicht über die eigene Stufe heben, und eine Erhöhung wirkt rückwirkend auf alle Versionen
(siehe `docs/05-akten-und-vorlagen.md`).
**Ausnahmsweiser Zugang** läuft über `CaseParticipant`: wer als Beteiligter eingetragen ist,
liest die Akte unabhängig von seiner Stufe. Das ist der vorgesehene Weg, jemanden gezielt
hinzuzuziehen, ohne ihm allgemein eine höhere Stufe zu geben. Beteiligte hinzuzufügen setzt
`case.edit` voraus und wird protokolliert.
**Ausnahmsweiser Zugang** läuft über `CaseParticipant`, aber **nur für Arbeitsrollen**. Die
Beteiligtenliste beantwortet zwei ganz verschiedene Fragen:
| Rolle | Bedeutung | Öffnet die Akte |
|---|---|---|
| `LEAD`, `INVESTIGATOR`, `OBSERVER` | bearbeitet den Fall | ja, unabhängig von der Stufe |
| `WITNESS`, `SUBJECT`, `SUSPECT`, `ACCOMPLICE` | ist Gegenstand des Falls | nein |
Die erste Gruppe ist der vorgesehene Weg, jemanden gezielt hinzuzuziehen, ohne ihm allgemein
eine höhere Stufe zu geben. Die zweite ist eine Angabe über den Fall und keine Berechtigung an
ihm — sonst läse ein Betroffener oder Beschuldigter mit Discord-Konto die Ermittlung gegen sich
selbst mit. Die Liste steht in `lib/cases/terms.ts` als `WORKING_ROLES`; wer sie erweitert,
entscheidet damit über Zugriff.
Beteiligte hinzuzufügen setzt `case.edit` voraus und wird protokolliert.
Die Gegenprobe bleibt der `CaseExclusion`: er schlägt jede Stufe und auch den Admin.