Files
Laufzettel/docs/issues/008-betriebsmodus-kunden.md
T
Florian WildeandClaude Opus 5 49ce06f206
Prüfung / pruefung (push) Canceled after 0s
Prüfung / e2e (push) Canceled after 0s
feat: Projektgerüst, gehärteten Betriebsstand und Prozess aufsetzen
Legt die Grundlage, auf der alle weiteren Meilensteine nur noch Fachlichkeit
ergänzen: Next 16 mit App Router und TypeScript strict, Tailwind 4, Prisma 7,
Vitest 5, Playwright, ESLint, Prettier und die Hooks für Lint und Commits.

Zwei Dinge sind bewusst so gebaut und durch Tests festgehalten:

Die Datenbank ist im Betriebsstand von außen nicht erreichbar. Sie hat kein
ports:-Mapping und hängt allein im Netz "intern", das ohne Gateway läuft; nur
"web" kommt zusätzlich nach draußen. tests/betriebsstand.test.ts schlägt an,
falls ein Port-Mapping zurückkehrt. Geprüft, nicht behauptet: docker compose up
startet den Stack, 5432 ist vom Host aus zu, aus "web" offen.

pnpm pruefe:doku hält Dokumentation und Code zusammen — Version im Changelog,
Issue-Dateien gegen ihre Übersicht, keine Verweise auf fehlende Dateien, keine
fehlenden Bilder. Das Skript wurde gegen vier eingebaute Fehler gegengeprüft.

Drei Versions-Obergrenzen sind nötig und in CLAUDE.md begründet: eslint bleibt
auf 9.x, weil eslint-plugin-react keinen Nachfolger für eslint 10 hat und das
Regelwerk sonst beim Laden abbricht; typescript bleibt auf 6.0.x, weil
typescript-eslint TypeScript 7 noch nicht unterstützt; prisma ist exakt auf
7.10.0 gepinnt, weil sein latest-Tag auf einen 8.0-RC zeigt, der von
@prisma/client aber nicht.

Auth.js entfällt entgegen der ursprünglichen Vorgabe: v5 steht dauerhaft auf
Beta, das Projekt ist im Wartungsmodus und sein Prisma-Adapter deckt Prisma 7
nicht ab. Stattdessen openid-client und jose, wie in ProxLedger.

Dieser erste Commit geht direkt auf main, weil es noch keinen Branch gibt, von
dem abzuzweigen wäre. Ab #006 läuft jedes Issue über einen eigenen Branch.

Closes #5

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-24 23:33:49 +02:00

2.6 KiB
Raw Blame History

#008 M3 – Betriebsmodus und Kunden

Status: offen Meilenstein: v0.1.0 Labels: phase-1, backend, frontend Geschätzt: 6 h Tatsächlich: –

Ziel

Ein Codepfad für beide Betriebsmodi. Im Modus INTERN ist die Kunden-Ebene vollständig unsichtbar, ohne dass irgendwo Daten fehlen — dadurch ist der Wechsel später eine Datenänderung und keine Migration.

Aufgaben

  • betriebsmodus() als zentraler, gecachter Zugriff auf Einstellung.modus; alle Listen und Formulare fragen ihn ab
  • kundeErmitteln(eingabe): im Modus INTERN immer die eigene Organisation, eine mitgeschickte kundeId wird verworfen
  • Moduswechsel-Service: INTERN → DIENSTLEISTUNG jederzeit, die eigene Organisation wird zum ersten Kunden (Name und Kürzel werden abgefragt), alle Daten bleiben daran hängen
  • Moduswechsel-Service: DIENSTLEISTUNG → INTERN nur bei genau einem nicht archivierten Kunden, sonst Ablehnung mit Hinweis
  • Beide Richtungen mit Bestätigungsdialog und Protokoll-Eintrag, nur ADMIN
  • Kundenverwaltung im Modus DIENSTLEISTUNG: anlegen, kuerzel eindeutig 2–6 Zeichen, archivieren statt löschen, Notizen
  • Navigation und Beschriftungen je Modus: INTERN = Übersicht, Läufe, Vorlagen, Mitarbeiter & Geräte, Archiv, Admin; DIENSTLEISTUNG = Übersicht, Läufe, Vorlagen, Kunden, Archiv, Admin und „Mitarbeiter" heißt „Personen"
  • Optionale Kundenbindung über OIDC_CUSTOMER_GROUP_PREFIX (z. B. lz-kunde-MUS): TECHNIKER/LESER sehen nur ihre Kunden, ADMIN/REDAKTEUR alles; ohne die Variable keine Einschränkung
  • Admin → Einstellungen: Modus mit Wechsel-Dialog, Name der eigenen Organisation, globale Namensregeln, Sperr-OU, Anzeige von APP_URL für die QR-Codes
  • Screenshots Einstellungen, Wechsel-Dialog, Kundenliste in docs/screenshots/m3/

Akzeptanzkriterien

  • Im Modus INTERN erscheint die eigene Organisation in keiner Liste, keinem Filter, keinem Formular und auf keinem Etikett
  • Test: eine Server Action mit mitgeschickter fremder kundeId schreibt im Modus INTERN trotzdem auf die eigene Organisation
  • Test: Wechsel INTERN → DIENSTLEISTUNG erhält alle Geräte, Mitarbeiter, Abteilungen und Läufe am ersten Kunden
  • Test: Wechsel DIENSTLEISTUNG → INTERN wird bei zwei nicht archivierten Kunden mit Hinweis abgelehnt, bei einem gelingt er
  • Test: ein Wechsel schreibt einen Protokoll-Eintrag mit Vorher- und Nachher-Zustand
  • Test: LESER und TECHNIKER dürfen den Modus nicht wechseln
  • Der Modus liegt in der Datenbank und ist ohne Neustart umschaltbar