# 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).