test(admin): WINDOWS #14 und #15 abgenommen — Ledger ohne offene Punkte

Abnahme im Browser auf alpha gegen das echte AD, nachdem der User die Container neu erstellt hatte. Voraussetzungen gemessen statt angenommen: Container tatsaechlich getauscht, Migration 20260909120000_user_email_optional angewandt, User.email is_nullable = YES. Die Migration lief beim API-Start automatisch mit. #15 — der Sync meldet jetzt "Erstellt: 4" statt vier stiller Fehlschlaege. Die kollidierenden Konten sind angelegt und aktiv, ohne Adresse; mbuntz behaelt als erster Anspruch seine. Der Bericht zeigt zwei verstaendliche deutsche Abschnitte statt Prisma-Text und englischer Meldungen. Die beiden Folgestellen vertragen Konten ohne Adresse: die Benutzerliste zeigt einen Gedankenstrich, und die Suche im Mitglieder-Dialog liefert die Konten sauber statt abzustuerzen — das war der eigentliche Fallstrick. #14 — die Matrix-Suche laesst die nicht getroffene Achse stehen. Alle vier Faelle geprueft: Modulname behaelt die Gruppenspalten, Gruppenname behaelt die Modulzeile, der AD-Name findet dieselbe Spalte wie der interne Name (Regression #6c intakt), und eine Suche ohne Treffer erklaert sich in einem verstaendlichen Satz. Am Active Directory wurde nichts veraendert; es wurde nur gelesen. Der fuer die Regressionsprobe gesetzte interne Name ist wieder geleert. Ledger danach: 0 offen, 15 behoben, 1 zurueckgestellt (#12 — es gibt intern kein Postfach fuer Ausschreibungs-Alarme). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
2026-09-09 08:26:15 +02:00
parent efcf11c988
commit ceb94e424b
5 changed files with 118 additions and 16 deletions
@@ -0,0 +1,102 @@
+# Abnahme im Browser — 2026-09-09
+
+Durchgefuehrt auf **alpha** (https://alpha.tessera.ctl.de) gegen das echte
+Active Directory, nachdem der User die Container neu erstellt hatte.
+Schliesst WINDOWS.md **#14** und **#15**.
+
+## Voraussetzungen gemessen, nicht angenommen
+
+| Pruefung | Ergebnis |
+|----------|----------|
+| Container wirklich getauscht | alle drei "Up About a minute" |
+| Migration angekommen | `User.email` → `is_nullable = YES` |
+| Migration in der Historie | `20260909120000_user_email_optional` |
+
+Die Migration lief beim Start der API automatisch mit — der Container fuehrt
+`prisma migrate deploy` vor dem Start aus (`apps/api/Dockerfile`). Es war kein
+zusaetzlicher Schritt noetig.
+
+## WINDOWS #15 — Sync-Bericht und Kontenanlage
+
+Ausgangslage vor dem Lauf: 409 Benutzer, **keiner** ohne Adresse, die vier
+kollidierenden Konten **nicht vorhanden**.
+
+Nach `Jetzt synchronisieren`:
+
+```
+Erstellt: 4, aktualisiert: 408, deaktiviert: 0
+```
+
+Darunter zwei neue, verstaendliche Abschnitte — kein Prisma-Text mehr, kein
+Englisch:
+
+> Diese Konten wurden ohne E-Mail-Adresse angelegt, weil die Adresse bereits zu
+> einem anderen Konto gehoert. Anmeldung und Zugriff funktionieren, nur
+> Benachrichtigungen per E-Mail erreichen sie nicht.
+>
+> - uvertrieb_ro — Adresse bereits vergeben an ein anderes Konto: mbuntz@ctl.de
+> - uvertrieb_rw — …
+> - uvertrieb_ro_ss — …
+> - usoftware_rw — …
+
+> Ohne Anmeldenamen uebersprungen — normal fuer Kontakte und Verteiler im
+> Verzeichnis.
+>
+> - CN=backupprtg@albweb.de,CN=Users,DC=ctl,DC=local
+> - CN=Rolf Staudenmayer,OU=CTL_Ressourcen,DC=ctl,DC=local
+> - …
+
+**Datenbankstand danach** — die Produktentscheidung haelt exakt:
+
+| Konto | Adresse |
+|-------|---------|
+| mbuntz | mbuntz@ctl.de (erster Anspruch behaelt sie) |
+| uvertrieb_ro | (keine) |
+| uvertrieb_rw | (keine) |
+| uvertrieb_ro_ss | (keine) |
+| usoftware_rw | (keine) |
+
+Alle vier aktiv. Vorher wurden sie bei **jedem** Lauf still verworfen.
+
+Beleg: `uat-2026-09-09/w15-sync-bericht-deutsch.png`
+
+### Folgestellen, die an Konten ohne Adresse haetten scheitern koennen
+
+| Stelle | Ergebnis |
+|--------|----------|
+| Benutzerliste (`/admin/users`) | zeigt die Konten, Adressspalte `–`, kein Fehler |
+| Suche im Mitglieder-Dialog | Suche nach `uvertrieb` liefert die drei Konten sauber — **kein Absturz** |
+
+Die zweite Stelle war der eigentliche Fallstrick: `GroupMembersModal` rief
+`.toLowerCase()` ungeschuetzt auf der Adresse auf. Ohne den Schutz waere die
+Mitgliedersuche mit dem ersten adresslosen Konto kaputtgegangen.
+
+## WINDOWS #14 — Suche in der Freigaben-Matrix
+
+Aufbau: zwei Gruppenspalten (`Alle Benutzer`, `Vertrieb Team` — interner Name
+fuer die AD-Gruppe `Claude_VT`), eine Modulzeile (`Ausschreibungs-Radar`).
+
+| Sucheingabe | Erwartung | Ergebnis |
+|-------------|-----------|----------|
+| `Ausschreibung` (Modulname) | Modulzeile **und alle** Gruppenspalten bleiben | bestanden — beide Spalten samt Kaestchen da |
+| `Vertrieb` (interner Gruppenname) | Spalte **und** Modulzeile bleiben | bestanden — Kaestchen anklickbar |
+| `Claude_VT` (AD-Name) | dieselbe Spalte, Modulzeile bleibt | bestanden — **Regression #6c intakt** |
+| `gibtesnicht123` | verstaendliche Leermeldung | „Kein Treffer fuer „gibtesnicht123" — weder bei den Modulen noch bei den Gruppen." |
+
+Vor der Reparatur leerte jede Suche die jeweils andere Achse, sodass nie ein
+Kaestchen uebrig blieb.
+
+Beleg: `uat-2026-09-09/w14-matrix-gruppensuche-behaelt-modulzeile.png`
+
+## Zustand nach der Abnahme
+
+- Der interne Name `Vertrieb Team` wurde nur fuer die Regressionsprobe gesetzt
+  und danach wieder geleert.
+- Die vier neu angelegten Konten bleiben bestehen — sie sind das Ergebnis des
+  Tests, kein Testartefakt, und gehoeren fachlich ins Verzeichnis.
+- Am Active Directory wurde **nichts** veraendert; es wurde nur gelesen.
+
+## Ledger
+
+WINDOWS.md danach: **0 offen**, 15 behoben, 1 zurueckgestellt (#12 — es gibt
+intern kein Postfach fuer Ausschreibungs-Alarme).