Implementation Plan · SOLCOM / P2503-275 · Go-Live 08.07.2026

Projekt-Alert-Konsolidierung — zwei Systeme werden eins

Auftrag Sub-Task P2503-275 (Parent-Bug P2503-270, Findings Projektpartnerportal): Stakeholder-Findings zum Projekt-Alert vor Go-Live vollständig lösen. Entscheidung aus dem Grilling vom 02.07.2026: Die zwei parallelen Alert-Systeme werden zu einem konsolidiert — solcom_project_offer_alert (Modul B) als Basis, solcom_projektpartner_alert (Modul A) wird stillgelegt. Architektur-Begründung: ADR-0055.
Scope-Änderung 2026-07-03 (ADR-0056) Der Projekt-Alert ist nur noch für registrierte Projektpartner:innen: Anonyme sehen einen Teaser mit Login-/Registrieren-CTAs statt des Formulars. WP4 (Migration) übernimmt nur user-gebundene aktive Neos-Alerts — Gast-Alerts enden per Hard Cut, die Soll-Zahl 12.912 gilt nicht mehr (neue Soll-Zahl per Quell-Query). Neues Arbeitspaket „Auth-Gating + Teaser" ersetzt die Anonym-Strecke aus WP1/WP2 (bereits gebauter Anonym-Code wird minimal gegated, Rückbau ist Post-Go-Live-Follow-up). Details: ADR-0056.
Deadline
08.07.2026
Module
2 → 1
Neos-Migration
12.912 aktive Alerts
Kanonische URL
/projektportal/projektalert
01

Entschiedene Leitplanken

Im Grilling mit dem Site Owner konvergiert; Details und verworfene Alternativen im ADR-0055.

