WS-5: Buchungs-Gate launch-ready – proaktiver Dashboard-Hinweis

Das Abo-/Bestandsschutz-Gate (User::hasActiveBooking, BookingRequiredException,
Submit-Modal, API 402/422) war bereits implementiert und getestet. Ergänzt wird
die proaktive Block-UX:

- Kunden-Dashboard zeigt bei scharfem Gate (billing.enforce_booking=true) und
  fehlender aktiver Buchung einen Banner "Buchung erforderlich, um zu
  veröffentlichen" mit Link zur Buchungsseite. Bestandskunden (grandfathered)
  sehen den Hinweis nicht; bei offenem Gate bleibt er unsichtbar.
- Tests: Banner aus (Gate offen) / an (Gate scharf, keine Buchung) /
  Ausnahme für grandfathered.

Launch-Flip bleibt env-gesteuert (BILLING_ENFORCE_BOOKING), Dev-Default false –
.env.example und Detailplan (WS-5 ) dokumentieren den Schalter.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Kevin Adametz 2026-06-16 16:37:16 +00:00
parent afefa86711
commit a0547208d3
4 changed files with 94 additions and 4 deletions

View file

@ -92,11 +92,16 @@ Alle hinter WS-2 **oder** regulärem Login.
- **Tests:** gemeinsame Abrechnung zweier Posten; portalübergreifende Geltung; Worker erzeugt Rechnung zum Periodenende.
- **Aufwand:** ~23 Tage. Parallel zu WS-1/2 möglich.
### WS-5 — Abo-/Bestandsschutz-Gate scharf schalten (Merkliste 6)
### WS-5 — Abo-/Bestandsschutz-Gate scharf schalten (Merkliste 6) — ✅ erledigt 16.06.2026
**Scope:** „User ohne aktives Abo oder Bestandsschutz dürfen keine PM schreiben."
- Mechanik existiert (`hasActiveBooking()` inkl. `grandfathered`, `BookingRequiredException`). Nötig: `billing.enforce_booking` für Launch auf `true`, Block-UX prüfen, Bestandsschutz-Fall absichern.
- **Tests:** User ohne Buchung → blockiert; grandfathered → erlaubt; aktives Abo → erlaubt.
- **Aufwand:**1 Tag. **Abhängigkeit:** WS-4.
- Mechanik existiert (`hasActiveBooking()` inkl. `grandfathered`, `BookingRequiredException`) und ist mit `enforce_booking=true` voll getestet:
- **Backend-Gate:** `PressReleaseService::submitForReview()` wirft `BookingRequiredException`/`QuotaExceededException`.
- **API:** `POST /api/v1/press-releases/{id}/submit``402` (keine Buchung) bzw. `422` (Kontingent erschöpft).
- **Block-UX am Einreichpunkt:** `press-release-submit-modal.blade.php` zeigt ohne Buchung statt des Prüf-Flows den Hinweis „Buchung erforderlich" + Button zur Buchungsseite; alle Volt-Caller (show/edit/create/index) fangen die Exceptions und zeigen einen Toast.
- **Proaktiver Hinweis:** Kunden-Dashboard zeigt bei scharfem Gate ohne aktive Buchung einen Banner „Buchung erforderlich, um zu veröffentlichen" → `me.bookings.index`. Bestandskunden (grandfathered) sehen ihn nicht.
- **Launch-Flip:** Kein Code-Default ändern — der Schalter bleibt in `config/billing.php` auf `false` (Dev-Default). Scharfschalten ausschließlich per Prod-Env `BILLING_ENFORCE_BOOKING=true` (→ WS-7-Checkliste).
- **Tests:** `HasActiveBookingTest`, `PressReleaseSubmitApiTest` (402/422), `DashboardTest` (Banner an/aus + grandfathered-Ausnahme), `LegacyBundleTest` (grandfathered zählt portalübergreifend).
- **Aufwand:** erledigt. **Abhängigkeit:** WS-4 (erledigt).
### WS-6 — Login/Registrierung: Flow + E-Mail-Verifizierung + Google-Login (Merkliste 7 + Zweig 3)
**Scope nach Entscheidung 2 & 3:**