Harlekin/AfiS-Aktensystem
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
Files
71c20f4b953b50185704cfbb5a9a66175e0d4793
AfiS-Aktensystem/TASKS.md
T
HarlekinandClaude Opus 5 71c20f4b95 Phase 7 abgeschlossen: Suche mit gestuftem Index, Facetten, Palette 
Der bisherige Suchvektor enthielt nur, was jeder sehen darf. Das war
leck-sicher und unbrauchbar zugleich: ab Stufe 1 fand die Suche nichts von
dem, was einen Fall ausmacht.

SearchIndex hält jetzt sechs Zeilen je Ziel, eine pro Freigabestufe. Die Zeile
zur Stufe N enthält alles, was ein Leser dieser Stufe sehen darf. Eine Suche
nimmt genau diese eine Zeile und kann deshalb nichts finden, was sie nicht
lesen darf — auch keinen höher eingestuften Eintrag in einer sichtbaren Akte.

Schwärzungen werden dabei stufenweise aufgelöst: strip_redactions_above
entfernt nur, was über der Stufe liegt. Sonst fände ein Leser der Stufe 4
einen Namen nicht, den er auf der Seite im Klartext sieht, und ein Leser der
Stufe 1 einen, den er dort nur als Balken sieht.

Die Suchbedingung ist nicht die Zugriffsprüfung: der Volltext liefert
Kandidaten, die Sichtbarkeit kommt aus visibleCaseWhere — derselben Funktion
wie in der Fallliste, und Treffer, Trefferzahl und Facettenzähler entstehen
gemeinsam in einer Abfrage. Eine in SQL nachgebaute Sichtbarkeitsregel wäre
die Sorte Duplikat, die auseinanderläuft.

Filter stehen in der Adresse. Damit ist jeder Zustand teilbar, der
Zurück-Knopf tut das Richtige, und eine gespeicherte Ansicht ist ein
Lesezeichen. Die mitgelieferten Ansichten stehen im Programm, weil sie von der
Gegenwart abhängen.

Strg+K öffnet die Kommandopalette. Im Grundgerüst steckt nur das
Tastaturereignis, die Palette selbst wird beim Öffnen geholt — das kostet die
anderen Seiten rund hundert Byte.

Offen geblieben: "Zuletzt geöffnet" als Ansicht. Dafür müsste jeder Aufruf
jeder Akte mitgeschrieben werden; das wäre eine Überwachungsfunktion, die
niemand bestellt hat. In TASKS vermerkt.

165 Tests im Web-Paket, 17 in der Datenbank, 7 im Worker, 34 e2e.
Grösste Route bei 119,7 kB gegen 120 erlaubte.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-02 21:23:01 +02:00

7.8 KiB
Raw Blame History

Bauplan

Phasen in Reihenfolge abarbeiten. Am Ende jeder Phase muss pnpm lint && pnpm typecheck && pnpm test durchlaufen und die Anwendung startbar sein.

Phase 0 — Gerüst

  • Next.js 15 mit TypeScript strict, Tailwind, pnpm-Workspace mit web/ und worker/
  • Prisma, Postgres im Compose, erste Migration
  • Design-Tokens aus docs/10-design-system.md als CSS-Variablen, IBM Plex selbst gehostet
  • lib/i18n/de.ts mit den ersten Texten, Konvention: keine deutschen Strings im JSX
  • Vitest und Playwright eingerichtet, ein rauchender Test je Ebene
  • .env.example gefüllt, compose.yaml aus docs/11-betrieb.md als Dockge-Stack lauffähig (zunächst nur web, db, pgbouncer)
  • Dockerfiles für web, worker und pdf, GitHub-Actions-Workflow schiebt die Images in die GitHub Container Registry
  • /api/health prüft Datenbank, Discord-Gateway und ClamAV, wird vom Healthcheck genutzt

Phase 1 — Anmeldung und Rechte

