Files
tessera-ctl/.planning/phases/16-ad-gruppen-synchronisation/16-UAT.md
T
schalli 208e449bc9
Tessera CI/CD / Lint & Type Check (push) Successful in 46s
Tessera CI/CD / Tests (push) Successful in 50s
Tessera CI/CD / Build & Publish Images (push) Successful in 7s
docs(16): UAT test 7 passed after the full sync run
The user released the full run once it was clear nothing there is productive
yet. All three report lines appeared (401 created / 9 memberships added / 0
groups adopted, renamed or deleted), and the amber default-marker line stayed
absent as it should when nothing was deleted.

The run doubles as the end-to-end proof for the 260811-f9i fix: the imported
group survived the sweep with its memberships filled, where the old filter
would have deleted it in exactly this run.

Roadmap marks Phase 16 complete; Phase 15 keeps its 7/8 with the reason named.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-11 13:37:47 +02:00

11 KiB

status, phase, source, started, updated
status phase source started updated
complete 16-ad-gruppen-synchronisation
16-VERIFICATION.md
2026-08-06T15:15:00Z 2026-08-11T09:20:00Z

Current Test

none — UAT am 2026-08-11 abgeschlossen.

Entscheidung 2026-08-11

Tests 1, 3, 4 und 8 werden NICHT durchgefuehrt. Entscheidung des Users, mit Begruendung akzeptiert:

  • Der User hat keine Schreibrechte im AD (balios.ctl.local) — Gruppen dort anlegen, umbenennen oder loeschen ist ihm nicht moeglich.
  • Der Aufwand fuer den Ersatzweg (eigener Wegwerf-Domaenencontroller im Container) steht nicht im Verhaeltnis zum Rest-Erkenntnisgewinn, nachdem der eine substanzielle Fehler an dieser Stelle bereits gefunden und behoben ist (siehe Test 2 und Quick-Task 260811-f9i).
  • Wortlaut der Entscheidung: "Mach den Test einfach nicht. Wenn mir irgendwann mal auffaellt, dass das nicht funktioniert, aendern wir das."

Damit gilt fuer SC-3 und SC-4: die Tessera-seitige Logik ist durch Unit-Tests gegen Testdaten belegt, die Annahme ueber das Verhalten des Verzeichnisses (A1: objectGUID uebersteht eine Umbenennung) stuetzt sich auf die Microsoft- Dokumentation und wurde nicht am lebenden Verzeichnis nachgestellt. Faellt beim ersten echten Einsatz auf, dass eine Umbenennung nicht nachzieht, ist das der Ansatzpunkt.

Tests

1. AD-Umbenennung behaelt dieselbe Kennung (Annahme A1)

expected: Gegen ein echtes AD (ViCoTest, balios.ctl.local), read-only — eine importierte Gruppe suchen, ihre objectGUID notieren, die Gruppe im AD umbenennen, erneut suchen, GUID vergleichen. Die GUID muss identisch bleiben. result: skipped reason: Kein Schreibzugriff im AD; Ersatzweg als unverhaeltnismaessig verworfen (siehe Entscheidung 2026-08-11). A1 bleibt eine dokumentierte, nicht nachgestellte Annahme.

2. Binaerer Existenz-Filter liefert korrekte Treffer (Annahme A2)

expected: Gegen dasselbe AD, read-only — eine Suche mit dem byteweise escapten (objectGUID=...)-Binaerfilter absetzen. Eine weiterhin existierende Gruppe muss einen Treffer liefern, eine tatsaechlich geloeschte keinen. Ein negatives Ergebnis bei Test 1 ODER 2 ist ein Stopp-Grund fuer die Loeschsemantik aus D-05. result: failed -> fixed tested: 2026-08-11 read-only gegen balios.ctl.local, Sonde CN=Domain Admins,CN=Users,DC=ctl,DC=local notes: | A2 war FALSCH — nicht am Domain Controller, sondern an der Umsetzung. Der als String interpolierte Filter (objectGUID=\1e\4b...) lieferte 0 Treffer fuer ein Objekt, dessen GUID unmittelbar zuvor aus demselben Verzeichnis gelesen wurde. Die Grossbuchstaben-Variante ebenfalls 0. Ein ldapts EqualityFilter mit dem rohen 16-Byte-Buffer lieferte genau einen Treffer mit korrekter DN; die Kontrollsuche (cn=Domain Admins) lieferte ebenfalls einen Treffer.

Auswirkung im damaligen Stand: beide Suchen der Existenzpruefung — die schmale ueber die Base-DNs und die weite WR-03-Absicherung — teilten sich diesen Filter. Der erste echte Sync-Lauf haette daher JEDE AD-gebundene Gruppe als geloescht eingestuft und samt GroupMembership und ModuleGrant entfernt.

Behoben in Quick-Task 260811-f9i (Commit d2019dc): EqualityFilter ueber den rohen Buffer, escapeLdapFilterBuffer() entfernt, zwei Regressionstests, die den String-Filter ausschliessen. Der negative Fall (unbekannte GUID liefert nichts) war in beiden Varianten erfuellt.

