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
103 lines
3.9 KiB
Markdown
103 lines
3.9 KiB
Markdown
# 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).
|