FrageEntscheidung
ScopeVollüberarbeitung aller 5 Stakeholder-Findings vor Go-Live (keine Deaktivierung).
Basis-SystemModul B solcom_project_offer_alert — kann anonym (Double-Opt-in) und eingeloggt (Upsert) bereits; Matcher arbeitet Freitext-basiert.
Schlagwort-EingabeFreitext + kuratierte Vorschläge (Neos-Parität: Select2-tags:true-Verhalten). Neues Vocabulary alert_suggestion, Seed aus den 28 Neos-Technology-Nodes. Keine Term-Erzeugung durch User-Eingaben.
ODER-GruppenExplizit gestrichen (User-Entscheidung). Formular bleibt flach; Neos-Bool-Gruppen werden bei Migration zu OR-Listen abgeflacht.
Anonym-VerwaltungToken-Edit-Link in jeder Mail (Bestätigung + Digest) — Formular vorbefüllt, mit Löschen-Button. Enumeration-safe.
MigrationAlle 12.912 aktiven Neos-Alerts (User- und Gast-Alerts), ohne erneutes Double-Opt-in — Consent bestand im Altsystem.
FrequenzErklär-Copy statt Einstellung („E-Mail sobald neue passende Projekte erscheinen — jedes Projekt nur einmal"). frequency-Feld bleibt im Datenmodell ungenutzt.
Treffer-PreviewNur Trefferzähler (AJAX auf vorhandenen Matcher), keine Ergebnisliste. Nice-to-have — darf nachrutschen.
URL-Kanon/projektportal/projektalert überlebt (pfadgleich mit dem Neos-Altsystem — Alt-Bookmarks bleiben gültig); /projektportal/suchagent wird Redirect.
02

Arbeitspakete & Sequenz

Sechs Pakete, sequenziert auf die verbleibenden Tage bis zum 08.07. Go-Live-kritisch: WP1, WP3, WP5, WP6. WP4 idealerweise davor, notfalls unmittelbar danach.

Do 02.07.

WP1 — Formular & Versand härten

  • Tagify-Felder (Include + Exclude) von Taxonomy-Whitelist auf Freitext-Chips: Vorschläge aus alert_suggestion, enforceWhitelist aus, min. 2 Zeichen, max. 4. Speicherung bleibt String-basiert.
  • Vocabulary alert_suggestion (Config) + Seed via Update-Hook aus den Neos-Technology-Nodes (normalisiert, dedupliziert).
  • validateForm(): identischer Begriff in Include und Exclude → Validierungsfehler.
  • Anonymer Dedup-Pfad: bekannte E-Mail → keine Neuanlage, enumeration-safe Mail mit Edit-Link.
  • Erklär-Copy zur Versandlogik + Neos-Hinweistexte im Formular.
  • Versand: Pro-Projekt-Dedup (Alert × Node einmalig, Neos-Mechanik) ergänzend zu last_digest_sent.
solcom_project_offer_alertProjectOfferAlertSubscribeFormhook_cron
Fr 03.07.

WP2 — Token-Edit-Route

  • /projektportal/projekt-alert/bearbeiten/{token} nach Muster der bestehenden confirm/unsubscribe-Routen.
  • Formular vorbefüllt im Edit-Modus, Löschen-Button, Submit-Label „Aktualisieren".
  • Edit-Link in Bestätigungs- und Digest-Mail-Templates.
routing.ymlAlertConfirmationControllerMail-Templates
Sa–Mo

WP4 — Neos-Migration (neu geschrieben)

  • Migrate-Source (SqlBase, DB-Key neos) auf contenance_solcom_domain_model_projectalert, nur active=1; JOIN projectalertguest, User-Alerts via migration_lookup auf Drupal-uid.
  • Mapping siehe Sektion 03. Lokal gegen den echten Dump fahren, Zahlen abgleichen (Soll: 12.912).
  • Alte, nie lauffähige solcom_projektpartner_alert_neos-Migration + NeosAlertSource entsorgen (erwartete Tabelle neos_search_agent existiert im realen Dump nicht).
migrate_plusNeos-DBFixtures aus echten Samples
Mo 06.07.

WP3 + WP5 — Frontend-Slice und Modul-A-Stilllegung

  • WP3 (eigener Sub-Task): Redirect /projektportal/suchagent/projektportal/projektalert, Tagify-Chip-Styling im byte_theme, optional „Kein Gebiet ausschließen"-Default-Checkbox. Browser-Verify + WCAG-Check Pflicht.
  • WP5: Vorab Staging/Prod auf echte ppp_alert-Daten prüfen (mw app exec + drush); ggf. Mini-Überführung. Dann Canvas-Page/Block raus, Permission entziehen, Modul deinstallieren, Config-Cleanup, CONTEXT.md nachziehen.
byte_themeredirectsolcom_projektpartner_alert (Uninstall)
Di 07.07.

Staging-Durchlauf & Stakeholder-Demo

  • Deploy auf Staging, Migration gegen frischen Neos-Dump, QA-Case SQ-P0-08 (Suchagent/Projekt-Alert) aus dem Staging-QA-Loop abfahren.
  • Stakeholder-Demo mit den gelösten Findings; Mi 08.07. bleibt Puffer für Findings und Merge-Fenster.
StagingMailpit/Mail-SinkQA-Report
parallel

WP6 — Skill-Vocabulary-Hygiene

  • SkillTextSplit + RSM-_split_skills: Werte mit ^/=/! als Alt-Suchsyntax erkennen und skippen (nicht splitten — Fragmente wären Müll).
  • Update-Hook: die 21 kaputten skill-Terms löschen, ihre 1–2 Node-Referenzen bereinigen.
  • Unabhängig vom Alert — betrifft auch Projektlisten-Filter. Kann jederzeit landen.
solcom_project_offersolcom_rsm_importhook_update_N
03

Migrations-Mapping Neos → Drupal

Quelle: contenance_solcom_domain_model_projectalert (20.369 Zeilen, davon 12.912 aktiv; 13.053 user-, 7.314 gast-gebunden). Ziel: project_offer_alert-Entities.

Neos-QuelleDrupal-ZielTransformation
tags (serialisierte Bool-Gruppen, Wildcards wie projektleit*)filter_skillsUnserialisieren, alle Gruppen zu einer OR-Liste abflachen, * strippen, trimmen, deduplizieren. Substring-Matching des Matchers macht Präfix-Wildcards implizit.
notagsfilter_exclude_skillsWie tags, Ziel ist JSON-Array von Labels.
states / locations (Exclude-Semantik)filter_excluded_locations1:1-Mapping: AAT, D0D9DE_0DE_9, Remoteremote, Internationalinternational, CHCH.
user (Neos-Account-UUID)uidJoin auf Neos-User → ppp_idmigration_lookup gegen solcom_projektpartner_neos_user.
guestprojectalertguest (gender, firstname, lastname, email)Kontaktfelder der Alert-EntityDirektübernahme; kein Drupal-User entsteht.
hashTokenWird NICHT übernommen — frisches UUID-Token pro migriertem Alert (Alt-Hashes waren in Alt-Mails, die auf Alt-Routen zeigen).
activeconfirmedNur active=1 wird migriert, ankommt als confirmed=TRUE — kein erneutes Double-Opt-in.
04

Tests & Verifikation

EbeneAbdeckung
KernelMatcher (Include-OR, Exclude-Vorrang, Location-Buckets inkl. PLZ-Regex); Form-Validierung (Include/Exclude-Duplikat, anonymer Dedup-Pfad); Migration mit Fixtures aus echten Neos-Samples (Bool-Gruppen, Gast-Join, states-Mapping).
FunctionalToken-Routen: bearbeiten/{token} lädt vorbefüllt, falsches Token 404/leer (enumeration-safe), Löschpfad entfernt Entity.
Browser (Pflicht vor UI-Done)Formular auf solcom.ddev.site + Staging: Chip-Eingabe frei, Vorschläge sauber (keine ^-Terms), Zähler, Mail-Links via Mailpit.
StatischPHPCS + PHPStan lokal in DDEV vor PR-Open (CI prüft nur auf PR/develop/main).
05

Risiken & Mitigations

Risiko
Sev
Mitigation
Datenqualität der 12.912 Alt-Alerts: Tippfehler, Alt-Suchsyntax (^/=/!), Leerstrings in tags/notags.
HIGH
Migration normalisiert defensiv (trim, dedupe, Syntax-Strip); Fixtures aus echten Samples; Probelauf lokal gegen vollen Dump mit Zahlen-Abgleich vor Staging.
Abgeflachte UND-Gruppen erzeugen mehr Treffer → mehr Mails als im Altsystem für einzelne Abonnenten.
MED
Bewusste Entscheidung (mehr statt weniger); jeder Mail liegt der Token-Edit-Link zum Nachschärfen bei; Pro-Projekt-Dedup verhindert Wiederholungen.
Modul-A-Stilllegung: Staging/Prod könnte echte ppp_alert-Daten haben (lokal nur 2 Testeinträge).
MED
Pflicht-Check via mw app exec vor Uninstall; bei Bestand Mini-Überführung nach B (gleiches Feld-Mapping wie Neos-User-Alerts).
Massen-Versand direkt nach Migration: 12.912 bestätigte Alerts treffen auf den bestehenden Projekt-Bestand.
HIGH
Pro-Projekt-Dedup-Tabelle beim Migrieren für den Ist-Bestand vorbefüllen (alle existierenden project_offer-Nodes als „bereits benachrichtigt" markieren) — Alerts zünden nur für NEUE Projekte nach Cut-over.
06

Offene Punkte

Trefferzähler-Slice halten oder schieben?
Nice-to-have im WP1; wenn Di 07.07. eng wird, fällt er als erstes und wird Post-Go-Live-Follow-up.
Entscheidet · Marc, spätestens 06.07.
Jira-Sub-Task-Zuschnitt
Entwürfe (Backend-Konsolidierung, Migration, Frontend-Slice, Vocab-Hygiene) liegen der Session bei; Posting nach User-Freigabe.
Draft · Claude, Posting · Marc