presseportale/docs/user-admin/Admin-User.md

# User Backend und Admin Backend

> **Stand der Doku**: 11.06.2026 — Phase 1, Phase 7 (PM-Form-Refactor), Phase 8 (User-Panel-Konsolidierung) und die KI-Pruef-Pipeline (Klassifikation + Content-Score) sind abgeschlossen.
> Aktueller Code-vs-Konzept-Abgleich: [`docs/STATUS-ABGLEICH-USER-PANEL.md`](../STATUS-ABGLEICH-USER-PANEL.md).
> Naechster Block (Zahlung/Tarife, Veroeffentlichungs-Flow): [`docs/Decision-Update Preisstruktur & Veröffentlichungs-Flow.md`](../Decision-Update%20Preisstruktur%20&%20Ver%C3%B6ffentlichungs-Flow.md).

Dieses Konzept beschreibt das gemeinsame Backend aus zwei Perspektiven:

- **User Backend**: Self-Service-Bereich für Kunden/User zur Pflege eigener Firmen, Kontakte, Pressemitteilungen, Rechnungen, API-Tokens und Einstellungen. „Pressemappe" bleibt als öffentlicher/PR-bezogener Kontext erhalten, nicht als Hauptnavigation im User Backend.
- **Admin Backend**: Verwaltungsbereich für interne Admins/Editoren. Die bestehende Admin-Oberfläche bleibt in Phase 1 unverändert.

Beide Bereiche laufen technisch im gleichen Backend. Die sichtbaren Menüs, Aktionen und Daten werden über Rollen, Policies und Berechtigungen getrennt. Admins können sich über Impersonation als User einloggen, um dessen User-Backend-Sicht nachzuvollziehen und Inhalte zu prüfen oder zu korrigieren.

> Hinweis Routen-Namen: In der UI heißen die Firmen ueberall „Firmen". Aus
> historischen Gruenden tragen die zugehoerigen Routen weiterhin den
> Praefix `me.press-kits.*` (z. B. `me.press-kits.show`). Das ist nur
> ein Routen-Name, fachlich sind es Firmen. Eine Umbenennung der Routen
> ist nicht geplant, weil sie nur intern relevant ist.

Vorab siehe hierzu folgende Mechanik für Untermenüs https://pressekonto.test/settings/profile

# Aktualisierte Navigation

## Phasen-Farbcode

Für die weitere Planung werden Features farblich/phasenbasiert getrennt:

- **Grün / Phase 1**: auf dem bestehenden Datenmodell kurzfristig umsetzbar.
- **Gelb / Phase 2**: braucht kleinere neue Tabellen, Policies oder Services.
- **Rot / Später**: strategische Produkt-/Monetarisierungsthemen mit größerem Datenmodell- oder Rechtsaufwand.

## Umsetzungsstand Phase 1

Bereits umgesetzt:

- Firmen-Kontext-Switcher im User Backend mit „Alle Firmen" und Einzelfirma, platziert rechts in der Topbar.
- User-Backend-Navigation gegliedert in „Mein Bereich", „Finanzen" und „Konto".
- „Buchungen & Add-ons" ist als vorbereiteter Bereich eingebunden; Statistiken, Credits/Tarif, Zahlungsarten und Benachrichtigungen bleiben markierte spätere Punkte.
- Dashboard und PM-Liste reagieren auf den aktiven Firmen-Kontext.
- Firmen-Liste und Firmen-Detail auf Basis der bestehenden `companies`, `contacts` und `press_releases`.
- Zugriff auf Firmen ist auf eigene bzw. zugeordnete Firmen begrenzt.
- Öffnen einer Firma setzt die aktive Firma für den weiteren User-Backend-Kontext.
- Kontaktverwaltung innerhalb der Firma für Owner und Verantwortliche; Mitglieder bleiben lesend.
- Neue Pressemitteilungen übernehmen die aktive Firma als Vorauswahl.
- PM-Detail zeigt zugeordnete Pressekontakte sowie Status-/Verlaufsdaten.
- Rechnungen sind im User Backend in einer eigenen Finanznavigation eingeordnet; Legacy bleibt als Archivhinweis im Inhalt sichtbar.
- Rechnungen zeigen einen Hinweisblock; Rechnungsadresse wird im Profil als eigener Bereich gepflegt.
- Firmen-Stammdaten werden sichtbar in der Firma gepflegt; die Profilseite verweist nur noch auf die jeweilige Firma.
- Dashboard zeigt erste Datenqualitäts-Hinweise aus bestehenden Tabellen: Profil, Rechnungsadresse, Pressekontakte und Legacy-PMs ohne Firma.

