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. Naechster Block (Zahlung/Tarife, Veroeffentlichungs-Flow): docs/Decision-Update Preisstruktur & Veröffentlichungs-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.

---