schalli
ceb94e424b
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
3.9 KiB
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 Teamwurde 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).