Phase 4J — Dashboard-PM-Listen mit 4H/4I-Patterns

Mini-Folgepäckchen: Die in 4H/4I entwickelten Mockup-Patterns (Portal-Pills, Status-Sub-Zeilen, Inline-Actions) werden auf die kompakten PM-Listen in den Dashboards übertragen.

Status: ✅ abgeschlossen · Aufwand: ~30 min · Risiko: niedrig

Anlass

Nach 4H/4I sehen die Voll-Listen exakt wie das Mockup aus — die Dashboard-Listen ("Meine letzten Pressemitteilungen", "Letzte Pressemitteilungen", "Zur Prüfung") sind aber noch auf dem alten Stand (Badge rechts, Sub-Zeile ohne Portal). Das wirkt inkonsistent.

Scope

Customer-Dashboard (Volt `customer/dashboard.blade.php`)

Volt-Component: recent lädt aktuell ['id', 'title', 'status', 'company_id', 'created_at']. → portal ergänzen.
Markup recent-Liste:
- Portal-Pills (presseecho/businessportal24) neben dem Badge
- Sub-Zeile mit PM-ID + Firma + Datum (statt nur Firma + Datum)

Admin-Dashboard (Controller-View `admin/dashboard.blade.php`)

recentPRs-Liste:
- Portal-Pills neben dem Badge
- Sub-Zeile mit PM-ID + Firma + User + Datum
pendingReviews-Liste:
- Portal-Pills neben Titel
- Inline-Action „Prüfen →" als Link zur Show-Page (im Dashboard keine direkte publish/reject-Methode möglich, da Controller+Blade statt Volt)

Was bleibt unangetastet

Backend-Logik (Controller, Volt-with())
Customer-Tests (DashboardTest) — die geprüften Strings („Phase 2 Demo Release", „Alle anzeigen", „Meine letzten Pressemitteilungen", …) bleiben
Quick-Actions, Newsletter, Brand-Bridge — bereits gut

Akzeptanzkriterien

Plan
Customer-Volt: portal + published_at in Recent-Select-Liste
Customer-Dashboard: Portal-Pills + PM-ID-Sub + published_at als Primärdatum bei Published
Admin-Dashboard recentPRs: Portal-Pills + PM-ID-Sub, badgeClass mit muted-Variante (statt hub für archived/draft)
Admin-Dashboard pendingReviews: Portal-Pills + Inline-Action „Prüfen →" + is-row-warn Tinting
Build + Pint + Tests grün (5/5 Dashboard, 230/231 voll)
PROGRESS.md + 03-WEITERE-PHASEN.md aktualisiert

2.2 KiB Raw Blame History