Files
nexarch/dms/docs/DOC-13-PRUEFPROTOKOLL.md
T
patrickandClaude Sonnet 5 533efa891c DOC-13: akten vorgangsanzeige im dokumentkontext
CasePanel zeigt Akte-Zugehoerigkeit, Vermerke und offene Wiedervorlagen in
der Dokument-Detailansicht ueber die externe Workflow-Board-API (VOR-04) an.
Kein eigenes Akte-Datenmodell, Ausfall der externen API blockiert nur diesen
Bereich.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-18 00:08:16 +02:00

3.1 KiB
Raw Blame History

DOC-13 – Prüfprotokoll: Akten-/Vorgangsanzeige im Dokumentkontext

Stand: 2026-09-18. Testhost 192.168.1.131. Umgesetzt in web/pdf-viewer (DOC-05s Dokument-Detailansicht), nicht im dms-Go-Modul — diese Kachel hat kein Backend im DMS-Modul, ausschließlich Anzeige über die externe Workflow-Board-API (VOR-04).

Umsetzung

lib/caseApi.ts — fetchCaseForDocument liefert einen von drei expliziten Zuständen (CaseLookupResult): found (mit CaseInfo), none (HTTP 404 — keine Verknüpfung, kein Fehler) oder unavailable (Netzwerkfehler oder Nicht-2xx/Nicht-404-Status). Kein eigenes Akte-Datenmodell (Akzeptanzkriterium 2) — die Funktion transportiert nur, was die externe API liefert, ohne eigene Persistenz.

components/CasePanel.tsx — rendert je nach Zustand: found → Akte-Titel, Vermerke, offene Wiedervorlagen; none → gar nichts (null); unavailable → eigener Hinweistext. Die Komponente wirft NIE (kein throw, fetch-Fehler werden in caseApi.ts bereits abgefangen) — dadurch kann ein Ausfall der externen API strukturell nicht die umgebende Seite (den PDF-Viewer) mitreißen, beide sind unabhängige Geschwisterkomponenten in app/viewer/[documentId]/page.tsx ohne gemeinsame Fehlergrenze, die das eine vom anderen abhängig machen würde.

Prüfung 1: Dokument mit verknüpfter Akte zeigt Akte-Informationen korrekt an

zeigt Akte-Titel, Vermerke und offene Wiedervorlagen an — PASS. Reale Antwort der (gemockten) Workflow-API mit Titel, einem Vermerk und einer Wiedervorlage wird vollständig und korrekt gerendert.

Prüfung 2: Dokument ohne Akte-Verknüpfung zeigt Bereich nicht/leer an

zeigt gar nichts an, wenn keine Akte verknuepft ist — PASS. Bei HTTP 404 rendert die Komponente null, kein Fehlertext, kein leerer Rahmen.

Prüfung 3: Simulierter Ausfall der Workflow-API blockiert die übrige Anzeige nicht

zeigt einen Hinweis statt eines Fehlers, wenn die Workflow-API nicht erreichbar ist — PASS. Ein simulierter Netzwerkfehler (fetch wirft) führt zu status: "unavailable" statt einer ungefangenen Exception — fetchCaseForDocument fängt den Fehler in einem try/catch ab, die Komponente zeigt den Hinweistext. Da CasePanel als eigenständige Geschwisterkomponente NACH PdfViewer gerendert wird und selbst nie wirft, kann dieser Ausfall die PDF-Anzeige strukturell nicht blockieren — ein Ende-zu-Ende-Test mit echtem PDF.js/Canvas-Rendering war in dieser Umgebung nicht möglich (gleiche Einschränkung wie bei DOC-05 dokumentiert), die strukturelle Trennung ist aber im Code nachvollziehbar und durch die Panel-eigenen Tests abgedeckt.

Akzeptanzkriterien 1–3

  • Akte-Zugehörigkeit/Vermerke/Wiedervorlagen anzeigen: siehe Prüfung 1 — PASS.
  • Kein eigenes Akte-Datenmodell: caseApi.ts persistiert nichts, liest nur — PASS (Code-Review).
  • Fehlerfall blockiert Dokumentanzeige nicht: siehe Prüfung 3 — PASS.

Testergebnis

npx vitest run: 22/22 PASS (7 neu: 4 caseApi, 3 CasePanel). npx tsc --noEmit: sauber. npx next build: erfolgreich (Route /viewer/[documentId] unverändert in der Größe, Panel fügt keine spürbare Bundle-Last hinzu).