tessera-ctl/.planning/phases/15-modul-berechtigungen-gruppen-user-grants/15-UAT-2026-09-07.md

phase, kind, date, windows_addressed, windows_opened, windows_closed_later, result

phase	kind	date	windows_addressed	windows_opened	windows_closed_later	result
15-modul-berechtigungen-gruppen-user-grants	uat-nachtrag	2026-09-07	1 2 3	10	10	2 von 3 bestanden, 1 mit Befund — Befund am selben Tag behoben und gegengeprueft

Phase 15 — Browser-Gegenproben, nachgeholt am 2026-09-07

Die drei Browser-Durchläufe aus den Plänen 15-06, 15-07 und 15-08 waren seit dem 2026-08-04 offen, weil in den damaligen Ausführungssitzungen kein Browser-Tool verfügbar war (WINDOWS.md #1, #2, #3). Sie wurden jetzt nachgeholt.

Aufbau: frisch gebaute Images aus main (79015dd), lokaler Docker-Stack, leere Datenbank, echter Chrome über Playwright. Testdaten über die Oberfläche angelegt: Modul im Marktplatz aktiviert, zwei USER-Konten (nutzer1, nutzer2) im selben Mandanten, Gruppen und Freigaben über die Administrationsseiten.

WINDOWS #1 — Gruppenverwaltung (15-06) — BESTANDEN

Schritt aus dem Plan	Beobachtung
Gruppe anlegen	„Vertrieb" erscheint in der Liste, Spalte AD-Bindung „Manuell", 0 Mitglieder
Umbenennen	Auf „Vertrieb Innendienst" geändert, Liste zieht nach
Standardmarkierung setzen	Markierung wandert exklusiv: „Alle Benutzer" wechselt auf „Als Standardgruppe festlegen", die neue Gruppe trägt „Standardgruppe"
Standardmarkierung wieder abschalten	Durch Setzen bei „Alle Benutzer" zurückgewandert
Mitglied hinzufügen	„Nutzer Eins" erscheint mit Herkunfts-Badge „Manuell"; seine Auswahl-Checkbox ist danach gesperrt, ein Doppel-Hinzufügen also nicht möglich
Mitglied entfernen	Liste wieder leer, Checkbox wieder frei
Löschdialog mit gefüllter Gruppe	„Diese Gruppe hat 1 Mitglieder und 1 Modul-Freigaben." — beide Zahlen konkret genannt (D-17)
Löschvorgang bei gestoppter API	Sichtbare deutsche Klartextmeldung „Gruppe konnte nicht gelöscht werden. Bitte erneut versuchen.", Löschen-Knopf danach gesperrt, Gruppe bleibt in der Liste

Nicht mehr prüfbar, weil bewusst geändert: Der Plan verlangte „an eine AD-Gruppe binden und Bindung lösen" sowie die AD-Suche bei gestoppter API. Beides gibt es an dieser Stelle nicht mehr. Phase 16 hat den Anlegen-Dialog umgebaut: er trägt jetzt den Hinweis „AD-Gruppen werden im LDAP-Bereich importiert, nicht hier angelegt." samt Link dorthin. Die Prüfpunkte sind damit gegenstandslos, nicht übersprungen.

Kleiner Sprachbefund: Der Löschdialog schrieb „1 Mitglieder" statt „1 Mitglied" — Mehrzahl auch bei Eins. Behoben am 2026-09-07 (Quick 260907-ipz): beide Zahlen laufen jetzt über eine Ein-/Mehrzahl-Regel, in Deutsch und Englisch. Im Browser an zwei Gruppen gegengeprüft, darunter der gemischte Fall „2 Mitglieder und 1 Modul-Freigabe".

WINDOWS #2 — Freigaben-Matrix und Direkt-Grants (15-07) — BESTANDEN

Schritt aus dem Plan	Beobachtung
Freigabe in der Matrix setzen	Checkbox für „Vertrieb Innendienst" gesetzt, Beschriftung wechselt von „freigeben" auf „entziehen"
Freigabe wieder entziehen und Wirkung gegenprüfen	Entzug für „Alle Benutzer" führte dazu, dass nutzer2 den Zugriff sofort verlor — belegt über alle vier Ebenen unter #3
Aktivierungsdialog, Weg „Sofort freigeben"	Cert Manager aktiviert; Grant an die Standardgruppe „Alle Benutzer" entstand (D-10)
Aktivierungsdialog, Weg „Später konfigurieren"	DKV-Rechnung aktiviert; kein Grant entstanden (0 Freigaben in der Datenbank)
Direkt-Grant neben Gruppen-Grant	Im Benutzer-Detail von nutzer1 zeigt die Spalte „Über Gruppe(n)" beide freigebenden Gruppen an, während die Spalte „Direkt" unabhängig davon gesetzt werden kann
Matrix-Zelle bei gestoppter API	Fehlermeldung erscheint und die Checkbox springt in ihren alten Zustand zurück; die Datenbank zeigt danach unveränderte Freigaben — kein optimistischer Zustand überlebt den fehlgeschlagenen Request. Beleg: uat-2026-09-07/w2-matrix-rollback-api-aus.png
Direkt-Kästchen bei gestoppter API	Fehlermeldung im Dialog, Grant unverändert in der Datenbank
Sehr langer Gruppenname	Kopfzeile schneidet mit Ellipse ab („Abteilung Zentraler Einkauf und Vergabemanagement…"), Spaltenbreiten bleiben, die Seite scrollt nicht horizontal. Beleg: uat-2026-09-07/w2-matrix-lange-namen.png

Befunde ohne Blockerwirkung:

• Die Fehlermeldung bei gestoppter API lautet in Matrix und Benutzer-Detail roh „500: Internal Server Error". Der Löschdialog der Gruppenseite kann es besser (deutscher Klartext) — die Behandlung ist also uneinheitlich.
• Wird eine Matrix-Seite bei bereits gestoppter API frisch geladen, meldet sie dem Administrator „Zugriff verweigert" statt „Server nicht erreichbar". Das ist eine irreführende Diagnose: der Administrator vermutet ein Rechteproblem statt eines Serverausfalls.
• Der Aktivierungsdialog duzte („möchtest du die Freigaben separat konfigurieren?"), während die übrige Oberfläche siezt. Behoben am 2026-09-07 (Quick 260907-ipz) — zusammen mit drei weiteren Du-Stellen, die dabei auffielen: dem Leerzustand der Gruppenliste, der Sperrseite und dem Marktplatz-Hinweis.
• Das Deaktivieren eines Moduls entfernt seine Freigaben nicht. Beim Wiederaktivieren sind die alten Freigaben sofort wieder wirksam. Das wirkt gewollt, ist aber nirgends festgehalten.

WINDOWS #3 — Sperrung ohne Freigabe über alle vier Ebenen (15-08) — DURCHGEFÜHRT, MIT BEFUND

Geprüft mit nutzer2 (Rolle USER, Freigabe für Ausschreibungs-Radar entzogen) gegen nutzer1 (Freigabe über Gruppe) und admin.

Ebene	Ergebnis
1. Sidebar	Kategorie „procurement" fehlt für nutzer2 vollständig; nur „security tools" (Cert Manager, dort freigegeben) erscheint ✓
2. Direkte URL /modules/procurement/tender-radar	403-Seite „Kein Zugriff auf dieses Modul" mit Handlungsanweisung und Weg zurück ✓ (D-07)
3. Marketplace	Karte trägt „Aktiviert" und das Sperr-Badge „Kein Zugriff", ist nicht anklickbar; der Klick löst den Toast „Kein Zugriff auf dieses Modul — wende dich an deinen Administrator." aus und navigiert nicht ✓ (D-08). Modul wird gekennzeichnet, nicht ausgeblendet
4. API	nutzer2 erhält auf /modules/tender-radar und allen geprüften Unterendpunkten (saved-searches, rss-feeds, email-config) durchgehend HTTP 403; nutzer1 durchgehend 200 ✓

Der Nachweis von PERM-04 gelingt damit auf drei von vier Ebenen nicht vollständig — siehe WINDOWS #10.

WINDOWS #10 (neu) — der Zugriffs-Guard greift nicht auf modul-eigenen Routen

Ebene 2 ist nur für die generische Route abgesichert. Der Guard sitzt in modules/[category]/[moduleSlug]/page.tsx. Vier Module haben daneben fest verdrahtete eigene Routen:

apps/web/src/app/(portal)/modules/cert-manager/
apps/web/src/app/(portal)/modules/dkv-fleet/
apps/web/src/app/(portal)/modules/domaincheck/
apps/web/src/app/(portal)/modules/tender-radar/

Diese laufen am Guard vorbei. Im Browser als nutzer2 ohne Freigabe gemessen:

Adresse	Ergebnis
/modules/procurement/tender-radar	403-Seite ✓ (generische Route, abgesichert)
/modules/tender-radar	volle Seite — Überschrift, Filter, Suchprofil-Formular, Trefferliste, Zahnrad-Link
/modules/tender-radar/my-sources	volle Seite — Postfach-Formular, Feed-Formular, Digest-Auswahl, alle Knöpfe bedienbar
/modules/dkv-fleet	volle Seite — inklusive Knopf „Jetzt pruefen" und Link zu den Moduleinstellungen

Es werden keine Daten preisgegeben. Die API antwortet auf jedem Endpunkt mit 403, die Listen bleiben leer. Der Defekt liegt auf der Anzeigeebene:

1. Der Nutzer sieht eine Seite, die er nicht benutzen darf, statt der 403-Seite.
2. Die Bedienelemente sind anklickbar und laufen ins Leere — genau das, was Plan 17-03 auf der Einstellungsseite des Ausschreibungs-Radars abgeschafft hat.
3. Statt einer verständlichen Meldung erscheinen rohe englische Techniktexte mitten in der deutschen Oberfläche: „Module 'tender-radar' is not accessible for this user", „Failed to fetch tenders", „Failed to fetch saved searches", „Failed to fetch notification preference".

Beleg: uat-2026-09-07/befund-modul-eigene-route-ohne-freigabe.png

Behoben am 2026-09-07 (Quick-Task 260907-e8k, Commits 4a23e13, 69b6418). Umgesetzt wurde nicht ein einzelnes Layout mit Pfadauflösung, sondern je ein layout.tsx pro Modulverzeichnis mit fest eingetragenem Slug — ein Layout deckt in Next.js alle verschachtelten Unterrouten automatisch mit ab, und der Slug steht damit explizit im Code statt aus dem Pfad geraten zu werden. Das 403-Markup liegt jetzt einmal als gemeinsame Komponente vor, die generische Route nutzt dieselbe. Ein Test liest das Modulverzeichnis aus und verlangt für jedes nicht-dynamische Unterverzeichnis eine layout.tsx, damit ein künftiges Modul die Lücke nicht erneut aufreißt.

Gegenprobe im Browser nach dem Fix (2026-09-07)

Frisch gebautes Web-Image, echter Chrome, dieselben Konten:

Konto	Adresse	Ergebnis
admin (SUPER_ADMIN)	/modules/tender-radar, /modules/tender-radar/my-sources, /modules/dkv-fleet, /modules/procurement/tender-radar	alle unverändert offen — die Sperre trifft niemanden zu viel
nutzer1 (Freigabe über Gruppe)	/modules/tender-radar/my-sources	offen, alle drei Abschnitte da — Phase-17-Funktion unbeschädigt
nutzer2 (keine Freigabe)	/modules/tender-radar, /modules/tender-radar/my-sources, /modules/tender-radar/settings, /modules/dkv-fleet	alle gesperrt, 403-Seite als Serverantwort
nutzer2 auf /modules/cert-manager (dort hat er eine Freigabe)		offen — die Gegenprobe gegen Überschießen

Beleg: uat-2026-09-07/w10-fix-my-sources-gesperrt.png

Messhinweis für spätere Prüfungen: Ein erster Versuch, die Adressen per fetch() aus der laufenden Seite heraus zu prüfen, meldete fälschlich alle Seiten als gesperrt — auch für den Administrator. Der Aufruf führt die Sitzung nicht so mit, wie eine echte Navigation es tut. Die Zahlen oben stammen ausschließlich aus echten Seitenaufrufen. Wer das nachprüft, sollte nicht per fetch messen.

Ergebnis

WINDOWS #1 und #2 sind geschlossen. #3 ist als Durchlauf erledigt. Der dabei gefundene Defekt wurde als #10 erfasst, am selben Tag behoben und im Browser gegengeprüft — er ist damit ebenfalls geschlossen.