Das ist der schwierigste Teil. Wenn er steht, ist der Rest Formularbau.

  • Auth.js mit Discord-Provider, Scope identify, state und PKCE
  • Bot-Client mit Bot-Token, Guild-Mitgliedschaftsprüfung im Callback
  • Eigene Session in der Datenbank, Cookie-Einstellungen wie in docs/03-auth-und-rechte.md
  • worker/: discord.js am Gateway, Ereignisse plus Voll-Abgleich alle 5 Minuten
  • pg_notify bei Rollenänderung, Cache-Invalidierung in der Web-App
  • EffectivePermissions mit prozesslokalem Cache
  • BOOTSTRAP_ADMIN_IDS als Notfallzugang
  • Adminseite Rollen-Mapping: Tabelle der Discord-Rollen, Stufe per Auswahl, Rechte per Kästchen, Vorschau „Was sieht Stufe 2?"
  • Sessions werden bei Rollenverlust oder Serveraustritt beendet
  • Zwischenstand: eingeloggte Seite zeigt Name, Rollen, errechnete Stufe und Rechte
  • Negativtests aus docs/03-auth-und-rechte.md grün, soweit sie ohne Akten prüfbar sind. Die vier zu nachträglichen Änderungen an Verlaufseinträgen gehören zu Phase 2
  • entry.edit_own, entry.edit_any, entry.retract und case.edit_closed als Rechte angelegt, im Auslieferungszustand keiner Rolle zugeordnet

Phase 2 — Akten

  • Datenmodell für Case, CaseSection, CaseEntry, Beteiligte, Ausschlüsse
  • lib/access/ mit Where-Fragmenten, überall verwendet, nirgends Nachfilterung
  • Aktenzeichen-Vergabe kollisionsfrei über CaseCounter
  • Fallliste mit Filtern, cursorbasiert, loading.tsx mit Skelett
  • Aktenansicht: Kopfdaten sofort, Verlauf in eigener Suspense-Grenze (Chat: Phase 6)
  • Vermerk anlegen, optimistisch, mit clientseitiger UUIDv7
  • Statusübergänge mit Rechteprüfung und automatischem Systemeintrag
  • Schreibgrenzen nach docs/03-auth-und-rechte.md: keine Akte über der eigenen Stufe anlegen, Ändern nur mit Lesezugriff, Klassifizierung nachträglich änderbar bis zur eigenen Stufe. Kein Löschen von Akten, nur ARCHIVED und SEALED
  • Umklassifizierung erzeugt SYSTEM-Eintrag und AuditLog mit alter und neuer Stufe
  • Negativtests dazu: Stufe 2 kann keine Stufe-4-Akte anlegen, nicht ändern, nicht hochstufen, auch nicht über einen direkten Aufruf der Server Action
  • Audit-Log für alle schreibenden Aktionen und Lesezugriffe ab Stufe 3
  • Nachträgliche Änderungen an Verlaufseinträgen nach docs/05-akten-und-vorlagen.md: CaseEntryVersion, Karenzzeit, Pflichtbegründung, bearbeitet · vN mit Diff-Historie
  • Zurückziehen mit Grabstein und Pflichtbegründung, kein hartes Löschen
  • Postgres-Regeln gegen DELETE auf CaseEntry und CaseEntryVersion
  • Änderungsübersicht als Reiter an der Akte
  • Adminseite für AppSetting: Änderungsrichtlinie, Karenzzeit, Markierungsverhalten

Phase 3 — Vorlagen und Abschnitte

  • Entschieden: jede Akte trägt Kurzvermerke und Dokumente, die Fallakte zusätzlich Abschnitte. Siehe docs/13-entscheidungen.md

  • Feldtypen für Textkörper-Vorlagen ergänzen: fester Fließtext, Überschrift, Platzhalter, Unterschriftenzeile — der Sonderarbeitsvertrag ist kein Formular

  • CaseTemplate mit Feldtypen aus docs/05-akten-und-vorlagen.md

  • Aktenzeichen-Muster je Vorlage: Präfix und Stellenzahl, Nummernkreis je Präfix und Jahr

  • Feld „Foundation-Freigabe" als gewöhnliches Vorlagenfeld, ohne Wirkung auf den Zugriff

  • Vorlagen-Editor im Adminbereich, versioniert, mit Vorschau

  • Abschnitte rendern und bearbeiten, Autosave lokal alle 2 Sekunden

  • Versionierung mit Diff-Ansicht

  • Konflikterkennung über mitgesendete Version, 409 mit Vergleichsansicht

  • minClearance pro Feld, serverseitige Ersetzung durch Platzhalter

  • Schwärzungs-Auszeichnung im Freitext, Parser in lib/redaction.ts

  • Seed mit vier Startvorlagen

