Projektpartnerportal — Dogfooding, AK-Verifikation & Kunden-Testanleitung

Worum es hier geht. Dieses Dokument hält fest, wie das Projektpartnerportal als echter Freiberufler durchgespielt wurde, welche Akzeptanzkriterien (AK) erfüllt sind, welche Lücken dabei gefunden und geschlossen wurden, und — für die Kolleginnen und Kollegen, die das Portal abnehmen — exakte Testschritte pro Kriterium samt Video-Mitschnitten der wichtigsten Abläufe. Geprüft wurde mit dem Test-Freiberufler Max Mustermann (max.mustermann@example.com).

Befund aus der Quelldaten-Analyse. Die Neos-Quelldatenbank speichert kein auswertbares, pro Person variierendes Einwilligungs-Kennzeichen. Konkret geprüft an allen 37.664 Datensätzen:

• policyoption (Ja/Nein-Feld) ist bei allen 37.664 Konten 0 — also konstant und damit als Filter wertlos: eine Filterung „nur Zustimmer übernehmen“ würde entweder alle oder niemanden übernehmen.
• magazineoption variiert zwar (531 Opt-ins), ist aber die Newsletter-Einwilligung, nicht die Datenschutz-Zustimmung.
• Die Registrierungs- und Konto-Änderungs-Tabellen führen ebenfalls kein Zustimmungs-Flag.

Bewertung. Eine quelldatengetriebene Filterung ist weder möglich noch sinnvoll. Die Datenschutz-Zustimmung war jedoch Voraussetzung der Neos-Registrierung — genau wie die beiden Pflicht-Häkchen im neuen Drupal-Formular (AK A2). Jedes übernommene Konto hat bei der Anmeldung zugestimmt; D3 ist damit als Precondition erfüllt. Bewusst nicht umgesetzt wurde ein künstlicher Filter auf ein konstantes Feld — das wäre Scheinmechanik ohne Wirkung.

Offene Legal-Klärung (Empfehlung). Falls Datenschutz/Legal eine erneute aktive Zustimmung der Bestandspartner verlangt, bietet sich der ohnehin erzwungene Erst-Login (D2) als Einsammel-Punkt an: das Reset-Formular könnte um eine Zustimmungs-Checkbox ergänzt werden. Das ist eine Produkt-/Rechtsentscheidung, kein Code-Defekt — daher hier dokumentiert, nicht eigenmächtig gebaut.

grün 79 Tests · 1.793 Assertions · 0 Errors · 0 Failures (Deprecations sind Framework-Hinweise von Drupal-Core/Contrib, keine Fehler).

Befehl: phpunit web/modules/custom/solcom_projektpartner/tests/{Kernel,Unit,Functional} web/modules/custom/solcom_projektpartner_alert/tests in DDEV.

Portal-Startseite / Navigation nach Login (Lücke #4). Alle Selbstservice-Funktionen (Profil, Unterlagen, Suchagent, Merkliste) funktionieren, sind aber nach dem Login nicht zentral verlinkt. Die Informationsarchitektur sieht dafür bereits die Seite „Mein Projektpartnerprofil“ (/mein-projektpartnerprofil) vor — derzeit eine leere Canvas-Stub-Seite. Empfehlung zur Abstimmung: diese Canvas-Seite mit Kacheln/Links zu Profil bearbeiten, Suchagent, Merkliste, Abmelden und Konto löschen redaktionell füllen und den Login-Redirect dorthin lenken. Da Canvas-Seiten bewusst lokal/redaktionell gepflegt werden (Entscheidung vom 2026-05-17), ist das Inhaltsarbeit, kein Code — daher hier als Empfehlung, nicht eigenmächtig umgesetzt.

Update 2026-06-17 umgesetzt (ADR-0053): Account-Menü-Links „Mein Profil", „Suchagent", „Merkliste" ergänzt; nach Login werden Projektpartner auf das eigene Profil (ID-lose Route /projektportal/profil) geleitet. Die redaktionelle Hub-Seite unter /projektportal bleibt der Content-Schritt (Login-Redirect dann einzeilig umstellbar). Browser-verifiziert.

Verwaltungs-Oberfläche für eingeloggte Endnutzer sichtbar Härtung vor Go-Live

Jeder eingeloggte Nutzer — auch der Freiberufler Max — sieht auf den Selbstservice-Seiten eine Verwaltungs-Leiste: die linke Admin-Seitenleiste, das Admin-Design auf Formular-Seiten und das Schnellsuch-Werkzeug „Coffee“. Ursache ist die Standard-Rolle „Authentifizierter Benutzer“, die alle eingeloggten Nutzer tragen und die vier verwaltungsnahe Rechte enthält: access navigation, view the administration theme, access administration pages, access coffee. Diese Rechte stehen in der versionierten Konfiguration (config/sync/user.role.authenticated.yml) und würden so auch live ausgeliefert.

Einordnung: Das ist keine Rechte-Ausweitung — Max bekommt keine Fähigkeit über seine Projektpartner-Rechte hinaus. access administration pages öffnet nur das /admin-Menü, dessen Einzelseiten weiterhin je einzeln rechtegeprüft sind (Max' /admin bleibt praktisch leer). Sichtbar ist also Admin-Optik, kein Admin-Können. Trotzdem widerspricht es dem Ziel „nur Frontend-Hülle“ und wirkt unfertig.

Warum nicht direkt behoben: Die betroffene Rolle ist seitenweit und wird auch von Redakteuren getragen; Drupal-Rollen sind rein additiv (es gibt kein rollenweises „Entziehen“). Die Rechte einfach zu streichen würde den Redakteuren ihren legitimen Verwaltungszugang nehmen. Sauber ist, diese vier Rechte von „Authentifizierter Benutzer“ auf die konkreten Redaktions-/Admin-Rollen zu verschieben — eine seitenweite Architektur-Entscheidung außerhalb des Portal-Tickets. Empfehlung: eigenes Ticket, vor Go-Live.

Zusätzlich auf derselben Rolle: skip CAPTCHA und bypass honeypot protection. Für eingeloggte Nutzer ist das eine gängige, oft bewusste Einstellung — bitte nur kurz bestätigen, dass sie gewollt ist.

Update 2026-06-17 umgesetzt (ADR-0053): Die vier Rechte wurden von „Authentifizierter Benutzer“ auf content_editor/content_manager verschoben. Projektpartner sehen kein Admin-Chrome mehr; /admin liefert für sie 403. Browser-verifiziert (body-class ohne gin--core-navigation, „Zugriff verweigert“ auf /admin). skip CAPTCHA + bypass honeypot protection bewusst auf authenticated belassen — bitte bestätigen.

Einheitliche Benennung der Merkliste Kleinigkeit

Derselbe „Projekt merken“-Mechanismus trägt drei verschiedene Bezeichnungen: „Bewerbungsliste“ auf dem Schalter der Projektseite, „Merkliste“ als Seitentitel und Menü-Ziel, und „In meiner Projektliste“ auf der Karte in der Merkliste. Für Endnutzer wirkt das wie drei verschiedene Funktionen. Empfehlung: auf einen Begriff festlegen (Vorschlag: durchgängig „Merkliste“) und Schalter-Beschriftungen angleichen.

Update 2026-06-17 umgesetzt (ADR-0053): Durchgängig „Merkliste“ — „Bewerbungsliste“, „In meiner Projektliste“ und „Zu meiner Projektliste“ ersetzt in beiden Node-Templates, beiden SDC-Komponenten, dem JS und den Canvas-Configs.