3. Umbenennung im AD zieht in Tessera nach (SC-3, end-to-end)

expected: Gruppe im echten AD umbenennen, Sync laufen lassen. Group.name und Group.ldapDn ziehen nach, der Zaehler groupsRenamed steigt, es findet KEINE Loesch-und-Neuanlage statt, Mitgliedschaften und Modulfreigaben bleiben erhalten, ein gesetzter interner Name bleibt unveraendert. result: skipped reason: Siehe Entscheidung 2026-08-11. Die Tessera-seitige Umbenennungslogik ist durch Unit-Tests gegen Testdaten belegt (ldap.service.spec.ts), der Durchlauf am lebenden Verzeichnis entfaellt.

4. Loeschung im AD entfernt die Gruppe — Verschiebung nicht (SC-4, end-to-end)

expected: Gruppe im echten AD loeschen, Sync laufen lassen — die Tessera-Gruppe wird samt GroupMembership und ModuleGrant kaskadierend entfernt, und war sie die Standardgruppe, wandert die Markierung weiter. Zusaetzlich: eine lediglich in eine andere OU VERSCHOBENE Gruppe darf NICHT geloescht werden, sondern erzeugt eine Fehlerzeile (WR-03-Fix). result: skipped reason: Siehe Entscheidung 2026-08-11. Die Filtermechanik, an der dieser Test wirklich hing, ist ueber Test 2 am echten AD geklaert und der dort gefundene Fehler behoben (260811-f9i).

5. Browser: Import-Sektion auf /admin/ldap

expected: Sektion "AD-Gruppen importieren" — Discovery liefert nur Gruppen (keine OUs), Checkbox-Auswahl funktioniert, Import-Button traegt die Auswahlzahl und ist bei leerer Auswahl deaktiviert, bereits importierte Gruppen tragen das Badge und sind deaktiviert, Ergebnisblock erscheint, Fehlerzustaende sind sichtbar (nicht still). Deckt die als verification: backstop markierten UI-Zustaende ab: leer, ladend, Fehler, Overflow, lange Namen. result: passed tested: 2026-08-11 auf alpha.tessera.ctl.de gegen das echte AD (balios.ctl.local), Playwright notes: | Discovery lieferte 236 Eintraege, davon 0 mit OU=-Prefix — der Typfilter greift. Leerer Zustand vor der Suche korrekt. Import-Button "Ausgewaehlte importieren (0)" deaktiviert, nach Auswahl von CN=Claude_VT auf "(1)" und aktiv. Nach dem Import: Ergebnisblock "1 importiert, 0 uebersprungen" plus Hinweis auf die spaetere Mitgliedschaftsbefuellung, Zeile traegt Badge "Bereits importiert" und die Checkbox ist deaktiviert. In der DB steht ldapObjectGuid=d11c8cea7d455f49a4919daee0039aa3. Fehlerzustand ueber eine erzwungene 500-Antwort auf GET /ldap/groups geprueft: "AD-Gruppen konnten nicht abgerufen werden..." erscheint sichtbar, kein stiller Abbruch.

6. Browser: Gruppen-Dialog in allen drei Zustaenden

expected: /admin/groups — Anlegen zeigt den Hinweis mit Link zum LDAP-Bereich und keine AD-Auswahl mehr; eine lokale Gruppe laesst sich umbenennen; bei einer importierten Gruppe ist das Namensfeld sichtbar gesperrt mit Herkunftshinweis, die AD-DN-Zeile ist sichtbar, der interne Name speichert korrekt, und ein Fehler beim Speichern bleibt im Dialog sichtbar mit erhaltenen Eingaben. result: passed tested: 2026-08-11 auf alpha.tessera.ctl.de, Playwright notes: | Zustand Anlegen: nur Namensfeld, Hinweis "AD-Gruppen werden im LDAP-Bereich importiert, nicht hier angelegt." mit Link "Zum LDAP-Bereich" auf /admin/ldap, keine AD-Auswahl mehr vorhanden. Zustand lokale Gruppe: "Alle Benutzer" liess sich auf "Alle Benutzer Test" umbenennen und wieder zuruecksetzen; kein AD-DN, kein internes Namensfeld. Zustand importierte Gruppe: Namensfeld disabled mit Wert "Claude_VT", Hinweis "Von der AD-Gruppe uebernommen...", Zeile "AD-DN: CN=Claude_VT,OU=Verteiler, OU=CTL_Gruppen,DC=ctl,DC=local", interner Name "Claude Verteiler" gespeichert und in der Liste als Anzeigename uebernommen. Fehlerfall (WR-02): lokale Gruppe auf den bereits vergebenen Namen "Claude_VT" umbenannt — 409 erzeugt "Der Name ist bereits vergeben." im Dialog, Dialog bleibt offen, Eingabe bleibt erhalten.

