gitmedia/presseportale
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
presseportale/dev/migration 2026/12-NAECHSTE-SCHRITTE.md
Kevin Adametz 0a3e52d603 19-05-2026 Rebrand Pressekonto, Hub-Flux UI und Legacy-Media-Migration 
Umbenennung presseportale → pressekonto in Domains, Themes und Dokumentation.
Design-Tokens, Portal-Shell, Customer-Dashboard, Auth- und Admin-PM-Views.
Artisan-Befehl migrate:legacy-media mit Tests und Hub-Flux-Entwicklungsdocs.

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-05-19 16:36:13 +00:00

15 KiB
Raw Blame History

12 – Nächste Schritte (Roadmap)

Stand: 2026-05-04 Quellen: 03-MIGRATION-PLAN.md, 08-PROGRESS.md, 11-NOCH-ZU-TUN-OPTIMIERUNGEN.md, 09-REVIEW-QUALITAET.md

Dieses Dokument bündelt alles, was laut Entwicklungsplan noch offen ist, in einer einzigen Übersicht – nach Priorität und Phase sortiert. Stand der Test-Suite: 180 Tests grün, 3 geskippt, 0 Fehler.

Legende: 🔴 hoch · 🟡 mittel · 🟢 niedrig · ⏸️ vertagt · ⬜ offen · 🔄 in Arbeit

1. Schnell-Status

