Betriebsmodus, Kundenverwaltung und Einstellungen #22

2026-09-25T05:02:51Z

florian.wilde commented

2026-09-25 05:02:51 +00:00

Zwei Betriebsmodi, ein Codepfad. Jede kundenbezogene Zeile trägt ohnehin schon eine Kunden-Zuordnung; im Modus INTERN ist das die eine Organisation, die nirgends erscheint. Der Wechsel ist deshalb eine Datenänderung, keine Migration — dieselbe Zeile bleibt, nichts hängt um.

src/server/mandant.ts ist die eine Stelle, an der die Mandantenregel steht.

Drei Blocker aus dem Review, alle behoben

1. Die Lesemodelle wandten die Mandantensicht nicht an. kundenListe() gab jedem alle Kunden zurück, und sichtbareKundenIds hatte 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.

2. Mein Kommentar „Alles in einer Transaktion" war falsch. Der Protokolleintrag stand dahinter: schlug er fehl, war der Modus gewechselt und der Vorgang stand nirgends. Reproduziert und geschlossen.

3. Wettlauf beim Moduswechsel. Prüfung und Vollzug lagen auseinander — zwei gleichzeitige Wechsel liefen beide durch, und ein zwischendurch angelegter Kunde führte zu Modus INTERN bei zwei nicht archivierten Kunden. Jetzt pg_advisory_xact_lock als erste Anweisung der Transaktion.

Sechs weitere Befunde

ASCII-Faltung in Texten, die Menschen lesen („Kuerzel", „gehoert") — die Regel gilt für Bezeichner, nicht für Fließtext; steht jetzt so in CLAUDE.md
Die Erfolgsmeldung nach dem Wechsel war unsichtbar, weil der gelungene Wechsel den Formularzweig ersetzt
Der Dialog versprach „Das Verzeichnis bleibt der eigenen Organisation vorbehalten" — nichts im Code setzt das durch, Satz entfernt
kundeArchivierenAktion ohne Fehlerbehandlung: der Versuch, die eigene Organisation zu archivieren, endete in einer 500er-Seite statt in der Begründung
Der Handy-Screenshot des Wechsel-Dialogs zeigte das Navigationsmenü
Huelle hatte einen stillen Standard für den Modus — ein vergessener Parameter hätte die Kundenebene ausgeblendet statt aufzufallen

Geprüft

Der Wechsel wurde durch die Oberfläche gefahren, nicht nur im Service: anmelden → Dialog aufklappen → bestätigen → Navigation steht auf Kunden, /kunden erreichbar.

lint, typecheck, build, pruefe:doku grün. 336 Tests (vorher 274), darunter die Unteilbarkeit des Wechsels (Rücknahme bei fehlgeschlagenem Protokoll), zwei gleichzeitige Wechsel und die eingeschränkte Sicht eines gebundenen Technikers.

Screenshots unter docs/screenshots/m3/, inklusive der Ablehnung des Rückwegs bei zwei Kunden.

Closes #8

Zwei Betriebsmodi, **ein** Codepfad. Jede kundenbezogene Zeile trägt ohnehin schon eine Kunden-Zuordnung; im Modus `INTERN` ist das die eine Organisation, die nirgends erscheint. Der Wechsel ist deshalb eine Datenänderung, keine Migration — dieselbe Zeile bleibt, nichts hängt um. `src/server/mandant.ts` ist die eine Stelle, an der die Mandantenregel steht. ## Drei Blocker aus dem Review, alle behoben **1. Die Lesemodelle wandten die Mandantensicht nicht an.** `kundenListe()` gab jedem alle Kunden zurück, und `sichtbareKundenIds` hatte 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. **2. Mein Kommentar „Alles in einer Transaktion" war falsch.** Der Protokolleintrag stand dahinter: schlug er fehl, war der Modus gewechselt und der Vorgang stand nirgends. Reproduziert und geschlossen. **3. Wettlauf beim Moduswechsel.** Prüfung und Vollzug lagen auseinander — zwei gleichzeitige Wechsel liefen beide durch, und ein zwischendurch angelegter Kunde führte zu Modus `INTERN` bei zwei nicht archivierten Kunden. Jetzt `pg_advisory_xact_lock` als erste Anweisung der Transaktion. ## Sechs weitere Befunde - ASCII-Faltung in Texten, die Menschen lesen („Kuerzel", „gehoert") — die Regel gilt für **Bezeichner**, nicht für Fließtext; steht jetzt so in `CLAUDE.md` - Die Erfolgsmeldung nach dem Wechsel war unsichtbar, weil der gelungene Wechsel den Formularzweig ersetzt - Der Dialog versprach „Das Verzeichnis bleibt der eigenen Organisation vorbehalten" — nichts im Code setzt das durch, Satz entfernt - `kundeArchivierenAktion` ohne Fehlerbehandlung: der Versuch, die eigene Organisation zu archivieren, endete in einer 500er-Seite statt in der Begründung - Der Handy-Screenshot des Wechsel-Dialogs zeigte das Navigationsmenü - `Huelle` hatte einen stillen Standard für den Modus — ein vergessener Parameter hätte die Kundenebene ausgeblendet statt aufzufallen ## Geprüft Der Wechsel wurde **durch die Oberfläche** gefahren, nicht nur im Service: anmelden → Dialog aufklappen → bestätigen → Navigation steht auf Kunden, `/kunden` erreichbar. `lint`, `typecheck`, `build`, `pruefe:doku` grün. **336 Tests** (vorher 274), darunter die Unteilbarkeit des Wechsels (Rücknahme bei fehlgeschlagenem Protokoll), zwei gleichzeitige Wechsel und die eingeschränkte Sicht eines gebundenen Technikers. Screenshots unter `docs/screenshots/m3/`, inklusive der Ablehnung des Rückwegs bei zwei Kunden. Closes #8

