22-05-2026 Optimierung der User und Admin Panels

dev/frontend/hub-flux/19-PHASE-7-PRESS-RELEASE-FORM.md

@@ -5,7 +5,7 @@
 > Bekommt deshalb eine eigene Phase außerhalb der bisherigen
 > `hub-flux`-Roadmap (Phase 0–6 sind dort abgeschlossen).
 
-**Status**: 🟡 in Planung · **Aufwand**: 2–3 Tage · **Risiko**: mittel
+**Status**: ✅ abgeschlossen · **Aufwand**: 2–3 Tage · **Risiko**: mittel
 (Datenmodell-Erweiterung, Editor-Format-Migration, Composer-Dependency)
 
 ---
@@ -187,25 +187,46 @@ Untertitel, Editor, Medien, Anhänge, Boilerplate.
 - [ ] Reorder-Test
 - [ ] Datei-Type-Validation grün
 
-### 7F — Scheduling + Embargo (Schema vorhanden, UI aktivieren)
+### 7F — Scheduling + Embargo ✅
 
-**Scope:**
-- UI-Elemente aus 7C (Veröffentlichung-RadioGroup,
-  Embargo-Checkbox + Date-Picker) aktivieren
-- `bald`-Badges entfernen
-- Service-Logik in `PressReleaseService`:
-  - bei `submitForReview` mit `scheduled_at` → Status bleibt
-    `review`, beim `publish` durch Admin/Job wird `published_at`
-    auf `scheduled_at` gesetzt
-  - bei `embargo_at` → öffentliche Anzeige erst ab `embargo_at`
-- Background-Job (`PublishScheduledPressReleases`) für die
-  Veröffentlichung um `scheduled_at`
-- Test: Geplante PM wird nicht vor Termin öffentlich
-- Test: Embargo-Filter im Portal-Index
+**Was umgesetzt wurde:**
+- **UI**: Customer Create + Edit haben eine zweite Radio-Option
+  „Geplanter Termin" mit `<flux:input type="datetime-local">` und
+  einen separaten Embargo-Switch + Date-Picker.
+  `bald`-Badge im Veröffentlichungs-Block entfernt.
+- **Validation**: `scheduled_at` muss min. 5 Min in der Zukunft
+  liegen (passend zum Scheduler-Intervall), `embargo_at` muss in
+  der Zukunft liegen. Beide Felder werden nur validiert, wenn der
+  jeweilige Toggle aktiv ist.
+- **Save**: `scheduled_at` + `embargo_at` werden in den Forms bei
+  Create + Update persistiert (Customer Variante; Admin bleibt
+  vorerst ohne UI).
+- **Service**: `PressReleaseService::publish()` nutzt jetzt
+  `resolvePublishedAt()`:
+  1. bereits gesetztes `published_at` bleibt unangetastet
+  2. sonst `scheduled_at` (falls vorhanden)
+  3. `embargo_at` verschiebt zusätzlich nach hinten
+  4. Fallback `now()`
+  Damit greift der vorhandene Sichtbarkeits-Filter
+  `where('published_at', '<=', now())` in `routes/web.php`
+  automatisch — keine zusätzlichen Embargo-Filter nötig.
+- **Background-Command** `press-releases:publish-scheduled`
+  (`App\Console\Commands\PublishScheduledPressReleases`) findet
+  alle Review-PRs mit `scheduled_at <= now`, publisht sie via
+  Service (`source: 'scheduler'` im Status-Log) und respektiert
+  weiterhin Blacklist + Mail-Benachrichtigung. Optionen:
+  `--dry-run`, `--limit=N`.
+- **Scheduler-Eintrag** in `routes/console.php`: alle 5 Min,
+  `withoutOverlapping()`, `runInBackground()`.
 
-**Hinweis:** 7F ist optional und kann nach 7C/D/E in eine eigene
-kleine Sub-Phase ausgelagert werden, weil es einen Background-Job
-einführt und der Test-Umfang separat sauber bleibt.
+**Tests:**
+- `tests/Feature/PressReleaseSchedulingTest.php` — 11 Tests für
+  Service + Command (resolvePublishedAt-Matrix, Source-Log,
+  Command-Dry-Run, Command-Limit).
+- `tests/Feature/CustomerPressReleaseSchedulingFormTest.php` —
+  5 Tests für die Form (Persistierung, Past-Date-Validation für
+  beide Felder, Now-Mode setzt scheduled_at zurück,
+  Edit-Hydration).
 
 ---