management/docs/issues/0103-wiki-zugang-ohne-gruppe-endet-stumm.md

type, id, status, created, milestone, priority, projekt, related, gitlab_iid

type	id	status	created	milestone	priority	projekt	related	gitlab_iid
issue	0103	open	2026-08-18	M1	medium	gitops	docs/issues/0049-wikijs-oidc-rollen-abschottung.md docs/adr/0014-wikijs-loest-docusaurus-ab.md	62

Wiki: Anmeldung ohne Gruppe endet stumm — wiki-anwender hat null Mitglieder

Aufgefallen 2026-08-18, weil @apo nicht ins Wiki kam. Die Einzelfrage ist ein Handgriff; das Issue führt den Teil, der bleibt.

Befund (gemessen am laufenden System)

@apo meldet sich erfolgreich an und landet in keiner Gruppe:

Prüfung	Ergebnis
Wiki-Nutzer für apo	vorhanden (id 6), angelegt 2026-08-16, letzter Login 2026-08-18 17:21
Identität belegt	OIDC-Subjekt 2fafe38b… = apos upstream_oauth_links-Eintrag in MAS
Gruppen dieses Nutzers	keine
Gruppe wiki-anwender (id 4)	existiert, 0 Mitglieder
Gruppe authentik Admins (id 3)	1 Mitglied (sorB)

Die Gruppen-Übernahme selbst funktioniert — sonst wäre sorB nicht automatisch in authentik Admins gelandet. Es fehlt die Mitgliedschaft, sonst nichts.

Warum daraus Stille wird

Drei bewusste Einzelentscheidungen ergeben zusammen eine Sackgasse:

1. selfRegistration: True auf der OIDC-Strategy — der erste Login legt ein Konto an, ohne dass jemand etwas tun muss.
2. autoEnrollGroups: [] — dieses Konto bekommt keine Gruppe.
3. Guests wurde per Konfig-Job auf permissions: [], pageRules: [] gesetzt, und die einzige Regel für home gilt nur für wiki-anwender (#0049).

Ergebnis: Für einen Nutzer ohne Gruppe greift auf jedem Pfad Default-Deny, die Startseite eingeschlossen. Er sieht kein „du brauchst eine Freigabe", sondern nichts. Betrieblich ist es genauso still: Bei der aktuellen Log-Stufe steht in den Wiki-Logs nur der Git-Sync — ein Login ohne Gruppe hinterlässt keine Zeile, kein Zähler, keine Meldung. Niemand erfährt, dass jemand vor der Tür stand.

Das betrifft nicht nur apo. wiki-anwender hat null Mitglieder: Das Wiki ist derzeit faktisch Admin-only, und jeder Nicht-Admin, der es je versucht hat, hat dasselbe erlebt.

Dieselbe Klasse wie der mrtc-Ausfall: alles grün, Dienst gesund, benutzen kann es keiner — und nichts meldet es.

Zu entscheiden

Empfehlung: autoEnrollGroups auf wiki-anwender setzen (eine Zeile in apps/production/wikijs-config.py, der Job ist idempotent und re-runnable). Begründung: Wer sich über Authentik anmelden kann, ist bereits kuratiert — der Zugang setzt einen Einladungstoken voraus. Die Kuratierung findet dort statt, nicht noch einmal im Wiki. /anwender ist ausdrücklich die Anwenderfläche, und betrieb/* bleibt über Default-Deny weiterhin admin-only; die Abschottung aus #0049 bleibt also erhalten, sie verschiebt nur ihre Grenze auf die Stelle, die sie wirklich trennt.

Alternative, falls die Kuratierung pro Person gewollt ist: Mitgliedschaft bleibt Handarbeit in Authentik — dann muss aber die Sackgasse sprechen, sonst wiederholt sich der Fall bei jedem neuen Nutzer.

Beides schließt sich nicht aus; die Rückmeldung ist auch bei Auto-Enrollment sinnvoll, weil sie den Fall „Gruppe später entzogen" abdeckt.

Acceptance

• Ein Nutzer ohne Sonderrechte, der sich neu anmeldet, kommt an die Anwenderdoku heran oder erfährt im Klartext, was ihm fehlt — nachgewiesen an einem echten Login, nicht an der Konfiguration.
• betrieb/* bleibt für ihn gesperrt (Gegenprobe, sonst ist die Abschottung aufgeweicht statt verschoben).
• Der Fall „angemeldet, aber ohne Gruppe" ist erkennbar: mindestens eine Logzeile oder ein Zähler, damit der nächste Fall nicht wieder erst auffällt, wenn sich jemand beschwert.
• @apo kommt rein (die auslösende Frage — kein Ersatz für die Punkte oben).

Sofortmaßnahme, unabhängig davon

apo in Authentik der Gruppe wiki-anwender hinzufügen; greift beim nächsten Login automatisch, ohne Eingriff im Wiki. Das ist eine Rechtevergabe und liegt bei sorb.