florian.wilde added 1 commit 2026-09-25 05:02:51 +00:00

feat(mandant): Betriebsmodus, Kundenverwaltung und Einstellungen

Prüfung / pruefung (push) Canceled after 0s

Details

Prüfung / pruefung (pull_request) Canceled after 0s

Details

Prüfung / e2e (push) Canceled after 0s

Details

Prüfung / e2e (pull_request) Canceled after 0s

Details

8e67591912

Laufzettel läuft jetzt in zwei Betriebsmodi, aber nicht in zwei Codepfaden. Jede
kundenbezogene Zeile trägt ohnehin schon eine Kunden-Zuordnung; im Modus INTERN
ist das die eine Organisation, die in der Oberfläche nirgends erscheint. Der
Wechsel ist deshalb eine Datenänderung und keine Migration — dieselbe Zeile
bleibt, nichts hängt um.

src/server/mandant.ts ist die eine Stelle, an der die Mandantenregel steht:
kundeErmitteln verwirft im Modus INTERN eine mitgeschickte kundeId, verlangt im
Modus DIENSTLEISTUNG eine Wahl und prüft, ob der Benutzer den Kunden überhaupt
sehen darf. Die Sichtbarkeit steckte zunächst in einer zweiten Funktion daneben,
an die jeder künftige Aufrufer selbst hätte denken müssen; da #009 diese Signatur
übernimmt, ist sie jetzt eingebaut.

Der unabhängige Review fand drei Blocker, alle behoben.

Die Lesemodelle wandten die Mandantensicht nicht an. kundenListe gab jedem alle
Kunden zurück, und sichtbareKundenIds hatte 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, wie CLAUDE.md es verlangt.

Mein Kommentar "Alles in einer Transaktion" war falsch: der Protokolleintrag
stand dahinter. Schlug er fehl, war der Modus gewechselt und der Vorgang stand
nirgends. Und Prüfung und Vollzug lagen auseinander, sodass zwei gleichzeitige
Wechsel beide durchliefen und ein zwischendurch angelegter Kunde zu Modus INTERN
bei zwei Kunden führte. Beides reproduziert, beides geschlossen: alles in einer
Transaktion, mit pg_advisory_xact_lock als erster Anweisung.

Dazu sechs kleinere Befunde: ASCII-Faltung in Texten, die Menschen lesen (die
Regel gilt für Bezeichner, nicht für Fließtext — steht jetzt so in CLAUDE.md);
eine Erfolgsmeldung, die nach dem Wechsel unsichtbar blieb; eine Zusage im
Dialog, die der Code nicht durchsetzt; fehlende Fehlerbehandlung beim
Archivieren; ein Handy-Screenshot, der das Navigationsmenü statt des Dialogs
zeigte.

Der Wechsel wurde nicht nur im Service geprüft, sondern per Playwright durch die
Oberfläche gefahren: anmelden, Dialog aufklappen, bestätigen, und danach steht
die Navigation auf Kunden.

336 Tests.

Closes #8

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

florian.wilde merged commit ecc3c579df into main

2026-09-25 05:03:12 +00:00

florian.wilde deleted branch feat/8-betriebsmodus

2026-09-25 05:03:12 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: florian.wilde/Laufzettel#22