Phase 4 — Personalakten und Verknüpfungen

  • PersonnelFile, auch für Personen ohne Discord-Konto
  • Dokumente an der Personalakte aus Vorlagen, z. B. Sonderarbeitsvertrag
  • Beteiligte einer Akte mit Rolle
  • Rückverweise auf der Personalakte, durch die Sichtbarkeitsprüfung gefiltert
  • Verknüpfungen zwischen Akten
  • Test: Stufe-1-Nutzer sieht auf einer Personalakte keinen Hinweis auf Stufe-3-Fälle
  • Aktenblatt der Personalabteilung als Vorlage, Aufbau und Aussehen übernommen
  • Status als mehrere Etiketten, im Adminbereich pflegbar
  • AfiS-Mitglieder an einer Personalakte, mit ausnahmsweisem Zugang
  • Fall und Person von beiden Seiten verknüpfbar, auch beim Anlegen

Phase 5 — Dateien

  • Upload-Endpunkt mit Quarantäne, Limits, Kontingent
  • Typprüfung über Magic Bytes, Whitelist
  • ClamAV-Container angebunden
  • Neu-Kodierung mit sharp und qpdf, Vorschaubild und Blurhash
  • Auslieferung über /api/files/[id] mit Rechteprüfung und harten Headern
  • Upload-UI: lokale Vorschau, Fortschrittsbalken, Zustand „Wird geprüft"
  • SSE-Ereignis attachment.scanned aktualisiert die Anzeige
  • Lichtbild im Aktenblatt: Feldtyp photo füllen, Wert ist die Kennung eines geprüften Anhangs — das Feld und sein Platz stehen seit Phase 4

Phase 6 — Chat und Echtzeit

  • SSE-Endpunkt mit LISTEN/NOTIFY, Heartbeat, Reconnect mit Last-Event-ID
  • Aktenchat mit Antworten, Reaktionen, Bearbeiten, Zurückziehen
  • Optimistisches Senden mit Dedupe über Client-ID
  • Aktenzeichen-Erkennung mit serverseitig aufgelöster Vorschaukarte
  • Ungelesen-Markierung und Trennlinie
  • Freie Kanäle mit eigener Mindeststufe
  • „Als Vermerk übernehmen"
  • Discord-Benachrichtigungen über den Worker, ohne Inhalte
  • Benachrichtigungseinstellung je Nutzer: alles / meine Fälle / Erwähnungen / aus

Phase 7 — Suche

  • search_vector mit Trigger und Gewichtung, GIN-Index — je Freigabestufe einer
  • Suchseite mit Filtern, Debounce, AbortController, gedimmte alte Treffer
  • Sichtbarkeitsprüfung in derselben Abfrage, auch für Facettenzähler
  • Kommandopalette auf Strg+K
  • Gespeicherte Ansichten
  • „Zuletzt geöffnet" als Ansicht — braucht eine eigene Spur, siehe docs/13

Phase 8 — Export

  • Druckansicht /faelle/[caseNumber]/druck mit @media print
  • Playwright-Container erzeugt PDF, Ergebnis gecacht
  • Schwärzung und Wasserzeichen im Export
  • Freigabeverfahren ab Stufe 3
  • Einzeldokument als PDF, ohne Verlauf, Aussehen aus der Vorlage
  • ZIP-Sammelexport und JSON-Vollexport für Admins

Phase 9 — Schliff

  • Dashboard: meine Fälle, Fristen, ungelesene Chats, letzte Aktivität
  • Beobachtungsliste
  • Helles Thema
  • Mobile Ansicht durchgehen, besonders Akte und Chat
  • Web-Vitals-Erfassung und Anzeige im Adminbereich
  • Bundle-Analyse, Budget aus docs/09-performance-und-ux.md einhalten
  • Backup-Wiederherstellung einmal von Hand testen
Reference in New Issue View Git Blame Copy Permalink