Was ist fertig

  • Phase 0 – Vorbereitung (bis auf Stripe-Daten vom Auftraggeber)
  • Phase 1 – Fundament (Schema, Models, Factories, Seeder, Migrations grün)
  • Phase 2 – Auth & Tenancy (Magic-Link, Portal-Scope, Portal-Switcher, Roll-Aware-Login-Redirect)
  • Phase 3 – Admin-UI (Press Releases, Categories, Footer-Codes, Companies, Contacts, Users, Roles alle real angebunden)
  • Phase 4 – Customer-Portal (jetzt als „Mein Bereich" unter /admin/me/* ins Admin-Panel konsolidiert)
  • Phase 5 (teilweise) – PressReleaseService inkl. Reject-Reason + Audit-Log, BlacklistService, ImageService, HasUniqueSlug-Trait
  • Phase 6 – Daten-Migration: Kern komplett (Users/Companies/Contacts/PMs/Bilder, idempotent, Bilder-Sync); Legacy-Rechnungen brauchen einen Vollimport-Nachziehschritt
  • Phase 7 – API v1 vollständig (Endpunkte, Sanctum, Rate-Limit, OpenAPI, Tests, Legacy-Cut, Kundenreport)

Was steht als Nächstes an

  1. Externe Abhängigkeit klären (siehe §2): Stripe-Keys + Grandfathering-Kriterien vom Auftraggeber.
  2. Legacy-Rechnungen vollständig importieren (siehe §8): DB-Struktur prüfen/erweitern, Import-Skript finalisieren, Status + User-Zuordnung erhalten, PDF-Erzeugung aus Legacy-Daten beim Abruf.
  3. PM-Veröffentlichung abrunden: Inline-Edit durch Admin, Bulk-Aktionen, In-App-Notifications (Bell-Icon).
  4. Newsletter wieder aufnehmen (P3.7 + P5.3 – aktuell vertagt).
  5. Phase 8 (Stripe-Billing) als größter Brocken – sobald Stripe-Daten da sind.
  6. Phase 10 (Härtung) + 11 (Deployment) – Security-Review, Coverage-Ziel, Staging-Rehearsal, DNS-Cutover.

2. Externe Blocker (Auftraggeber liefert)

Diese Punkte können wir nicht selbst anstoßen – ohne sie blockt P8 und teilweise P11.

# Aufgabe Plan-Ref Wirkung
⬜ 0.5 Stripe-Test-Account + API-Keys 03-MP §0 P8 komplett blockiert
⬜ 0.6 Liste der neuen Stripe-Produkte (Preisliste) 03-MP §0 P8.2 blockiert
⬜ 0.7 Liste der aktiven Alt-Abos (oder Kriterien) für Grandfathering 03-MP §0 P6.6 + P8.8 blockiert
⬜ 11.4 Finale Texte fürs Go-Live-Mailing (Passwort-Reset/Sicherheitshinweis) 03-MP §11 Versand am Go-Live blockiert; Command + Mailable selbst sind fertig
⬜ 11.5 Freigabeliste + operative Mailtexte für API-Kunden-Migration 03-MP §11 Versand blockiert; Kundenreport selbst ist fertig

Empfehlung: Diese fünf Punkte als kompakte Mail/Liste an den Auftraggeber – ohne sie kann der Go-Live-Pfad nicht abgeschlossen werden.

3. Pressemitteilungs-Block: Nice-to-Have-Erweiterungen

Der Kern (Erstellen → Submit → Review → Publish/Reject mit Reason + Audit-Log) ist fertig. Diese Erweiterungen würden den Workflow noch runder machen:

# Aufgabe Priorität Aufwand
⬜ pm-x1 Inline-Edit + „Speichern & Veröffentlichen" auf einer Seite im Admin – heute zwei separate Schritte 🟡 0.25 d
⬜ pm-x2 Bulk-Aktionen im Admin-Index: mehrere PMs auf einmal Veröffentlichen/Ablehnen (mit gemeinsamer Begründung) 🟡 0.5 d
⬜ pm-x3 In-App-Notifications (Bell-Icon in der Sidebar) für Customer: „PM veröffentlicht/abgelehnt" – ergänzt heutige Mail 🟡 0.5–1 d
⬜ pm-x4 Permission-Granularität: press-releases:review (lesen + freigeben) vs. press-releases:publish (final veröffentlichen) trennen, falls Editor nicht direkt veröffentlichen soll 🟢 0.25 d

4. Phase 1 – Restarbeiten

# Aufgabe Priorität Status
1.8 DefaultAdminUserSeeder + SalutationTranslationSeeder ergänzen 🟢 🔄
1.10 Zentrale Factory-Smoke-Suite (alle Factories erzeugen valide Models) 🟢 🔄

5. Phase 3 – Admin-UI: Restarbeiten

# Bereich Aufgabe Priorität Status
3.7 Newsletter Subscriber-Liste + CSV Im-/Export 🟡 ⏸️ vertagt 2026-05-04
3.8 Invoices (neu) Liste, Detail, Stripe-Status, PDF-Download 🔴 ⬜ wartet auf P8
3.9 Legacy-Invoices Admin Admin-Spiegel zur Customer-Sicht finalisieren 🟡 ✅ Übersicht mit Filtern, Mapping-Hinweisen und PDF-Download umgesetzt; Navigation heißt Legacy Rechnungen
3.10 Payments Liste + Detail 🔴 ⬜ wartet auf P8

6. Phase 4 – Customer-Portal: Restarbeiten

# Aufgabe Priorität Status
4.2 Customer-Dashboard: aktive Abos + offene neue Rechnungen 🟡 🔄 wartet auf P8
4.4 Neue Rechnungen einsehen & PDF-Download 🔴 🔄 wartet auf P8

7. Phase 5 – Domain-Services: Restarbeiten

# Aufgabe Priorität Status
5.3 NewsletterService neu (Subscribe / Confirm / Unsubscribe mit Token) 🟡 ⏸️ vertagt 2026-05-04
5.4 CompanyService (Aktivierung, Logo-Upload, Footer-Code-Management) 🟡 ⬜
5.7 Domain-Events + Listeners (PressReleasePublished → SendPublishNotification etc.) 🟢 🔄 nur Mailables, keine echten Events
5.8 Vollständige Service-Test-Suite (Coverage > 70 %) 🟡 🔄

Hinweis: ImageService (5.5) hat noch einen offenen Restpunkt: Legacy-Thumbnail-Redirect – kein Blocker, aber nice für SEO-Kontinuität alter Bild-URLs.

8. Phase 6 – Daten-Migration: Restarbeiten

# Aufgabe Priorität Status
6.5d Legacy-Rechnungen Vollimport: alle bestehenden Rechnungen aus den Legacy-DBs inkl. Status, Beträgen, Datum, Zahlart, vollständigem Raw-Snapshot und User-Zuordnung importieren; legacy:archive-invoices schreibt Import-Report + PDF-Payload; PDF-Erzeugung bleibt DB-basiert/on-demand statt Datei-Migration 🔴 ✅ umgesetzt 2026-05-04; Rehearsal gegen Produktiv-Snapshot bleibt P6.10
6.6 legacy:grandfather-subscriptions (aktive Alt-Abos übernehmen) 🔴 ⬜ wartet auf Auftraggeber-Kriterien
6.10 Rehearsal-Lauf gegen produktiven Snapshot auf Staging 🔴 ⬜

Wichtig für 6.5d: legacy:archive-invoices importiert jetzt Rechnungsdaten, Billing-Adress-Snapshot und User-Payment-Snapshot in legacy_invoices.raw_snapshot/pdf_payload, zählt unzugeordnete Legacy-User im Report und lässt diese Rechnungen trotzdem im Archiv. Für Legacy-Rechnungen bleibt die bestehende Logik erhalten: Rechnung liegt als Datenbankdatensatz vor und das PDF wird bei Bedarf auf Knopfdruck aus diesen Daten erzeugt. Neue Stripe-Rechnungen werden separat in P8 geplant. Der finale Nachweis der Vollständigkeit erfolgt weiterhin im Staging-Rehearsal mit aktuellem Produktiv-Snapshot.

9. Phase 8 – Stripe-Billing (komplett offen, größter Brocken)

Hängt komplett an §2 (Stripe-Account + Produktliste).

# Aufgabe Priorität Aufwand
8.1 Stripe-Setup (.env, Cashier vs. raw stripe-php) 🔴 0.25 d
8.2 PaymentOption-Admin + Sync zu Stripe Products/Prices (stripe:sync-products) 🔴 0.5 d
8.3 Checkout-Flow im Customer-Portal (Stripe Checkout Session + Rückkehr-URL) 🔴 0.5 d
8.4 Webhook-Controller /webhooks/stripe + Event-Handler (checkout-session-completed, invoice-paid, invoice-payment-failed, subscription-deleted) 🔴 0.5 d
8.5 InvoiceNumberGenerator ({YYYY}{MM}-{seq}) 🟡 0.25 d
8.6 PDF-Blade + InvoiceService 🟡 0.25 d
8.7 Mahnwesen vereinfacht (invoices:remind für Stripe-Fails) 🟡 0.25 d
8.8 Grandfathering-Handler (ExpireGrandfatheredSubscriptions-Scheduler + Customer-Mail) 🔴 0.25 d
8.9 Legacy-Rechnungen Archiv-UI im Admin finalisieren + DB-basierte Legacy-PDF-Erzeugung absichern 🟡 ✅
8.10 Tests mit Stripe-Test-Mode (Fake-Webhooks) 🔴 0.25 d

Gesamt P8: ~2.5–3 Manntage netto, sobald Stripe-Daten vorliegen.

10. Phase 9 – Scheduler & Queues

# Aufgabe Priorität Status
9.1 Supervisor/Queue-Worker-Setup dokumentieren (Dev + Prod) 🟡 ⬜
9.2 Cron-Jobs für invoices:remind, grandfather:expire, newsletter:campaign-digest (optional) ergänzen 🟡 🔄 (magic-links:purge + press-releases:purge-drafts da, P8/P5-Jobs fehlen)
9.3 Failure-Alerting (Log-Channel + Mail bei fehlgeschlagenen Jobs) 🟡 ⬜

11. Phase 10 – Testing & Härtung

# Aufgabe Priorität Status
10.1 Coverage-Ziel 70 % auf app/Services und app/Actions 🔴 ⬜
10.2 Architecture-Tests (Pest arch()) – z. B. „kein Volt-Volt darf direkt Mail::send aufrufen" 🟡 ⬜
10.3 php artisan test --parallel grün 🟡 ⬜
10.4 Manuelle QA-Checkliste durchgehen (siehe 06-FEATURES-SCOPE.md §15) 🔴 ⬜
10.5 Security-Review: CSRF, CORS, Rate-Limits, File-Uploads, Magic-Link-TTL 🔴 ⬜

12. Phase 11 – Deployment

# Aufgabe Priorität Status
11.1 Produktiv-DB-Server provisionieren + Backups konfigurieren 🔴 ⬜
11.2 Staging-Deployment + Smoke-Tests 🔴 ⬜
11.3 Produktiv-Import-Rehearsal gegen aktuellen Legacy-Snapshot 🔴 ⬜
11.4 Go-Live-Mailing (Passwort-Reset + Sicherheitshinweis) versenden 🔴 🔄 (Code fertig, Texte/Versand offen)
11.5 API-Kunden-Kommunikation (Token-Migration) versenden 🔴 🔄 (Report fertig, Texte/Versand offen)
11.6 DNS-Cutover-Plan: pressekonto.de auf neuen Server 🔴 ⬜
11.7 Read-Only-Modus auf Legacy-Systemen während Final-Import 🔴 ⬜
11.8 Abschalten der alten Symfony-Server (nach Review-Periode) 🟡 ⬜

13. Performance-Optimierungen (aus 11-NOCH-ZU-TUN)

Nicht zwingend für Go-Live nötig, aber fürs Polishing:

# Aufgabe Priorität Quelle
⬜ opt-1 Slow-Admin-Reports mit echten Daten füllen + auswerten 🔴 11-NOCH §1
⬜ opt-2 EXPLAIN auf Top-Slow-Queries laufen lassen, Indexe nachziehen 🔴 11-NOCH §2
⬜ opt-3 admin.users.edit aufteilen (Profil-Partial → BillingAddress-Partial → Volt-Komponente company-links → Volt-Komponente contact-links) 🟡 11-NOCH §3.1
⬜ opt-4 admin.companies.show – Kontakte-Tab als eigene Volt-Komponente isolieren 🟡 11-NOCH §4
⬜ opt-5 Listen weiter splitten (nur bei messbarer Langsamkeit, nicht prophylaktisch) 🟢 11-NOCH §5
⬜ opt-6 Billing-Dummy-Views durch echte Implementierung ersetzen 🔴 11-NOCH §6 (= P3.8/3.10/3.11 in P8)
⬜ opt-7 Rollen-Index nur bei Bedarf optimieren (Pagination/Cache) 🟢 11-NOCH §7
⬜ opt-8 Slow-Requests zusätzlich in DB persistieren (Trends über Releases) 🟢 11-NOCH §8
⬜ opt-9 Report-UI erweitern (CSV-Export, Zeitraum-Schnellfilter, Vergleichsmodi) 🟢 11-NOCH §9

14. Restpunkte aus dem Qualitätsreview (09-REVIEW)

Die kritischen Punkte aus §2 sind durchgängig behoben. Aus §3/§4 stehen noch aus:

# Aufgabe Priorität Quelle
⬜ rev-1 gdpr_consent_at im Registrierungsflow befüllen 🔴 09-REVIEW §3 / §4.6
⬜ rev-2 UserManagementTest.php (820 Zeilen) in tests/Feature/Admin/UserCrudTest.php, CompanyCrudTest.php, ContactCrudTest.php, FilterPresetTest.php aufteilen 🟡 09-REVIEW §3.5
⬜ rev-3 session()->flash() in inline Volt-Aktionen (ohne Redirect) durch $this->dispatch('notify', ...) ersetzen 🟡 09-REVIEW §3.6
⬜ rev-4 04-DATA-MODEL.md um contact_user-Pivot ergänzen (Doku-Lücke) 🟢 09-REVIEW §3.4
⬜ rev-5 Drei user_filter_presets-Migrations zu einer zusammenführen (Hygiene vor Go-Live) 🟢 09-REVIEW §3.2
⬜ rev-6 ENUM → VARCHAR mit Enum-Cast prüfen, falls beim Rehearsal Lock-Probleme auf großen Tabellen auftreten 🟢 09-REVIEW §3.7

15. Empfohlene Reihenfolge der nächsten Sessions

Folgende Tranchen-Reihenfolge priorisiert das Erreichen der Produktionsreife:

Tranche A – Legacy-Rechnungen Vollimport ✅ erledigt 2026-05-04

  1. P6.5d Source-Audit: Legacy-Rechnungstabellen, Statuswerte, benötigte PDF-Daten und User-Mapping geprüft
  2. legacy:archive-invoices zu vollständigem, idempotentem Import-/Report-Skript ausgebaut
  3. DB-Vorbereitung mit pdf_payload + pdf_generated_at nachgezogen
  4. Customer-PDF-Abruf auf DB-basierte Legacy-PDF-Erzeugung abgesichert

Tranche B – PM-Block abrunden (~1 Tag, sofort möglich)

  1. pm-x1 Inline-Edit + „Speichern & Veröffentlichen" im Admin
  2. pm-x2 Bulk-Aktionen im Admin-Index
  3. pm-x3 In-App-Notifications (Bell-Icon)
  4. rev-1 gdpr_consent_at im Registrierungsflow (DSGVO)

Tranche C – Newsletter-Wiederaufnahme (~1 Tag)

  1. P5.3 NewsletterService (Subscribe/Confirm/Unsubscribe mit Token)
  2. P3.7 Admin-Newsletter-UI (Subscriber-Liste + CSV)

Tranche D – Service-Härtung & Test-Coverage (~1 Tag)

  1. P5.4 CompanyService
  2. P5.7 Domain-Events einführen
  3. P10.1 Coverage auf 70 % heben
  4. P10.2 arch()-Tests

Tranche E – Performance-Polishing (~0.5 Tage, optional)

  1. opt-1 + opt-2 Echte Slow-Reports auswerten + EXPLAIN
  2. opt-3 admin.users.edit aufteilen

Tranche F – Wartet auf Auftraggeber: P8 Stripe (~2.5–3 Tage)

  1. Sobald Stripe-Daten vorliegen: P8 komplett (8.1 – 8.10)
  2. P3.8 + P3.10 (Invoices/Payments-Admin echt anbinden)
  3. P4.2 + P4.4 (Customer-Dashboard + neue Rechnungen)

Tranche G – Phase 9 + 10 + 11 (~2–3 Tage)

  1. P9.1 – 9.3 Queue/Scheduler/Alerting
  2. P10.4 + 10.5 QA-Checkliste + Security-Review
  3. P11.1 – 11.3 Staging-Deployment + Rehearsal
  4. P11.4 + 11.5 Mailings versenden
  5. P11.6 – 11.8 DNS-Cutover + Legacy-Read-Only + Abschaltung

16. Aufwandsschätzung Rest

Block Aufwand Abhängigkeiten
Tranche A (Legacy-Rechnungen Vollimport) ✅ erledigt Produktiv-Snapshot-Rehearsal bleibt P6.10
Tranche B (PM-Polishing) ~1 d –
Tranche C (Newsletter) ~1 d –
Tranche D (Service-Härtung) ~1 d –
Tranche E (Performance) ~0.5 d –
Tranche F (Stripe + Billing) ~3 d Stripe-Daten ⬜
Tranche G (Deployment) ~2.5 d Tranche F + Auftraggeber-Texte
Σ Restaufwand ~9.5–10 Manntage –

Der Endspurt zum Go-Live (Tranche F + G) ist davon ~5.5 Tage und hängt komplett am Auftraggeber-Input.

17. Zusammenfassung: Was kann heute ohne externen Input passieren?

  • Tranche B (PM-Polishing) – 1 Tag
  • Tranche C (Newsletter) – 1 Tag
  • Tranche D (Service-Härtung & Tests) – 1 Tag
  • Tranche E (Performance-Polishing) – 0.5 Tage
  • Restpunkte aus §14 (Quality-Review-Cleanup) – 0.5 Tage

= ~4 Manntage produktive Arbeit, bevor wir auf Stripe-/Go-Live-Daten vom Auftraggeber warten müssen.