docs(16): close Phase 16 UAT with A1 accepted as an open assumption
The user has no write access to the company AD, so tests 1, 3, 4 and 8 cannot be run there, and building a throwaway domain controller for them was judged disproportionate now that the one substantive defect at this spot is found and fixed (UAT test 2 -> quick task 260811-f9i). Recorded rather than hidden: A1 (objectGUID survives a rename) now rests on Microsoft's documentation, not on our own measurement. The Tessera-side rename and delete logic stays covered by unit tests against fixtures. If a rename ever fails to propagate in production, 16-VERIFICATION.md names that as the starting point. Phase 16 marked complete in STATE.md. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -1,29 +1,42 @@
|
||||
---
|
||||
status: testing
|
||||
status: complete
|
||||
phase: 16-ad-gruppen-synchronisation
|
||||
source: [16-VERIFICATION.md]
|
||||
started: 2026-08-06T15:15:00Z
|
||||
updated: 2026-08-11T08:40:00Z
|
||||
updated: 2026-08-11T09:20:00Z
|
||||
---
|
||||
|
||||
## Current Test
|
||||
|
||||
number: 1
|
||||
name: AD-Umbenennung behaelt dieselbe Kennung (Annahme A1)
|
||||
expected: |
|
||||
Eine im Active Directory umbenannte Gruppe behaelt ihre unveraenderliche
|
||||
objectGUID. Nur dann kann der Sync eine Umbenennung von einem Verschwinden
|
||||
unterscheiden — die Grundlage von Erfolgskriterium 3.
|
||||
awaiting: user response
|
||||
blocked_on: |
|
||||
Schreibzugriff im AD (balios.ctl.local) — die importierte Gruppe CN=Claude_VT
|
||||
muss dort umbenannt werden. Danach Test 2, 3, 4 und der offene Teil von Test 7.
|
||||
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: [pending]
|
||||
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.
|
||||
@@ -49,11 +62,13 @@ notes: |
|
||||
|
||||
### 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: [pending]
|
||||
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: [pending]
|
||||
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.
|
||||
@@ -106,16 +121,17 @@ notes: |
|
||||
|
||||
### 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: [pending]
|
||||
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: 2
|
||||
passed: 3
|
||||
partial: 1
|
||||
issues: 1
|
||||
pending: 4
|
||||
skipped: 0
|
||||
pending: 0
|
||||
skipped: 4
|
||||
blocked: 0
|
||||
issues_detail: |
|
||||
Test 2 hat einen kritischen Fehler aufgedeckt (Existenzpruefung fand nie etwas,
|
||||
|
||||
@@ -1,8 +1,10 @@
|
||||
---
|
||||
phase: 16-ad-gruppen-synchronisation
|
||||
verified: 2026-08-06T15:07:32Z
|
||||
status: human_needed
|
||||
score: 5/5 must-haves (code-level) — 2 davon PRESENT_BEHAVIOR_UNVERIFIED wegen ungeprüfter Live-AD-Annahmen
|
||||
status: accepted_with_open_assumptions
|
||||
accepted_at: 2026-08-11
|
||||
accepted_by: user
|
||||
score: 5/5 must-haves (code-level) — 2 davon PRESENT_BEHAVIOR_UNVERIFIED wegen ungeprüfter Live-AD-Annahmen; A2 am 2026-08-11 geprüft, widerlegt und der gefundene Fehler behoben (260811-f9i)
|
||||
behavior_unverified: 2
|
||||
overrides_applied: 0
|
||||
human_verification:
|
||||
@@ -37,6 +39,40 @@ behavior_unverified_items:
|
||||
|
||||
# Phase 16: AD-Gruppen-Synchronisation Verification Report
|
||||
|
||||
## Nachtrag 2026-08-11 — Abschluss der offenen Punkte
|
||||
|
||||
Die sechs `human_verification`-Punkte unten sind am 2026-08-11 abgearbeitet
|
||||
worden, mit einem substanziellen Fund und einer bewussten Entscheidung:
|
||||
|
||||
**Geprüft und bestanden (Browser, alpha.tessera.ctl.de, Playwright):** die
|
||||
Import-Sektion, der Gruppen-Dialog in allen drei Zuständen, der Fehlerpfad des
|
||||
Sync-Berichts und die Spaltensuche der Freigabe-Matrix unter internem wie
|
||||
AD-Namen. Details in `16-UAT.md`, Tests 5 bis 7.
|
||||
|
||||
**Geprüft und WIDERLEGT — Annahme A2:** der binäre `(objectGUID=...)`-Filter
|
||||
wurde als escapter String gebaut und fand am echten AD nie etwas, auch nicht für
|
||||
existierende Objekte. Beide Suchen der Existenzprüfung teilten sich diesen
|
||||
Filter, also hätte der erste echte Sync-Lauf jede AD-gebundene Gruppe samt
|
||||
Mitgliedschaften und Modulfreigaben gelöscht. Behoben in Quick-Task 260811-f9i
|
||||
(Commit `d2019dc`): `EqualityFilter` über den rohen Buffer, gegengeprüft am
|
||||
echten Verzeichnis, plus zwei Regressionstests. Damit ist SC-4 nicht mehr
|
||||
`PRESENT_BEHAVIOR_UNVERIFIED`, sondern in seiner kritischen Mechanik belegt.
|
||||
|
||||
**Bewusst nicht geprüft — Annahme A1 und die End-to-End-Läufe (Tests 1, 3, 4, 8):**
|
||||
der User hat keine Schreibrechte im AD, und der Ersatzweg über einen eigenen
|
||||
Wegwerf-Domänencontroller wurde als unverhältnismäßig verworfen, nachdem der eine
|
||||
substanzielle Fehler bereits gefunden war. A1 (objectGUID übersteht eine
|
||||
Umbenennung) stützt sich damit auf die Microsoft-Dokumentation, nicht auf eine
|
||||
eigene Messung. Die Tessera-seitige Umbenennungs- und Löschlogik ist durch
|
||||
Unit-Tests gegen Testdaten belegt. Fällt im Betrieb auf, dass eine Umbenennung
|
||||
nicht nachzieht, ist das der Ansatzpunkt — siehe `16-UAT.md`, Abschnitt
|
||||
"Entscheidung 2026-08-11".
|
||||
|
||||
Ebenfalls offen und bewusst so belassen: die Zahlenzeilen eines ERFOLGREICHEN
|
||||
Sync-Laufs (Test 7, zweiter Teil). Die lassen sich ohne AD-Rechte nachholen,
|
||||
sobald einmal ein Sync mit eng gesetztem Filter auf alpha läuft.
|
||||
|
||||
|
||||
**Phase Goal:** Ausgewählte AD-Gruppen werden als Tessera-Gruppen angelegt und dauerhaft nachgeführt, statt jede Gruppe von Hand anzulegen und zu binden. Der Admin wählt aus der AD-Gruppenliste aus, welche Gruppen übernommen werden; der bestehende Benutzer-Sync hält Bestand, Namen und Mitgliedschaften danach aktuell.
|
||||
**Verified:** 2026-08-06T15:07:32Z
|
||||
**Status:** human_needed
|
||||
|
||||
Reference in New Issue
Block a user