Noch offen in Phase 1:

- Keine offenen Punkte aus der ersten grünen User-Backend-Ausbaustufe.

## Umsetzungsstand Phase 7 (PM-Form-Refactor)

Phase 7 ist mit Stand 21.05.2026 abgeschlossen. Sie hat das Form-Erlebnis für Pressemitteilungen vereinheitlicht und das Datenmodell um mehrere Felder erweitert. Details: `dev/frontend/hub-flux/19-PHASE-7-PRESS-RELEASE-FORM.md`.

Zusammenfassung:

- **Neue PM-Felder**: `subtitle`, `scheduled_at`, `embargo_at`, `boilerplate_override`, `no_export`. Migrationen liegen in `database/migrations/2026_05_20_*`.
- **HTML-Sanitizer**: Inhalt wird serverseitig durch `mews/purifier` gereinigt (`App\Services\PressRelease\PressReleaseHtmlSanitizer`).
- **Sidebar-Aufbau** in Customer- und Admin-Forms identisch (Status & Absenden, Kategorie, Portal-Pill, Pressekontakt, Themen-Tags, Veröffentlichung, Weitere Felder, Phase-2-Footer).
- **Pressekontakt-Pflichtfeld** aufgehoben — Auswahl bleibt empfohlen, ist aber technisch nullable. Eine Warn-Box im Sidebar-Card (Phase 8) macht das transparent.
- **Anhänge-/Downloads-UI deaktiviert** wegen ausstehendem Security-Review. Tabelle `press_release_attachments` und Manager-Komponente bleiben erhalten.
- **Background-Job** `php artisan press-releases:publish-scheduled` veröffentlicht geplante PMs (alle 5 Minuten via Scheduler).
- **UX**: `Flux::toast()` für alle Erfolg/Fehler-Meldungen, Smooth-Scroll zum ersten Validation-Fehler nach Save, `presubmitChecks` als kompakte Pflichtfeld-Übersicht im Sidebar.

## Phase 8 (abgeschlossen 29.05.2026)

Plan-Doku: `docs/PHASE-8-USER-PANEL-PLAN.md`. Schwerpunkte:

1. ✅ Show-Page-Lücken aus Phase 7 schließen (Subtitle, Scheduling, Embargo, Boilerplate-Override) — Customer + Admin (8A).
2. ✅ Listen-Indikatoren für geplante Veröffentlichung und Embargo (8B).
3. ✅ Pressekontakt-Warn-Box in der Form-Sidebar, wenn kein Kontakt gewählt (8C).
4. ✅ Firmen-Liste auf Mockup-Niveau (Counter-Strip, Saved-Views, Filter-Chips, Card/List-Toggle, Rollen-Legende) (8E).
5. ✅ SVG-Platzhalter-Set für PM-Titelbilder + Auswahl-Modal + Cover-Resolver (8F/8G).
6. ✅ Image-Manager mit Lizenz-Pflichtfeldern (Urheber/Lizenztyp/Lizenz-URL/Rechte-Bestätigung) (8H).
7. ✅ Veröffentlichungs-Modal mit rechtlichen Hinweisen und Kontingent-Stub (8I/8J; das echte Tarif-System kommt später).

## KI-Prüfung & Veröffentlichung (abgeschlossen 11.06.2026)

Detail-Doku: `Entwicklungsplan KI-Pruefung und Veroeffentlichung.md`. Kurzfassung:

- Jede Einreichung (Customer-Form **und** API) läuft durch denselben Funnel: Blacklist-Hard-Filter → asynchrone KI-Klassifikation (Rot/Gelb/Grün, OpenAI mit deterministischem Fallback) → Status-Routing.
- Rot → abgelehnt + Begründung per Mail; Gelb → manuelle Admin-Review-Queue; Grün → Auto-Publish (sofort oder zum geplanten Termin).
- Jede KI-Entscheidung wird in `ki_audits` protokolliert; Admin sieht Badge, Begründung und kann nach Klassifikation filtern. On-Demand-Prüfung über den „Prüfung"-Button im Admin-Editor.
- Zusätzlich Content-Score 0–100 → Stufe Standard/Geprüft/Hochwertig mit Editor-Panel und Badges.
- Parallel umgesetzt (10./11.06.): ein Titelbild pro PM (Cover 1280×580), erweitertes Lizenz-/Rechteformular, Termine in Europe/Berlin (Speicherung UTC), Embargo aus der Form-UI entfernt — siehe `Umsetzung Pressemitteilung Bearbeitung Titelbild Veroeffentlichung.md`.

## Topbar

Oben rechts über dem Content:

**Firmen-Kontext-Switcher** Dropdown „Aktive Firma: [bma.cc ▼]" mit drei Optionen. Vorteil: Die Sidebar bleibt schlank und einklappbar, ohne den aktiven Firmenkontext zu verlieren.

- Einzelne Firma wählen → filtert Dashboard, PMs, Kontakte, Statistiken auf diese Firma
- „Alle Firmen" → aggregierte Sicht
- „Firma anlegen" am Ende der Liste

Da die User-Firmen-Beziehung n:m mit Rollen ist (`member`, `responsible`, `owner`), zeige ich pro Eintrag ein dezentes Rollen-Icon. Das hilft dem User zu verstehen, wo er was darf.

Wichtig: Da das Portal über die Firma abgeleitet wird, ist der Switcher implizit auch der Portal-Switcher. Sauber gelöst, ohne zweites Konzept.

---

## Hauptnavigation (überarbeitet)

### Gruppe „Mein Bereich"

**1. Dashboard** Zusätzlich zu vorher genannten Elementen jetzt mit **Datenqualitäts-Hinweisen**, weil das Datenmodell zeigt, dass viele Pflichtfelder optional sind:

- „Rechnungsadresse fehlt – Rechnungen können nicht erstellt werden"
- „3 Pressemitteilungen ohne Firmenzuordnung (Legacy)"
- „Profil unvollständig – ergänzen für Verifizierung"

Diese Hinweise sind dismissible und verschwinden bei Erledigung. Das senkt deinen Support-Aufwand erheblich, weil User ihre eigenen Datenlücken sehen.

Phase: **Grün**, wenn die Hinweise auf vorhandene Tabellen beschränkt bleiben (`profile`, `billing_addresses`, `company_user`, `companies`, `press_releases`).

**2. Pressemitteilungen** Erweiterungen aus dem Datenmodell:

- **PM-Detailansicht** zeigt einen „Status & Verlauf"-Block (aus `press_release_status_logs` mit Status-Wechseln, Grund, Quelle, Zeitpunkt) — als Card auf der Show-Page, nicht als eigener Tab.
- Filter „PMs ohne Firma" (für Legacy-Migration)
- Filter „PMs mit Portalabweichung" (falls du das den Usern zeigen willst – ich würde es eher in den Admin-Bereich legen)
- **Filter-Presets** (aus `user_filter_presets`): User kann seine eigenen Filter speichern, „Meine Entwürfe der letzten 30 Tage" etc.
- In der PM-Detail: zugeordnete `press_release_contact`-Kontakte als eigene Sektion

Stand 21.05.2026:

- **PM-Felder** umfassen jetzt zusaetzlich `subtitle`, `scheduled_at`, `embargo_at`, `boilerplate_override`, `no_export` (Phase 7).
- **Editor** ist `flux:editor` mit Absaetzen, fett, kursiv, Listen, Zitat, Links und Headings. Der Inhalt wird beim Speichern serverseitig durch HTMLPurifier (`mews/purifier`, gekapselt in `PressReleaseHtmlSanitizer`) bereinigt.
- **Pressekontakt-Auswahl** ist Single-Select aus den Kontakten der Firma, **optional** und mit Warn-Box, wenn leer. Das Pivot `press_release_contact` bleibt n:m, fuer den Customer-Flow wird aber maximal ein Kontakt pro PM gespeichert.
- **Anhaenge** sind im UI deaktiviert (Security-Review). Tabelle `press_release_attachments` und Service `PressReleaseAttachmentStorage` bleiben erhalten.
- **Filter-Presets** sind weiterhin **Gelb** (Tabelle existiert, UI noch nicht aktiv).

Phase: **Gruen** fuer Liste, Detail, Statusverlauf, Firmenpflicht, Untertitel, Scheduling und Boilerplate-Override. **Umgesetzt (11.06.)**: KI-Pruefung bei Einreichung (Klassifikation + Content-Score, siehe `Entwicklungsplan KI-Pruefung und Veroeffentlichung.md`); Embargo wurde aus der Form-UI entfernt. **Gelb** fuer Filter-Presets. **Rot/Spaeter** fuer Vorab-KI-Pruefung ohne Einreichung, Notice-and-Action und Korrektur-/Update-Hinweis-System (siehe `Presseportal – Konzept für Relaunch.md`).

**3. Firmen** Klar strukturierter Detailbereich pro Firma, weil hier am meisten dranhängt:

- Tab **Stammdaten** (Firma, Logo, Branche, Footer-Code-Flag)
- Tab **Pressekontakte** – wichtig: Kontakte hängen an der Firma, nicht direkt am User. Hier verwaltet der User die Liste der hinterlegten Pressekontakte. Direkte `contact_user`-Pivots würde ich für den User unsichtbar lassen, da sie eher technisches Artefakt sind.
- Tab **Pressemitteilungen** der Firma
- Tab **Statistik** der Firma
- Tab **Abrechnung** – falls Zahlungsoptionen über `user_payment_option_company` an Firmen gehängt sind, hier sichtbar
- Eigentümer-Anzeige: konsolidiert aus `owner_user_id` UND `company_user.role = owner`. Falls beides existiert und divergiert → Datenqualitätshinweis (eher Admin-Thema, aber User sollte zumindest wissen, wer Owner ist)

Phase: **Grün** für Stammdaten, Kontakte, PMs und Eigentümeranzeige auf bestehendem Modell. **Gelb** für Team-Einladungen, Owner-Übertragung und firmenscharfe Abrechnung.

**4. Medien** Wie zuvor (Eigene / Stock / KI), aber Bilder kommen aus `press_release_images`. Konzeptionell sollte die Bibliothek über alle PMs/Firmen aggregieren. Wenn das Datenmodell aktuell nur 1:n PM→Bild ist, müsste das später auf eine eigenständige `media_library` mit polymorpher Verwendung in PMs umgebaut werden. Aber das ist Phase 2 – fürs Konzept reicht erstmal die Aggregations-Sicht.

Phase: **Gelb** für eine aggregierte Ansicht vorhandener `press_release_images`; **Rot/Später** für eine echte wiederverwendbare Medienbibliothek.

**5. Statistiken** Reichweite/Performance aggregiert oder nach Switcher-Auswahl gefiltert.

Phase: **Grün**, soweit nur vorhandene `hits`, PM-Status und Zeiträume genutzt werden. Erweiterte Quellen, Verweildauer oder Demografie sind **Rot/Später**.

---

### Gruppe „Buchen & Bezahlen"

**6. Buchungen & Add-ons** _(neu als eigener Punkt)_ Zentraler Marktplatz für alles Verbrauchsbasierte:

- Highlights (Kategorie / Startseite / Top-Slot)
- KI-Services (Lektorat, Quality-Check, Übersetzung, Bildgenerierung)
- Premium-Stock
- Newsletter-Erwähnung
- Verteiler-Versand
- Verifiziertes Firmenprofil
- Custom Domain

Mit Tabs:

- **Verfügbar** (Marktplatz, alle buchbaren Services)
- **Aktive Buchungen** (was läuft gerade, wann endet es)
- **Verlauf** (was wurde wann gebucht)

Zusätzlich: Aus dem PM-Editor heraus immer noch der direkte „Highlight buchen"-Button als kontextueller Einstieg. Beide Wege koexistieren.

**7. Credits & Tarif** Wie zuvor, zwei Tabs.

**8. Rechnungen** Wie zuvor: aktuelle + Legacy als Archiv-Tab.

---

### Gruppe „Konto"

**9. Einstellungen** Tabs strukturiert auf Basis des Datenmodells:

- **Profil** (`profiles`-Daten: Anrede, Titel, Adresse, Geburtsdatum, Backlink, Statistik-/Footer-Code-Flags)
- **Rechnungsadresse** (`billing_addresses` – getrennt von Profil, weil eigene Tabelle und oft abweichend)
- **Sicherheit** – hier zeigt das Datenmodell Möglichkeiten, die du dem User geben solltest:
    - Passwort & 2FA
    - Aktive Sessions (`sessions`)
    - **Magic-Link-Verlauf** (`magic_links` – Zweck, Zeitpunkt, IP) – wertvoll für Transparenz und Sicherheit
    - Login-Verlauf
- **Benachrichtigungen** – verbunden mit `newsletter_subscriptions`: User sieht hier seine Newsletter-Abos pro Portal, kann steuern
- **Zahlungsmethoden** (`user_payment_options` – inkl. Verknüpfung zu Firmen, falls vorhanden)
- **Team** (für Agency-Tarif: `company_user`-Pivots verwalten, Rollen vergeben)
- **API & Integrationen**:
    - Tokens (`personal_access_tokens` mit Berechtigungen, letzter Zugriff)
    - **API-Nutzungs-Log** (`api_usage_logs` – Methode, Pfad, Status, Dauer) als eigener Sub-Tab. Das ist Gold für API-User und entlastet deinen Support enorm.
    - Webhooks

Phase: **Grün** für Profil, Rechnungsadresse, Sicherheit, Newsletter und API-Tokens. **Gelb** für Magic-Link-/Token-Request-Historie und API-Nutzungs-Log. **Rot/Später** für Webhooks.

Hinweis unten bei dem Namen ist ein Menü, wo auch noch einmal Settings verknüpft sind https://pressekonto.test/settings/profile 
---

### Gruppe „Hilfe"

**10. Hilfe & Support** wie zuvor.

---

# Was sich konkret durch das Datenmodell geändert hat

|Feature|Wo verankert|Datenquelle|
|---|---|---|
|Datenqualitäts-Hinweise auf Dashboard|Dashboard|`profile`, `billing_address`, PM-`company_id`-Null-Checks|
|PM-Statusverlauf|PM-Detail, Tab „Verlauf"|`press_release_status_logs`|
|Filter-Presets|PM-Liste|`user_filter_presets`|
|Magic-Link-Historie|Einstellungen → Sicherheit|`magic_links`|
|API-Nutzungs-Log|Einstellungen → API|`api_usage_logs`|
|Newsletter-Abos|Einstellungen → Benachrichtigungen|`newsletter_subscriptions`|
|Pressekontakte je Firma|Firma → Bereich „Pressekontakte"|`contacts` via `company_id`|
|Eigentümer-Anzeige|Firma → Stammdaten|`owner_user_id` + `company_user.role`|
|Zahlungsoptionen pro Firma|Firma → Bereich „Abrechnung"|`user_payment_option_company`|

---

# Zwei strategische Punkte aus deinem Datenmodell, die ich aufwerfen würde