7. Browser: Sync-Bericht und Freigabe-Matrix

expected: /admin/ldap — Sync ausloesen, alle drei Zahlenzeilen erscheinen auch bei Werten von 0; die gelbe Zeile zur verschobenen Standardmarkierung erscheint nur, wenn das tatsaechlich passiert ist; ein fehlgeschlagener Sync zeigt eine Fehlermeldung statt eines Null-Berichts. /admin/modules/grants — die Spaltensuche findet eine Gruppe sowohl unter ihrem internen als auch unter ihrem AD-Namen. result: passed tested: 2026-08-11 auf alpha.tessera.ctl.de, Playwright (Fehlerpfad und Matrix vormittags, erfolgreicher Lauf um 13:32) notes: | Bestanden: Fehlerfall des Berichts (D-21) — bei erzwungener 500-Antwort auf POST /ldap/sync erscheint "Die Synchronisation konnte nicht ausgefuehrt werden.", KEIN Null-Bericht mit Zahlenzeilen. Bestanden: Freigabe-Matrix — Spaltenkopf zeigt den internen Namen "Claude Verteiler"; die Spaltensuche findet die Gruppe sowohl unter "Claude Verteiler" als auch unter dem AD-Namen "Claude_VT". Nachgeholt am 2026-08-11 um 13:32 — der User hat den vollen Lauf freigegeben ("Noch laeuft das nicht produktiv"). Alle drei Zahlenzeilen erschienen: "Erstellt: 401, aktualisiert: 3, deaktiviert: 0" / "Gruppenmitgliedschaften: 9 hinzugefuegt, 0 entfernt" / "AD-Gruppen: 0 neu uebernommen, 0 umbenannt, 0 geloescht". Die Amber-Zeile zur verschobenen Standardmarkierung blieb korrekt aus, weil nichts geloescht wurde.

Nebenbefund von Wert: der Lauf ist zugleich der End-to-End-Beleg fuer den Fix aus 260811-f9i. Die zuvor importierte Gruppe CN=Claude_VT hat den Sync ueberlebt (0 geloescht, 9 Mitgliedschaften befuellt) — mit dem alten Filter waere sie in genau diesem Lauf samt Mitgliedschaften entfernt worden.

Fehlerzeilen des Laufs sind Datenlagen im AD, kein Sync-Fehler: 7 Eintraege ohne sAMAccountName (Kontakte/Ressourcen) und 4 E-Mail-Kollisionen aus OU=CTL_PWS_Gruppen. Der Lauf hat sie ausgewiesen statt abzubrechen.

8. Nebenlaeufigkeit und Layoutstress (backstop-Aussagen)

expected: Kein beobachtbares Fehlverhalten bei parallelen Anfragen, bei Reihenfolgeunabhaengigkeit, bei Sortier-Divergenz zwischen AD-Name und internem Namen, und bei sehr langen Texten in Listen und Dialogen. Diese Aussagen sind bewusst als verification: backstop deklariert — kein Code-Beleg reicht zu ihrer Bestaetigung. result: skipped reason: Siehe Entscheidung 2026-08-11. Backstop-Aussagen, im Browser-Durchlauf vom 2026-08-11 ist nichts davon negativ aufgefallen — das ist aber Beobachtung, kein Nachweis.

Summary

total: 8 passed: 4 partial: 0 issues: 1 pending: 0 skipped: 4 blocked: 0 issues_detail: | Test 2 hat einen kritischen Fehler aufgedeckt (Existenzpruefung fand nie etwas, Loeschung aller gebundenen Gruppen beim ersten Sync). Behoben in Quick-Task 260811-f9i, Commit d2019dc. Der Test selbst gilt damit als bestanden fuer die Filtermechanik; der Sync-Lauf als Ganzes bleibt ueber Test 3/4 offen.

Gaps

Offen nach dem Browser-Durchlauf vom 2026-08-11:

  • Tests 1 und 2 (Annahmen A1/A2 gegen ein echtes AD) — brauchen Schreibzugriff im AD (Gruppe umbenennen, Gruppe loeschen). Nicht durch die Oberflaeche abbildbar.
  • Tests 3 und 4 (SC-3 Umbenennung, SC-4 Loeschung end-to-end) — haengen an 1 und 2 und brauchen zusaetzlich einen echten Sync-Lauf.
  • Test 7, Teil "Zahlenzeilen eines erfolgreichen Laufs" — auf Wunsch uebersprungen, siehe Notiz dort. Vorschlag: vorher den Import-Filter auf CN=Claude_VT setzen, dann bleibt der Lauf klein.
  • Test 8 (Nebenlaeufigkeit, Layoutstress) — weiterhin offen, per Definition backstop.

Zustand auf alpha nach dem Durchlauf: die AD-Gruppe CN=Claude_VT ist als Tessera-Gruppe importiert und traegt den internen Namen "Claude Verteiler". Sie ist bewusst stehen geblieben, weil Tests 3 und 4 genau diese Gruppe brauchen.