PRD · SOLCOM Projektpartnerportal · P2503-275
Projekt-Alert-Konsolidierung
approved
2026-07-02 · Target-Release 08.07.2026 ·
ADR: 0055 ·
Plan: 2026-07-02-001 ·
Jira: P2503-275
Scope-Änderung 2026-07-03 (ADR-0056):
Der Projekt-Alert steht nur noch registrierten, eingeloggten Projektpartner:innen zur Verfügung. Anonyme Besucher:innen sehen auf
/projektportal/projektalert einen Teaser mit Login- und Registrieren-Aufruf statt des Formulars. Damit entfallen die Stories des Clusters A (anonyme Anlage, Double-Opt-in, Token-Bearbeiten-Links) sowie Story 20 und 22 in ihrer Gast-Form: Die 7.314 aktiven Gast-Alerts des Altsystems werden nicht migriert (Hard Cut); übernommen werden ausschließlich user-gebundene aktive Alerts. Der Token-Abmelde-Link in den E-Mails bleibt als Ein-Klick-Abmeldung erhalten. Dieses Dokument bleibt als Stand vom 02.07.2026 unverändert stehen — das verbindliche Delta lebt in ADR-0056.
Problem Statement
Wer auf der neuen SOLCOM-Website über passende Projekte informiert werden will, stößt auf einen Projekt-Alert, der Vertrauen kostet statt Vertrauen aufzubauen: Beim Eintippen von Schlagworten erscheinen kryptische Vorschläge wie „anlagen^bau". Eigene Begriffe wie „Kunde" werden nicht akzeptiert, obwohl das auf der alten Website selbstverständlich ging. Niemand erklärt, wie oft und wann E-Mails kommen. Dasselbe Schlagwort lässt sich gleichzeitig als Suchbegriff und als Ausschluss eintragen, ohne dass das Formular widerspricht. Und wer den Alert ohne Registrierung angelegt hat, findet ihn nie wieder: Die Seite ist beim nächsten Besuch leer, es gibt keinen Weg, die eigenen Kriterien anzusehen, zu ändern oder zu löschen.
Hinter diesen Symptomen steht ein strukturelles Problem: Es existieren zwei parallel gebaute Alert-Systeme — ein „Suchagent" nur für eingeloggte Projektpartner:innen (mit Bearbeiten und Löschen, aber ohne Ausschluss-Kriterien) und ein anonymer „Projekt-Alert" (mit Ausschluss-Kriterien und Double-Opt-in, aber ohne jede Verwaltungsmöglichkeit). Der Stakeholder hat nur das zweite gesehen und vermisst genau das, was das erste kann. Zusätzlich hängen am alten System rund 13.000 aktive Abonnements (registrierte Nutzer:innen und Gäste), die beim Relaunch ersatzlos verloren gingen, wenn niemand sie mitnimmt.
Solution
Es gibt künftig genau einen Projekt-Alert für alle — erreichbar unter derselben Adresse wie auf der alten Website (/projektportal/projektalert). Schlagworte lassen sich frei eintippen; beim Schreiben schlägt das Formular Begriffe aus einer redaktionell gepflegten Liste vor. Suchbegriffe und Ausschlüsse verhalten sich identisch, Widersprüche (gleicher Begriff auf beiden Seiten) werden abgewiesen. Das Formular erklärt die Versandlogik in einem Satz: E-Mail, sobald neue passende Projekte online gehen — jedes Projekt nur einmal. Eine Trefferzahl zeigt schon beim Ausfüllen, wie viele Projekte aktuell passen würden.
Anonyme Abonnent:innen bestätigen ihr Abo wie bisher per E-Mail-Link (Double-Opt-in) und erhalten künftig in jeder E-Mail zwei Verwaltungslinks: „Alert bearbeiten" öffnet das ausgefüllte Formular (ändern oder löschen), „Abmelden" beendet das Abo sofort. Eingeloggte Projektpartner:innen legen ihren Alert ohne erneute Kontaktdaten-Eingabe an, er ist sofort aktiv, und sie pflegen ihn jederzeit im Portal — genau einen pro Person. Die aktiven Abonnements der alten Website (auch die von Gästen) werden vollständig übernommen; niemand muss sich neu anmelden, und niemand wird nach der Umstellung mit E-Mails zu längst veröffentlichten Projekten geflutet.
User Stories
Cluster A — Anonyme Interessent:innen
- Als anonyme:r Besucher:in möchte ich einen Projekt-Alert anlegen, ohne mich registrieren zu müssen, damit ich mit minimaler Hürde über passende Projekte informiert werde.
- Als anonyme:r Besucher:in möchte ich beliebige eigene Schlagworte eintippen können (z. B. „Kunde"), damit meine Suche nicht an einer vorgegebenen Liste scheitert.
- Als anonyme:r Besucher:in möchte ich beim Tippen sinnvolle Vorschläge aus einer gepflegten Begriffsliste sehen, damit ich schneller und tippfehlerfrei zu guten Kriterien komme.
- Als anonyme:r Besucher:in möchte ich keine kryptischen Vorschläge wie „anlagen^bau" sehen, damit ich dem Formular vertraue.
- Als anonyme:r Besucher:in möchte ich Schlagworte ausschließen können — mit derselben freien Eingabe wie bei den Suchbegriffen, damit sich beide Felder konsistent verhalten.
- Als anonyme:r Besucher:in möchte ich eine verständliche Fehlermeldung bekommen, wenn ich denselben Begriff als Suchwort und als Ausschluss eintrage, damit mein Alert keine widersprüchlichen Kriterien enthält.
- Als anonyme:r Besucher:in möchte ich Einsatzgebiete ausschließen können (Remote, Österreich, Schweiz, deutsche PLZ-Bereiche, andere Länder), damit ich nur regional relevante Projekte erhalte.
- Als anonyme:r Besucher:in möchte ich schon beim Ausfüllen sehen, wie viele Projekte aktuell auf meine Kriterien passen, damit ich einschätzen kann, ob meine Kriterien zu eng oder zu weit sind.
- Als anonyme:r Besucher:in möchte ich im Formular erklärt bekommen, wann und wie oft ich E-Mails erhalte, damit ich weiß, was mich erwartet.
- Als anonyme:r Besucher:in möchte ich mein Abo per Bestätigungslink in einer E-Mail aktivieren (Double-Opt-in), damit niemand fremde Adressen anmelden kann.
- Als Abonnent:in möchte ich in jeder E-Mail einen „Alert bearbeiten"-Link haben, der mein ausgefülltes Formular öffnet, damit ich meine Kriterien jederzeit ansehen und ändern kann — auch ohne Konto.
- Als Abonnent:in möchte ich meinen Alert über den Bearbeiten-Dialog oder den Abmelde-Link endgültig löschen können, damit ich die Kontrolle über meine Daten behalte.
- Als Abonnent:in möchte ich beim erneuten Ausfüllen mit derselben E-Mail-Adresse keine zweite Anmeldung erzeugen, sondern per E-Mail auf meinen bestehenden Alert hingewiesen werden, damit keine Dubletten entstehen.
- Als Besucher:in möchte ich nicht über das Formular herausfinden können, ob eine fremde E-Mail-Adresse bereits einen Alert hat, damit meine Daten geschützt bleiben.
Cluster B — Registrierte Projektpartner:innen
- Als eingeloggte:r Projektpartner:in möchte ich meinen Alert ohne erneute Eingabe meiner Kontaktdaten anlegen, damit das Formular meine Zeit respektiert.
- Als eingeloggte:r Projektpartner:in möchte ich, dass mein Alert sofort aktiv ist (ohne Bestätigungs-E-Mail), damit ich keinen unnötigen Schritt gehen muss.
- Als eingeloggte:r Projektpartner:in möchte ich genau einen Alert besitzen, den ich im Portal ansehen, ändern und löschen kann, damit meine Benachrichtigungen an einer Stelle gepflegt sind.
- Als eingeloggte:r Projektpartner:in möchte ich unter der bisherigen Suchagent-Adresse automatisch auf die neue Alert-Seite geleitet werden, damit alte Lesezeichen weiter funktionieren.
Cluster C — Bestands-Abonnent:innen der alten Website
- Als Bestands-Abonnent:in der alten Website möchte ich, dass mein aktiver Alert den Relaunch übersteht, damit ich mich nicht neu anmelden muss.
- Als Gast-Abonnent:in der alten Website (ohne Konto) möchte ich, dass auch mein Alert übernommen wird, damit mein aktives Abo nicht stillschweigend verschwindet.
- Als übernommene:r Abonnent:in möchte ich nach der Umstellung keine Flut von E-Mails zu Projekten erhalten, die schon vor der Umstellung online waren, damit der Alert nützlich bleibt statt lästig.
- Als übernommene:r Abonnent:in möchte ich in den künftigen E-Mails dieselben Verwaltungsmöglichkeiten haben wie Neu-Abonnent:innen (bearbeiten, abmelden), damit ich meine übernommenen Kriterien nachschärfen kann — gerade wenn die Umstellung meine Suchlogik vereinfacht hat.
- Als übernommene:r Abonnent:in möchte ich im Zweifel eher etwas mehr passende Projekte sehen als zu wenige, damit mir durch die Umstellung keine Chancen entgehen.
Cluster D — Redaktion und Betrieb
- Als Redakteur:in möchte ich die Vorschlagsliste der Schlagworte selbst pflegen können, damit die Vorschläge zum Projektangebot und zur Sprache unserer Zielgruppe passen.
- Als Redakteur:in möchte ich, dass frei eingetippte Nutzer-Begriffe meine gepflegte Liste nicht verändern, damit die Vorschlagsqualität nicht schleichend verfällt.
- Als Betreiberin möchte SOLCOM genau ein Alert-System betreiben, damit jede künftige Änderung nur einmal gebaut, getestet und gepflegt werden muss.
- Als Betreiberin möchte SOLCOM, dass Bearbeiten- und Abmelde-Links nicht erratbar sind, damit niemand fremde Alerts manipulieren kann.
- Als Betreiberin möchte SOLCOM unbestätigte Anmeldungen nach kurzer Frist automatisch löschen, damit keine unnötigen personenbezogenen Daten liegen bleiben.
- Als Betreiberin möchte SOLCOM jedes Projekt pro Abonnent:in höchstens einmal verschicken, damit der Alert als hochwertig wahrgenommen wird.
- Als Betreiberin möchte SOLCOM, dass die Kuriositäten-Begriffe auch aus den Filtern der Projektliste verschwinden und über die Importe nicht wieder entstehen, damit das Problem nicht nur am Alert-Formular kaschiert wird.
Implementation Decisions
- Ein System, eine Basis: Das anonym-fähige Alert-Modul (
solcom_project_offer_alert, Domain-Begriff „Suchagent / Projekt-Alert" laut Glossar) wird das einzige Alert-System. Das eingeloggt-only-Modul solcom_projektpartner_alert wird stillgelegt und deinstalliert; vor der Deinstallation wird der Datenbestand auf den Zielumgebungen geprüft und ggf. überführt. Begründung und verworfene Alternativen: ADR-0055.
- Schlagwort-Eingabe: Freie Chip-Eingabe (minimal 2 Zeichen, maximal 4 Begriffe pro Feld — Parität zum Altsystem) mit Autocomplete-Vorschlägen aus einem neuen, redaktionell gepflegten Vocabulary
alert_suggestion. Initialbefüllung aus der bereinigten redaktionellen Begriffsliste des Neos-Altsystems. Nutzereingaben werden als Zeichenketten am Alert gespeichert und erzeugen keine Taxonomie-Begriffe. Das skill-Vocabulary bleibt Quelle der Projektlisten-Filter, wird separat bereinigt und ist nicht mehr Vorschlagsquelle des Alerts.
- Matching-Semantik: Der vorhandene Matcher arbeitet substring-basiert gegen den Projekt-Freitext (Titel, Anforderungen, Skills). Include-Begriffe wirken als ODER-Liste, Ausschluss-Begriffe haben Vorrang, Gebiets-Ausschlüsse arbeiten über die bestehenden Buckets (Remote, AT, CH, deutsche PLZ-Bereiche 0–9, International). Die Bool-Gruppen-Fähigkeit des Datenmodells bleibt ungenutzt bestehen.
- Verwaltung für Anonyme: Neue tokenisierte Bearbeiten-Route nach dem Muster der bestehenden Bestätigen-/Abmelde-Routen. Der Bearbeiten-Link steht in jeder E-Mail (Bestätigung und Digest). Die Route rendert das Abo-Formular vorbefüllt im Bearbeitungsmodus inklusive Löschen. Zugriff allein über Token-Wissen (UUID) — identisches Vertrauensmodell wie im Altsystem.
- Dublettenschutz, enumeration-safe: Auch auf dem anonymen Pfad wird per E-Mail-Adresse auf einen bestehenden Alert geprüft. Bei Treffer entsteht keine zweite Entity und keine verräterische UI-Meldung; stattdessen erhält die Adresse eine E-Mail mit dem Bearbeiten-Link.
- Versandlogik: Keine Frequenz-Einstellung (wie im Altsystem). Erklärtext im Formular; Versand cron-getaktet nur bei neuen Treffern; ein Pro-Projekt-Versandprotokoll (Alert × Projekt einmalig) verhindert Wiederholungen — Mechanik nach Neos-Vorbild. Das vorhandene Frequenz-Feld bleibt ungenutzt im Datenmodell.
- Validierung: Identische Begriffe in Include und Exclude werden mit Fehlermeldung abgewiesen.
- Trefferzahl: Ein AJAX-Endpunkt liefert die aktuelle Trefferzahl über den vorhandenen Matcher. Ausdrücklich nice-to-have: fällt bei Zeitdruck als erstes und wird Follow-up.
- Bestandsübernahme: Alle aktiven Alerts des Neos-Altsystems (registrierte und Gast-Abonnent:innen, 12.912 Stück) werden migriert — ohne erneutes Double-Opt-in, da der Consent im Altsystem per Double-Opt-in erteilt wurde und bis zur Abbestellung gilt. ODER-Gruppen der Altdaten werden zu flachen ODER-Listen abgeflacht (bewusste Entscheidung: eher mehr Treffer als weniger; Wildcards werden entfernt, Substring-Matching deckt Präfixe implizit). Gebiets-Ausschlüsse mappen eins zu eins. Jeder migrierte Alert erhält ein frisches Token. Gegen Massen-Versand nach der Umstellung wird das Pro-Projekt-Versandprotokoll mit dem Ist-Projektbestand vorbefüllt.
- URL-Kanon:
/projektportal/projektalert bleibt die eine Alert-Seite (pfadgleich mit der alten Website — Alt-Lesezeichen und Alt-Mail-Links auf die Seite bleiben gültig). Die bisherige Suchagent-Seite wird zur Weiterleitung.
- Datenhygiene der Importe: Die beiden Projektdaten-Importe (Salesforce, RSM) erkennen künftig Alt-Suchsyntax-Werte (
^/=/!) und überspringen sie, statt sie als Begriffe anzulegen; die 21 vorhandenen Kuriositäten-Begriffe werden mitsamt ihren wenigen Verweisen bereinigt.
Testing Decisions
Ein Seam, ganz oben (User-Entscheidung): Sämtliche Tests greifen an der öffentlichen HTTP-Oberfläche an — dem höchsten existierenden Seam. Getestet wird ausschließlich externes Verhalten: was ein:e Abonnent:in im Browser und im Postfach erlebt. Keine Assertions auf Entity-Interna, Service-Rückgaben oder Implementierungsdetails.
- Der eine Seam: die öffentlichen Routen des Alert-Systems (Formular-Seite, Direktroute zum Abonnieren, Token-Routen für Bestätigen/Bearbeiten/Abmelden) plus Cron-Auslösung plus Drupals Test-Mail-Collector als Beobachtungspunkt für alles Versendete.
- Lebenszyklus-Abdeckung über den Seam: Abonnieren (anonym mit Double-Opt-in, eingeloggt sofort aktiv), Bestätigen, Bearbeiten über Token (vorbefüllt, ändern, löschen), Abmelden, Dubletten-Verhalten (enumeration-safe), Validierungsfehler (Include/Exclude-Duplikat), Versand bei neuem passendem Projekt inklusive Einmaligkeit pro Projekt, korrekte Verwaltungslinks in jeder Mail.
- Migration über denselben Seam: Fixture-Altdaten (aus echten Neos-Samples abgeleitet, inklusive Bool-Gruppen, Gast-Alerts und Gebiets-Ausschlüssen) werden migriert; verifiziert wird über die Oberfläche — der Bearbeiten-Link eines migrierten Alerts zeigt die abgeflachten Kriterien, ein neues passendes Projekt löst genau eine Digest-Mail aus, Alt-Projekte lösen keine aus.
- Prior Art: der Functional-Test-Harness aus dem Projektpartnerportal-Self-Service-Strang (P2503-226) mit Browser-getriebenen Formular-Flows und Mail-Assertions; die bestehenden Token-Routen-Muster des Alert-Moduls.
- Bewusster Trade-off: Functional-Tests sind langsamer als Kernel-Tests; Matching-Edge-Cases (PLZ-Buckets, Exclude-Vorrang) werden über gezielt konstruierte Fixture-Projekte am selben Seam geprüft statt über einen separaten Service-Seam. Entscheidung des Site Owners zugunsten maximaler Realitätsnähe.
- Ergänzend (kein Test-Seam): PHPCS/PHPStan lokal vor jedem PR; manuelle Browser-Verifikation mit Mail-Sink vor jedem UI-Done gemäß Projektregel.
Out of Scope
- ODER-Gruppen-Eingabe (bis zu vier verknüpfte Schlagwort-Felder wie im Altsystem) — explizit gestrichen; das Datenmodell bliebe fähig, die Oberfläche bietet es nicht an.
- Frequenz-Wahl (täglich/wöchentlich) im Formular.
- Treffer-Liste als Vorschau im Formular — nur die Trefferzahl ist im Scope (und selbst die ist nice-to-have).
- Übernahme gemerkter Projekte („Bookmarks") aus dem Altsystem — bleibt wie im Glossar festgehalten ausgeschlossen (kein stabiler Projekt-Schlüssel).
- Re-Opt-in-Kampagne für Bestands-Abonnent:innen — bewusst verworfen (ADR-0055).
- Vollsanierung des
skill-Vocabularys über die 21 Kuriositäten-Begriffe hinaus (etwa Dubletten-Zusammenführung der ~2.600 Begriffe).
- Benachrichtigungen für andere Inhaltstypen (Stellenanzeigen/Vacancies) — der Alert bleibt auf Projektangebote beschränkt.
Further Notes
- Das Neos-Altsystem liegt vollständig lokal vor (Quelltext und Datenbank-Spiegel) und diente als empirische Referenz für Eingabeverhalten, Versand-Mechanik und Bestandszahlen; die Zugriffspfade sind maschinenlokal in
CLAUDE.local.md dokumentiert.
- Das größte operative Risiko ist der Massen-Versand unmittelbar nach der Migration; die Mitigation (Vorbefüllung des Versandprotokolls) ist Teil der Implementation Decisions und muss vor dem ersten produktiven Cron-Lauf greifen.
- Reihenfolge und Tages-Sequenz bis zum Go-Live am 08.07.2026 stehen im Implementation Plan; die Architektur-Begründung mit sieben verworfenen Alternativen im ADR-0055.
- Das Customer-Lens-Review (Decision-Time-Gate) lief zum Zeitpunkt der PRD-Erstellung noch; materielle Einwände werden als Plan-Korrektur oder Follow-up-ADR nachgezogen.
- Der Stakeholder-Eindruck „auf der alten Homepage konnten nur registrierte Nutzer einen Alert hinterlegen" ist durch den Altdaten-Befund widerlegt (7.314 Gast-Alerts) — relevant für die Stakeholder-Kommunikation, weil die anonyme Anlage kein Relaunch-Neuzugang ist, sondern Kontinuität.