**1. Direkte `contact_user`-Pivots im User-UI verstecken** Das Datenmodell erlaubt, Kontakte direkt an User zu hängen (zusätzlich zur Pflicht-Zuordnung an eine Firma). Für den User-UI würde ich das **nicht** sichtbar machen – das verwirrt. Kontakte werden über die Firma verwaltet. Punkt. Die direkte Pivot-Zuordnung kann technisch bleiben (z. B. „User darf diesen Kontakt sehen" über alle Firmen hinweg), aber UI-seitig bleibt es bei „Firma → Kontakte".

**2. PMs ohne Firma** Das Datenmodell erlaubt `company_id = null`. Im User-UI würde ich diese Fälle:

- Auf dem Dashboard als Hinweis listen („3 PMs ohne Firmenzuordnung – jetzt zuordnen")
- In der PM-Liste als eigenen Filter
- Im PM-Editor als Pflichtfeld erzwingen (auch wenn DB es zulässt)

So drehst du die Datenqualität schrittweise sauber, ohne harte Migration.

---

# Firmen-Detail (User-Sicht)

> **IST-Stand 21.05.2026**: Die Firmen-Detailseite ist umgesetzt als
> **eine lange Seite mit Quick-Nav-Ankern** statt mit echten Tab-Wechseln.
> Die im folgenden beschriebene Tab-Struktur ist konzeptuell gleichwertig
> und kann bei Bedarf in eine echte Tab-Komponente umgezogen werden,
> ohne den Funktionsumfang zu aendern.
>
> **Route**: `/admin/me/press-kits/{company}` mit dem Routen-Namen
> `me.press-kits.show`. In der UI heisst der Bereich „Firmen".

## Aufruf

Drei Wege führen hierher:

- Klick auf einen Eintrag in der Firmen-Liste
- Klick auf den Firmennamen im Firmen-Kontext-Switcher (→ aktive Firma + Sprung in Detail)
- Tiefenlinks aus PM-Detail („zur Firma"), Statistik („Firma im Detail")

URL-Struktur: `/firmen/{id}` im User Backend (konzeptueller Zielzustand). IST: `/admin/me/press-kits/{id}` (siehe Routen-Name oben). Öffentliche Pressemappe bleibt ein separater PR-Kontext.

---

## Header (über allen Tabs sichtbar)

Kompakte Header-Karte mit:

- **Logo** (links, klickbar zum Ändern wenn berechtigt)
- **Firmenname** + dezenter `slug`-Hinweis
- **Status-Badges nebeneinander**:
    - Portal (welches der beiden Portale)
    - Verifizierungs-Status (Häkchen oder „Nicht verifiziert")
    - Aktiv/Inaktiv
    - Deine Rolle: Owner / Verantwortlich / Mitglied
- **Aktions-Menü** rechts:
    - Primär: „Neue Pressemitteilung" (führt direkt in Editor mit dieser Firma vorausgewählt)
    - Sekundär (Dropdown): „Verifizierung beantragen", „Custom Domain einrichten", „Als inaktiv markieren", „Firma übertragen"

Der Header bleibt beim Tab-Wechsel stehen, sodass Kontext (welche Firma, welche Rolle) nie verloren geht.

---

## Tab-Struktur (6 Tabs)

### Tab 1: Übersicht (Default)

Eine Mini-Dashboard-Sicht für genau diese Firma. Gibt dem User sofort das Gefühl „hier passiert was" beim Reinklicken.

Inhalte:

- **KPI-Reihe**: Anzahl PMs gesamt, Veröffentlicht in den letzten 30 Tagen, Aktive Highlights, Reichweite (30 Tage)
- **Letzte 5 Pressemitteilungen** dieser Firma mit Status und Datum
- **Pressekontakte-Block**: kompakte Liste, „X Kontakte hinterlegt", Sprung in Tab 3
- **Datenqualitäts-Hinweise** firmenspezifisch:
    - „Logo fehlt"
    - „Keine Pressekontakte hinterlegt – Änderungs-Workflow nicht möglich"
    - „Owner-Konflikt: `owner_user_id` und `company_user.role=owner` divergieren" (eher Admin-Hinweis, aber wenn es User betrifft, transparent zeigen)
    - „Branche nicht gesetzt – beeinträchtigt Auffindbarkeit"
- **Quick Actions**: „Neue PM", „Pressekontakt hinzufügen", „Highlight buchen"

### Tab 2: Stammdaten

Bearbeitbare Firmendaten. Felder gemäß `companies`-Tabelle:

- Firmenname *
- Logo (Upload, mit Preview)
- Kurzbeschreibung (1–2 Sätze für Listing-Ansichten)
- Lange Beschreibung (für die Firmenseite)
- Branche/Kategorie *
- Adresse: Straße, PLZ, Ort, Land
- Website-URL
- Footer-Code-Flag (mit kurzer Erklärung was es bewirkt)
- Aktivstatus (Toggle, mit Warnhinweis was passiert)

**Eigentümer-Block** (read-only für Nicht-Owner):

- Anzeige des konsolidierten Eigentümers
- Bei Divergenz zwischen `owner_user_id` und `company_user.role=owner`: gelber Warnhinweis mit „An Support melden"-Link

**Portal-Anzeige**:

- Read-only mit Tooltip: „Das Portal wird durch die Firma festgelegt und kann nicht im Self-Service geändert werden. Bei Bedarf bitte Support kontaktieren."

**Verifizierung**:

- Status anzeigen
- Wenn nicht verifiziert: CTA „Verifizierung beantragen" → führt zu Buchungen & Add-ons mit vorausgewähltem Service

### Tab 3: Pressekontakte

Verwaltung der `contacts` dieser Firma. Direkte `contact_user`-Pivots werden hier nicht angezeigt – Kontakte gehören zur Firma, Punkt.

Liste mit:

- Name, Position, E-Mail, Telefon
- Status-Badge: „Magic-Link aktiv" / „Magic-Link inaktiv"
- Anzahl PMs, in denen dieser Kontakt referenziert ist (aus `press_release_contact`)
- Aktionen: Bearbeiten / Löschen / Test-Magic-Link senden

Oben: „+ Neuer Pressekontakt" mit Formular (Name, Position, E-Mail, Telefon, Magic-Link-Berechtigung ja/nein).

**Wichtiger Erklärungsblock** über der Liste (einmalig dismissible):

> Pressekontakte sind die offiziellen Ansprechpartner zu dieser Firma. Sie können sich per Magic-Link einloggen, um Pressemitteilungen zu korrigieren, zu aktualisieren oder DSGVO-Anfragen zu stellen. Hinterlegen Sie alle relevanten Kontakte, um den autorisierten Änderungs-Workflow zu ermöglichen.

Beim Löschen eines Kontakts: Warnung, falls dieser noch in PMs referenziert ist („In 12 PMs hinterlegt – diese verlieren den Kontakt").

### Tab 4: Pressemitteilungen

Gefilterte PM-Liste auf `company_id` dieser Firma.

- Standard-Filter (Alle / Veröffentlicht / In Prüfung / Entwürfe / Depubliziert / Korrekturen)
- Volltextsuche
- „+ Neue Pressemitteilung" mit dieser Firma vorausgewählt
- Pro Eintrag: Titel, Status, Datum, zugeordnete Pressekontakte, Reichweite, Aktionen

Bulk-Aktionen für Power-User: Mehrere PMs auswählen → „Pressekontakte bulk zuordnen", „Exportieren als PDF".

### Tab 5: Statistik

Reichweite und Performance dieser Firma:

- Views, Klicks, Verweildauer im Zeitverlauf (30/90/365 Tage)
- Top-PMs nach Reichweite
- Verteilung nach Quelle (organisch, Newsletter, Distribution-Partner)
- Kategorien-Heatmap (welche Themen performen)
- Aktive Highlights & Buchungen, die dieser Firma zugeordnet sind
- Im Pro-Tarif zusätzlich: Demografie, Geräte, Suchbegriffe

Export-Button (CSV/PDF) – sinnvoll für Reportings, die User intern an Marketing/Geschäftsführung weiterleiten.

### Tab 6: Abrechnung

Hier wird's etwas heikel, weil Abrechnung hauptsächlich am User hängt, aber `user_payment_option_company` einen firmenscharfen Bezug erlaubt.

Inhalte:

- **Zahlungsmethoden für diese Firma** – Liste der `user_payment_options`, die per Pivot mit dieser Firma verknüpft sind
- „Zahlungsmethode dieser Firma zuordnen" (aus den vorhandenen User-Zahlungsmethoden auswählen)
- **Rechnungen mit Firmenbezug** – PMs/Buchungen, die diese Firma betreffen, mit den entsprechenden Rechnungen
- **Klarer Erklärtext oben**:

> Rechnungen werden grundsätzlich auf Ihren User-Account ausgestellt. Hier sehen Sie Zahlungsmethoden und Buchungen, die speziell dieser Firma zugeordnet sind. Eine vollständige Übersicht aller Rechnungen finden Sie unter „Rechnungen".

Dieser Tab ist nur für Owner sichtbar – Member und Verantwortliche haben hier nichts verloren.

---

## Rollen-Logik (aus `company_user.role`)

Klare Sichtbarkeits- und Bearbeitungsregeln:

**Owner**: Alle Tabs, alle Aktionen. Kann Firma deaktivieren, übertragen, Pressekontakte verwalten, Stammdaten ändern, Abrechnung sehen.

**Verantwortlich**: Übersicht, Stammdaten (read-only), Pressekontakte (verwalten), PMs (verwalten + erstellen), Statistik. Kein Tab Abrechnung. Stammdaten-Änderungen mit Hinweis „Nur Owner kann ändern".

**Mitglied**: Übersicht, Stammdaten (read-only), Pressekontakte (read-only), PMs (eigene erstellen, nur eigene bearbeiten), Statistik. Kein Tab Abrechnung.

Im Header die Rolle als Badge zeigen, damit der User immer weiß, was er darf, ohne dass er es durch Klicken herausfindet.

---

## Verknüpfungen zu anderen Bereichen

- **Switcher** (Topbar rechts): Auswahl einer Firma scrollt globale Filter auf diese Firma, der direkte Sprung ins Detail bleibt aber ein expliziter Klick
- **PM-Editor**: PMs werden mit `company_id` erstellt, das Feld ist Pflicht (auch wenn DB nullable). Aus dem Firmen-Detail ist es vorausgewählt.
- **Buchungen & Add-ons**: Highlights, KI-Services, Verifizierung etc. werden in der Buchungs-Sektion abgewickelt, aber aus dem Firmen-Detail kontextuell verlinkt
- **Statistiken (Hauptpunkt)**: Aggregierte Sicht über alle Firmen vs. firmenspezifische Sicht hier im Tab. Beide Wege koexistieren.
- **Einstellungen → Team**: Beim Agency-Tarif können User andere User zur Firma einladen (`company_user`-Pivot mit Rolle setzen). Verlinkung von hier aus sinnvoll.

---

## Offene Designentscheidungen

**1. Firmenwechsel-Bestätigung** Wenn ein User im Firmen-Detail arbeitet und über den Switcher die Firma wechselt – sofort wechseln oder Warnung „ungespeicherte Änderungen"? Ich würde Standard-Browser-Verhalten beibehalten (`beforeunload` bei dirty forms), kein eigener Dialog.

**2. Firma deaktivieren vs. löschen** Im Datenmodell ist Aktiv/Inaktiv vorhanden. Echtes Löschen ist heikel wegen verknüpfter PMs, Rechnungen, Kontakte. Ich würde dem User **nur** Deaktivieren anbieten – echtes Löschen läuft über Support-Anfrage. Senkt deine Risiken bei DSGVO-Konflikten.

**3. Owner-Übertragung** „Firma übertragen" ist ein sensibler Vorgang. Ich würde einen eigenen Wizard mit E-Mail-Bestätigung beim neuen Owner verlangen (ähnlich GitHub-Repo-Transfer). Macht den Punkt komplexer, aber sauber.

**4. Pressekontakt-Zuordnung beim PM-Erstellen** Beim Anlegen einer neuen PM: Sollen alle Pressekontakte der Firma automatisch zugeordnet werden, oder muss der User explizit auswählen? Ich tendiere zu „alle vorausgewählt, abwählbar" – gibt dem User eine Voreinstellung, die in 90 % der Fälle stimmt.

---