Files

T

schalli 2c4558164e test(15,16): alte Browser-Gegenproben nachgeholt — ein Defekt gefunden

Die sechs seit Anfang August offenen Browser-Durchlaeufe aus Phase 15 und 16
(WINDOWS.md #1-#6) waren liegengeblieben, weil in den damaligen Sitzungen kein
Browser-Tool verfuegbar war. Der Stack lief fuer die Phase-17-Gegenproben ohnehin,
also wurden alle nachgeholt, die ohne echtes Active Directory pruefbar sind.

Geschlossen:

#1 (15-06) Gruppenverwaltung: anlegen, umbenennen, Standardmarkierung exklusiv
setzen und zuruecknehmen, Mitglied hinzufuegen und entfernen, Loeschdialog nennt
beide Zahlen konkret. Bei gestoppter API meldet der Loeschvorgang deutschen
Klartext und laesst die Gruppe stehen. Die AD-Bindung ist an dieser Stelle
gegenstandslos geworden — Phase 16 hat sie in den LDAP-Bereich verlagert.

#2 (15-07) Freigaben-Matrix: setzen und entziehen, Aktivierungsdialog auf beiden
Wegen (Sofort-Freigabe legt den Grant an, "Spaeter konfigurieren" nicht),
Direkt-Grant neben Gruppen-Grant mit sichtbarer Gruppenspalte, langer Gruppenname
bleibt in seinen Massen. Bei gestoppter API springt die Checkbox zurueck und die
Datenbank bleibt unveraendert — kein optimistischer Zustand ueberlebt.

#5 (16-04) Gruppen-Dialog in allen drei Zustaenden, inklusive importierter Gruppe
mit gesperrtem AD-Namen und freiem internen Namen; die Liste zeigt danach den
internen Namen und traegt den AD-Namen im Tooltip. Die AD-Bindung wurde dafuer in
der Datenbank gesetzt, nicht importiert — im Bericht ausdruecklich vermerkt.

#3 (15-08) wurde durchgefuehrt und hat einen Defekt aufgedeckt:

WINDOWS #10 (neu, offen): PERM-04 greift nicht auf den modul-eigenen Routen. Der
Zugriffs-Guard sitzt allein in modules/[category]/[moduleSlug]/page.tsx. Die vier
fest verdrahteten Modulrouten (tender-radar, dkv-fleet, cert-manager, domaincheck)
samt Unterseiten laufen daran vorbei. Ein USER ohne Freigabe bekommt unter
/modules/procurement/tender-radar korrekt die 403-Seite, unter /modules/tender-radar,
/modules/tender-radar/my-sources und /modules/dkv-fleet dagegen die volle Seite mit
bedienbaren Knoepfen. Keine Datenpreisgabe — die API antwortet durchgehend 403 —
aber der Nutzer sieht Bedienelemente, die er nicht benutzen darf, und rohe
englische Techniktexte statt einer verstaendlichen Meldung. Sidebar, Marketplace
und API verhalten sich dagegen korrekt.

Offen bleiben #4 und #6: beide messen den Sync-Vorgang selbst und brauchen ein
erreichbares Active Directory.

Berichte mit Screenshots unter 15-UAT-2026-09-07.md und 16-UAT-2026-09-07.md.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5jtbGzC5Sf9npJ3JCjKhq

2026-09-07 10:08:04 +02:00

3.6 KiB

Raw Blame History

phase, kind, date, windows_addressed, windows_still_open, result

phase

kind

date

windows_addressed

windows_still_open

result

16-ad-gruppen-synchronisation

uat-nachtrag

2026-09-07

1 bestanden, 2 weiterhin offen (echtes AD erforderlich)

Phase 16 — Browser-Gegenprobe, nachgeholt am 2026-09-07

Von den drei offenen Punkten aus Phase 16 (WINDOWS.md #4, #5, #6) ließ sich einer ohne erreichbares Active Directory nachholen. Die beiden anderen nicht — sie messen den Sync selbst, nicht die Oberfläche.

Aufbau: frisch gebaute Images aus main (79015dd), lokaler Docker-Stack, leere Datenbank, echter Chrome über Playwright.

WINDOWS #5 — die drei Zustände des Gruppen-Dialogs (16-04) — BESTANDEN

Zustand	Beobachtung
Anlegen	Kein Feld für eine AD-Bindung, sondern der Hinweis „AD-Gruppen werden im LDAP-Bereich importiert, nicht hier angelegt." mit Link „Zum LDAP-Bereich"
Lokale Gruppe umbenennen	Namensfeld frei editierbar, kein AD-Hinweis, kein Feld für einen internen Namen. Umbenennung von „Vertrieb" auf „Vertrieb Innendienst" zieht sofort in die Liste durch
Importierte Gruppe bearbeiten	Namensfeld gesperrt mit dem vollen AD-Namen und der Erklärung „Von der AD-Gruppe übernommen. Wird beim nächsten Sync automatisch aktualisiert."; darunter die Zeile „AD-DN: CN=Zentraler Einkauf,OU=Abteilungen,DC=firma,DC=local"; darunter das freie Feld „Interner Name" mit der Erklärung „Wird von der Synchronisation nie verändert. Bleibt das Feld leer, zeigt die Oberfläche stattdessen den AD-Namen."

Namensanzeige mit Tooltip nach dem Speichern: Nach dem Setzen des internen Namens auf „Einkauf Nordwest" zeigt die Liste diesen an, und das title-Attribut der Namenszelle trägt den vollen AD-Namen „Abteilung Zentraler Einkauf und Vergabemanagement Region Nordwest Standort Braunschweig". Die Spalte AD-Bindung steht auf „AD-gebunden". Programmatisch aus dem gerenderten DOM ausgelesen, nicht aus dem Quelltext geschlossen.

Beleg: uat-2026-09-07/w5-gruppenliste-interner-name.png

Wie die importierte Gruppe entstanden ist — ausdrücklich vermerkt: In dieser Sandbox gibt es kein erreichbares Active Directory. Die AD-Bindung wurde deshalb direkt in der Datenbank gesetzt (ldapDn, ldapObjectGuid, internalName), nicht durch einen echten Import. Das ist für diesen Prüfpunkt zulässig, weil der zu prüfende Dialogzustand ausschließlich vom Datensatz abhängt und nicht davon, wie er entstanden ist. Für die Prüfpunkte #4 und #6 gilt das ausdrücklich nicht — die messen den Sync-Vorgang selbst.

WINDOWS #4 und #6 — weiterhin offen

Beide brauchen ein echtes Active Directory und können hier nicht ersetzt werden:

#4 (16-03): Die Annahmen A1 (objectGUID übersteht eine Umbenennung im AD) und A2 (byteweise Hex-Filter-Syntax) sind gegen kein echtes Verzeichnis geprüft. Ein negatives Ergebnis bei A1 oder A2 wäre ein Stopp-Grund für die Löschsemantik (D-05). Der verwandte kritische Fehler in der Löscherkennung wurde am 2026-08-11 mit d2019dc behoben und dabei read-only am echten AD gemessen — A1 selbst bleibt davon unberührt offen.
#6 (16-05): Einen Sync auslösen und die drei Zahlenzeilen sowie die Amber-Zeile bei verschobener Standardmarkierung prüfen. Ohne Verzeichnis gibt es keinen Lauf, dessen Zahlen man ablesen könnte. Die Spaltensuche der Freigaben-Matrix unter beiden Namen ist dagegen inzwischen indirekt belegt: die Matrix zeigt AD-gebundene Gruppen unter ihrem internen Namen an (siehe #5).

Beide Punkte bleiben im Ledger open und sind vor dem Produktivbetrieb der AD-Synchronisation an einem echten Verzeichnis nachzuholen.

3.6 KiB Raw Blame History

Phase 16 — Browser-Gegenprobe, nachgeholt am 2026-09-07

WINDOWS #5 — die drei Zustände des Gruppen-Dialogs (16-04) — BESTANDEN

WINDOWS #4 und #6 — weiterhin offen

3.6 KiB

Raw Blame History