Florian WildeandClaude Opus 5
abacad1cb7
Eine veroeffentlichte Vorlagen-Version ist fuer immer unveraenderlich — daran haengt, dass ein archivierter Lauf in zehn Jahren noch genau die Schritte zeigt, mit denen er gestartet wurde. Die Regel steht deshalb zweimal: im Service, der die verstaendliche Meldung gibt, und in der Datenbank, die die Garantie gibt. Vier Trigger fangen Schreibzugriffe ab, die nicht durch den Service kommen — Migrationen, psql, der Seed und ab Phase 4 die Connectoren — und versperren den Rueckweg nach ENTWURF, der alles andere ausgehebelt haette. - Service: anlegen, Kopfdaten bearbeiten, Entwurf als tiefe Kopie der letzten veroeffentlichten Version, speichern, veroeffentlichen, verwerfen, duplizieren, archivieren - Hoechstens ein Entwurf je Vorlage, durchgesetzt vom partiellen Index; zwei gleichzeitige Klicks auf „Bearbeiten“ bekommen denselben Entwurf statt eines Fehlers - Optimistisches Sperren ueber geaendertAm: wer auf einem ueberholten Stand speichert, wird abgewiesen statt die Arbeit des anderen spurlos zu ersetzen - JSON-Export und -Import samt Format-Dokumentation; der Export ist nachsichtig, der Import streng - src/lib/validierung.ts als einzige Zod-Quelle mit deutschen Meldungen, per ESLint-Regel erzwungen Der unabhaengige Review fand drei Blocker, alle an der Mandantengrenze: der Suchfilter brachte ein zweites OR mit und ueberschrieb die Kundenbedingung, Historie und Aufbau einer Version filterten gar nicht. Zu queries/vorlagen.ts gab es keinen Test — jetzt gibt es tests/vorlagen-sicht.test.ts. 428 Tests gruen (vorher 336). Schliesst #009 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
5.3 KiB
5.3 KiB
#008 M3 – Betriebsmodus und Kunden
Status: erledigt Meilenstein: v0.1.0 Labels: phase-1, backend, frontend Geschätzt: 6 h Tatsächlich: 1 h 20 min
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 aufEinstellung.modus; alle Listen und Formulare fragen ihn abkundeErmitteln(eingabe): im ModusINTERNimmer die eigene Organisation, eine mitgeschicktekundeIdwird verworfen- Moduswechsel-Service:
INTERN → DIENSTLEISTUNGjederzeit, die eigene Organisation wird zum ersten Kunden (Name und Kürzel werden abgefragt), alle Daten bleiben daran hängen - Moduswechsel-Service:
DIENSTLEISTUNG → INTERNnur bei genau einem nicht archivierten Kunden, sonst Ablehnung mit Hinweis - Beide Richtungen mit Bestätigungsdialog und
Protokoll-Eintrag, nurADMIN - Kundenverwaltung im Modus
DIENSTLEISTUNG: anlegen,kuerzeleindeutig 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/LESERsehen nur ihre Kunden,ADMIN/REDAKTEURalles; ohne die Variable keine Einschränkung - Admin → Einstellungen: Modus mit Wechsel-Dialog, Name der eigenen Organisation, globale Namensregeln, Sperr-OU, Anzeige von
APP_URLfür die QR-Codes - Screenshots Einstellungen, Wechsel-Dialog, Kundenliste in
docs/screenshots/m3/
Akzeptanzkriterien
- Im Modus
INTERNerscheint die eigene Organisation in keiner Liste, keinem Filter und auf keinem Etikett. Eine Ausnahme, bewusst: auf der Einstellungsseite und im Wechsel-Dialog ist sie sichtbar — dort muss der Admin ihren Namen pflegen und vor dem Wechsel wissen, was aus ihr wird. - Test: eine Server Action mit mitgeschickter fremder
kundeIdschreibt im ModusINTERNtrotzdem auf die eigene Organisation - Test: Wechsel
INTERN → DIENSTLEISTUNGerhält alle Geräte, Mitarbeiter, Abteilungen und Läufe am ersten Kunden - Test: Wechsel
DIENSTLEISTUNG → INTERNwird 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:
LESERundTECHNIKERdürfen den Modus nicht wechseln - Der Modus liegt in der Datenbank und ist ohne Neustart umschaltbar
Beim Bauen aufgefallen
- Die Lesemodelle haben die Mandantensicht nicht angewandt.
kundenListe()gab jedem alle Kunden zurück,sichtbareKundenIdshatte in der Produktion keinen einzigen Aufrufer. Ein gebundener Techniker hätte Namen, Notizen und Bestandszahlen fremder Kunden gesehen. Die Funktionen verlangen jetzt den Benutzer und filtern selbst —CLAUDE.mdverlangt genau das, „damit kein Aufrufer sie vergessen kann“. - Mein Kommentar „Alles in einer Transaktion“ war falsch. Der Protokolleintrag stand hinter der Transaktion: schlug er fehl, war der Modus schon gewechselt und der Vorgang stand nirgends. Der Review hat es reproduziert. Jetzt läuft alles in einer Transaktion.
- Wettlauf beim Moduswechsel. Prüfung und Vollzug lagen auseinander: zwei gleichzeitige
Wechsel liefen beide durch, und ein zwischen Prüfung und Vollzug angelegter Kunde führte zu
Modus
INTERNbei zwei nicht archivierten Kunden — genau der Zustand, den die Regel verhindern soll. Einpg_advisory_xact_lockals erste Anweisung der Transaktion schließt das. - Die Sichtbarkeit steckte in einer zweiten Funktion, an die jeder künftige Aufrufer selbst
hätte denken müssen. Sie ist jetzt Teil von
kundeErmitteln— der einen Stelle, an der die Mandantenregel steht. Die Signatur ändert sich damit vor #009, das sie übernimmt. - ASCII-Faltung im falschen Text. „Kuerzel“, „gehoert“, „Grossbuchstaben“ standen in
Fehlermeldungen, die der Admin liest, während die Oberfläche sonst „Kürzel“ schreibt. Die Regel
in
CLAUDE.mdgilt für Bezeichner, nicht für Fließtext — steht jetzt ausdrücklich dort. - Die Erfolgsmeldung nach dem Wechsel war unsichtbar. Sie wurde im Formularzweig gerendert, den der gelungene Wechsel gerade durch die „Rückweg gesperrt“-Box ersetzt.
- Der Dialog versprach etwas, das der Code nicht durchsetzt („Das Verzeichnis bleibt der eigenen Organisation vorbehalten"). Eine Zusage auf Vorrat in einem Dialog, dessen ganzer Wert darin liegt, nur zu zeigen was wirklich passiert — Satz entfernt.
- Der Handy-Screenshot des Wechsel-Dialogs zeigte das Navigationsmenü, weil
getByRole("group").first()bei 390 px das erstedetailsder Seite trifft und das die Navigation ist. - Der Screenshot-Lauf im Modus Dienstleistung stürzte ab — und das war korrektes Verhalten: mit zwei nicht archivierten Kunden gibt es keinen Dialog zum Aufklappen. Daraus ist ein eigener Screenshot geworden, der die Ablehnung zeigt.