leocrm/IMPLEMENTATION_PLAN.md

LeoCRM — Implementationsplan: Fehlende Frontend-Features

Stand: 26.07.2026 (Audit-korrigiert) | Backend: 352 Endpunkte | Frontend: 47 Pages, 38 API-Clients Repo: /a0/usr/workdir/leocrm-fix | Branch: main | Deploy: Coolify App stvabl4vaqru7jclx4ittzr3

---

⚠️ Audit-Korrekturen (26.07.2026 02:17)

Korrektur 1: Permissions Management UI — ENTHALTEN IN SettingsRoles.tsx

Vorher: Plan sagte "keine Verwaltungs-Seite um Permissions pro Rolle zu konfigurieren" Tatsächlich: SettingsRoles.tsx (531 Zeilen) hat VOLLSTÄNDIGE Permission-Verwaltung:

• ✅ Grant permissions (Checkboxen gruppiert nach system/plugin)
• ✅ Denied permissions (explizite Verweigern-Liste)
• ✅ Field-level permissions (pro Modul/Feld Sensitivität)
• ✅ Rollen erstellen/bearbeiten mit Permission-Zuweisung
• ✅ DMS ShareDialog.tsx nutzt bereits File-Permissions API (grant/revoke/share-link) Folge: Feature 8 entfällt. Keine neue Permission-UI nötig.

Korrektur 2: Import/Export — Export-Route fehlt DEFINITIV

Vorher: Plan sagte "falls Export fehlt" Tatsächlich: export_contacts_csv() Service-Funktion existiert, aber KEINE Route in import_export.py. Nur /import und /import/preview sind registriert. Export muss als Route hinzugefügt werden.

Korrektur 3: Activity Timeline — ActivityFeed existiert bereits

Vorher: Plan sagte "Dashboard hat ActivityFeed aber nur statisch" Tatsächlich: Dashboard nutzt ActivityFeed mit Daten aus Audit-API. Komponente ist wiederverwendbar. Es fehlt nur eine eigenständige Seite mit Filterung/Pagination.

Korrektur 4: DMS ShareDialog — File Permissions bereits integriert

Vorher: Plan sah FilePermissionDialog als neue Komponente vor Tatsächlich: ShareDialog.tsx (11KB) existiert bereits und nutzt fetchFilePermissions, grantPermission, revokePermission, createShareLink, revokeShareLink aus permissions.ts.

---

Übersicht: 14 verbleibende Features in 4 Phasen

Phase	Features	Priorität	Geschätzter Aufwand
1 — Kritisch	Workflows UI, Dedup/Merge UI, Import/Export UI, Print/PDF	CRM-Kern	~4-5 Tage
2 — Wichtig	Tags UI, Custom Fields UI, Notifications Dropdown	Tagesgeschäft	~2.5-3 Tage
3 — Nice-to-have	Saved Filters UI, Entity History UI, Activity Timeline, API Docs Link	Produktivität	~1.5-2 Tage
4 — Backend+Frontend	Webhooks, Backup/Restore UI, Onboarding/Tutorial	Erweiterungen	~3-4 Tage

Gesamtaufwand: ~11-14 Entwicklungstage (1 Feature entfallen)

---

Architektur-Grundsätze (für alle Features)

Frontend-Konventionen

• Routing: Lazy-loaded in frontend/src/routes/index.tsx, explizite Routes (nicht PluginRouteRenderer)
• API-Clients: In frontend/src/api/<name>.ts, verwenden apiGet/apiPost/apiPatch/apiDelete aus client.ts
• Hooks: React Query (useQuery/useMutation) mit Query-Key-Invalidierung
• UI: Tailwind CSS, clsx für Klassen, lucide-react für Icons
• i18n: useTranslation() mit t('key'), Keys in frontend/src/i18n/
• Sidebar: Plugin-Manifeste liefern Menu-Items via usePluginStore — neue Pages brauchen Plugin-Manifest-Einträge
• Settings: Hardcoded nav items in Settings.tsx + plugin settings_pages
• Error Handling: ErrorBoundary wrappt alle Routes

Backend-Konventionen

• Routes: app/routes/<name>.py, registriert in app/main.py
• Services: app/services/<name>_service.py
• Models: app/models/<name>.py, Migrationen in alembic/versions/
• Schemas: app/schemas/<name>.py (Pydantic)
• Permissions: require_permission('plugin:action') Dependency
• Events: event_bus.publish() für System-Events

---

Phase 1 — Kritisch für CRM-Betrieb

1.1 Workflows UI

Audit-Status: ✅ Backend vollständig (routes, model, service, execution engine). ✅ API-Client vollständig (workflows.ts). ❌ Keine Frontend-Seite. ❌ Kein menu_items-Eintrag im Automation-Plugin.

Neue Dateien:

• frontend/src/pages/Workflows.tsx — Hauptseite mit Tabs: Definitionen | Instanzen
• frontend/src/components/workflows/WorkflowEditor.tsx — Visueller Step-Editor
• frontend/src/components/workflows/WorkflowInstanceList.tsx — Liste laufender/abgeschlossener Instanzen
• frontend/src/components/workflows/WorkflowInstanceDetail.tsx — Detail mit Step-History, Approve/Reject
• frontend/src/components/workflows/StepConfigPanel.tsx — Konfiguration pro Step-Typ

Modifizierte Dateien:

• frontend/src/routes/index.tsx — Route /workflows + /workflows/instances/:id
• app/plugins/builtins/automation/plugin.py — menu_items Eintrag für Workflows (aktuell menu_items=[])
• frontend/src/i18n/de.json — Workflow-Übersetzungen

Step-Editor:

• Step-Typen: action, approval, notification, condition
• Drag-and-Drop Reihenfolge (oder Button-basiert nach oben/unten)
• Pro Step: Name, Typ, Config-Form
• Trigger-Event Dropdown (aus Event-Bus-Events)
• Aktiv/Inaktiv Toggle

Instanzen-View:

• Status-Filter: pending, in_progress, completed, rejected, cancelled
• Pro Instanz: Workflow-Name, Status, Current Step, Timeout
• Detail: Step-History Timeline, Approve/Reject Buttons

Aufwand: ~1.5 Tage

---

1.2 Dedup/Merge UI

Audit-Status: ✅ Backend vollständig (dedup_service.py, routes in contacts.py: /duplicates, /merge, /merge-history). ✅ API-Client vollständig (dedup.ts). ❌ Keine Frontend-Seite.

Neue Dateien:

• frontend/src/pages/DedupMerge.tsx — Hauptseite mit drei Bereichen
• frontend/src/components/dedup/DuplicatePairCard.tsx — Side-by-side Vergleich
• frontend/src/components/dedup/MergeDialog.tsx — Merge-Dialog mit Feld-Auswahl
• frontend/src/components/dedup/MergeHistory.tsx — Verlauf der durchgeführten Merges

Modifizierte Dateien:

• frontend/src/routes/index.tsx — Route /contacts/dedup
• frontend/src/pages/ContactsList.tsx — Button "Duplikate prüfen" im Header
• frontend/src/i18n/de.json — Dedup-Übersetzungen

Merge-Dialog:

• Side-by-side Feld-Vergleich
• Pro Feld Radio: Quelle | Ziel | Manuell eingeben
• Vorschau des merged Kontakts
• Optionale Notiz
• Bestätigungs-Button mit Warnung

Aufwand: ~1 Tag

---

1.3 Import/Export UI

Audit-Status: ✅ Backend hat /api/v1/import + /api/v1/import/preview (Routes). ✅ Service hat import_csv(), export_contacts_csv(). ❌ Export-Route fehlt — Service-Funktion existiert aber ist nicht als Endpoint registriert. ❌ Kein Frontend, kein API-Client.

Backend-Ergänzung (bestätigt nötig):

• app/routes/import_export.py — GET /api/v1/export?entity_type=contacts&format=csv hinzufügen
  • Ruft export_contacts_csv() auf, gibt StreamingResponse mit CSV zurück
  • Erweiterung: entity_type=companies (Filter auf Contact.type == 'company')
  • Optional: XLSX-Format via openpyxl

Neue Frontend-Dateien:

• frontend/src/pages/ImportExport.tsx — Hauptseite mit Tabs: Import | Export
• frontend/src/components/import-export/ImportWizard.tsx — Mehrstufiger Import-Wizard
• frontend/src/components/import-export/ExportPanel.tsx — Export-Auswahl
• frontend/src/api/importExport.ts — API-Client (neu)

Modifizierte Dateien:

• frontend/src/routes/index.tsx — Route /import-export
• Plugin-Manifest — menu_items Eintrag
• frontend/src/i18n/de.json — Übersetzungen

Import-Wizard:

Step 1: Datei hochladen + Entity-Typ (Companies/Contacts)
Step 2: Dry-Run Preview — zeigt erkannte Spalten, Mapping, Fehler
Step 3: Bestätigung — Anzahl neu/aktualisiert/fehlerhaft
Step 4: Import ausführen — Progress + Ergebnis

Export-Panel:

• Entity: Kontakte / Firmen
• Format: CSV (XLSX optional)
• Download-Button → File-Download

Aufwand: ~1.5 Tage (inkl. Backend Export-Route)

---

1.4 Print/PDF

Audit-Status: ❌ Komplett fehlend. Keine Print-Utils, keine Print-Buttons, kein @media print CSS.

Neue Dateien:

• frontend/src/utils/print.ts — Print-Utility
• frontend/src/components/common/PrintButton.tsx — Wiederverwendbarer Print/Export-Button
• frontend/src/styles/print.css — Print-spezifische CSS

Modifizierte Dateien:

• frontend/src/pages/ContactsList.tsx — Print-Button in Toolbar
• frontend/src/pages/ContactDetailPage.tsx — Print-Button
• frontend/src/pages/Calendar.tsx — Print-Button
• frontend/src/pages/Reports.tsx — Print-Button
• frontend/index.html — Print-CSS einbinden

Implementierung:

• Option A: window.print() mit @media print CSS (empfohlen für Listen/Details)
• Option B: jspdf + html2canvas für echte PDF-Generierung (für Reports)
• Print-Button Dropdown: "Drucken" | "Als PDF"

Aufwand: ~0.5 Tage

---

Phase 2 — Wichtig für Tagesgeschäft

2.1 Tags UI

Audit-Status: ✅ Backend-Plugin vollständig (app/plugins/builtins/tags/: models, routes, schemas). ✅ API-Client vollständig (tags.ts). ❌ Keine Frontend-Seite.

Neue Dateien:

• frontend/src/pages/Tags.tsx — Tag-Verwaltung (CRUD, Farb-Auswahl, Usage-Count)
• frontend/src/components/tags/TagBadge.tsx — Wiederverwendbares Tag-Badge
• frontend/src/components/tags/TagSelector.tsx — Multi-Select Tag-Picker

Modifizierte Dateien:

• frontend/src/routes/index.tsx — Route /tags
• frontend/src/pages/ContactsList.tsx — Tag-Spalte + Tag-Filter
• frontend/src/pages/ContactDetailPage.tsx — Tag-Badges + Tag-Selector
• frontend/src/pages/Calendar.tsx — Tag-Badges für Termine
• frontend/src/pages/Dms.tsx — Tag-Badges für Dateien
• Plugin-Manifest — menu_items
• frontend/src/i18n/de.json

Aufwand: ~1 Tag

---

2.2 Custom Fields UI

Audit-Status: ✅ Backend hat Custom-Fields-Route (plugin-manifest-gesteuert, Werte in contacts.custom JSONB). ❌ Keine User-definierten Feld-Definitionen (nur Plugin-Definitionen). ❌ Keine Frontend-Seite.

Backend-Ergänzung nötig:

• app/models/custom_field_definition.py — Model für User-definierte Felder
• app/schemas/custom_field_definition.py — Pydantic Schemas
• app/services/custom_field_service.py — CRUD-Service
• app/routes/custom_fields.py — GET/POST/PATCH/DELETE /api/v1/custom-fields/definitions
• Migration für custom_field_definitions Tabelle
• Bestehende _collect_custom_field_definitions() erweitern um DB-Definitionen

Neue Frontend-Dateien:

• frontend/src/pages/CustomFields.tsx — Definitionen verwalten
• frontend/src/components/custom-fields/FieldDefinitionForm.tsx — Form für neue Felder
• frontend/src/components/custom-fields/CustomFieldRenderer.tsx — Dynamisches Feld-Rendering
• frontend/src/api/customFieldDefinitions.ts — API-Client für Definitionen

Modifizierte Dateien:

• frontend/src/routes/index.tsx — Route /settings/custom-fields
• frontend/src/pages/Settings.tsx — Nav-Eintrag "Custom Fields"
• frontend/src/pages/ContactDetailPage.tsx — Custom Fields Section
• frontend/src/i18n/de.json

Feld-Typen: text, number, date, select, multiselect, boolean

Aufwand: ~1.5 Tage (inkl. Backend CRUD + Migration)

---

2.3 Notifications Dropdown (Bell Icon in TopBar)

Audit-Status: ✅ API-Client vollständig (notifications.ts). ✅ Backend vollständig. ❌ TopBar hat kein Bell-Icon (confirmed: grep findet nichts). Notifications nur in AISidebar.

Neue Dateien:

• frontend/src/components/layout/NotificationBell.tsx — Bell-Icon mit Badge + Dropdown
• frontend/src/components/notifications/NotificationDropdown.tsx — Dropdown-Liste
• frontend/src/components/notifications/NotificationItem.tsx — Einzelne Notification

Modifizierte Dateien:

• frontend/src/components/layout/TopBar.tsx — <NotificationBell /> vor User-Menu einfügen
• frontend/src/i18n/de.json

Features:

• Unread-Count Badge (rot)
• Polling alle 30s (refetchInterval in useQuery)
• Click: Notification als gelesen markieren
• "Alle als gelesen" Button
• Type-Icon pro Notification
• Zeitstempel (relativ: "vor 5 Min")

Aufwand: ~0.5 Tage

---

Phase 3 — Nice-to-have / Produktivität

3.1 Saved Filters UI

Audit-Status: ✅ Backend vollständig (saved_filters.py: CRUD, entity_types: contacts/mail/calendar/dms). ✅ API-Client vorhanden (savedFilters.ts). ❌ Keine UI.

Neue Dateien:

• frontend/src/components/common/SavedFilterBar.tsx — Filter-Leiste mit Save/Load
• frontend/src/components/common/SaveFilterDialog.tsx — Dialog zum Speichern

Modifizierte Dateien:

• frontend/src/pages/ContactsList.tsx — SavedFilterBar
• frontend/src/pages/Calendar.tsx — SavedFilterBar
• frontend/src/pages/Dms.tsx — SavedFilterBar
• frontend/src/pages/Tasks.tsx — SavedFilterBar
• frontend/src/i18n/de.json

Aufwand: ~0.5 Tage

---

3.2 Entity History UI

Audit-Status: ✅ Backend vollständig (entity_history.py: get/restore/undo). ✅ API-Client vorhanden (entityHistory.ts). ❌ Keine UI-Komponente.

Neue Dateien:

• frontend/src/components/common/EntityHistoryPanel.tsx — Timeline-Komponente
• frontend/src/components/common/HistoryDiff.tsx — Visualisierung von Feld-Änderungen

Modifizierte Dateien:

• frontend/src/pages/ContactDetailPage.tsx — History-Tab/Panel
• frontend/src/pages/Dms.tsx — History für Dateien
• frontend/src/pages/Calendar.tsx — History für Termine
• frontend/src/i18n/de.json

Features:

• Timeline mit create/update/delete Events
• Diff-Anzeige: alt → neu pro Feld
• Restore-Button pro Eintrag
• Undo-Button (letzte Aktion rückgängig)

Aufwand: ~0.5 Tage

---

3.3 Activity Timeline

Audit-Status: ✅ ActivityFeed Komponente existiert (wiederverwendbar). ✅ Dashboard nutzt sie mit Audit-Daten. ❌ Keine eigenständige Seite mit Filterung/Pagination.

Neue Dateien:

• frontend/src/pages/ActivityTimeline.tsx — Globale Activity-Feed Seite
• frontend/src/components/activity/ActivityFilter.tsx — Filter (User, Entity, Action, Zeitraum)

Modifizierte Dateien:

• frontend/src/routes/index.tsx — Route /activity
• frontend/src/api/audit.ts — Erweitern um Timeline-Query (alle Entities, Pagination)
• frontend/src/pages/Dashboard.tsx — Link "Alle Aktivitäten anzeigen"
• frontend/src/i18n/de.json

Features:

• Wiederverwendung von ActivityFeed Komponente
• Gruppierung nach Tag
• Filter: User, Entity-Typ, Aktion, Zeitraum
• Pagination / Infinite-Scroll
• Link zu Entity-Detail bei Click

Aufwand: ~0.5 Tage

---

3.4 API Documentation Link

Audit-Status: ✅ FastAPI generiert automatisch /docs (Swagger) und /redoc. ❌ Kein Link im UI.

Modifizierte Dateien:

• frontend/src/components/layout/TopBar.tsx — "API Docs" Link im User-Menu
• frontend/src/pages/SettingsSystem.tsx — "API Dokumentation" Sektion
• frontend/src/i18n/de.json

Implementierung:

• Link zu Swagger UI: /docs (FastAPI auto-docs)
• Link zu ReDoc: /redoc
• In Settings/System: Sektion "Entwickler"

Aufwand: ~0.25 Tage

---

Phase 4 — Backend + Frontend (komplett neu)

4.1 Webhooks

Audit-Status: ❌ Komplett fehlend. Kein Backend, kein Frontend, keine Modelle.

Neue Backend-Dateien:

• app/models/webhook.py — Webhook-Modell (url, events, secret, is_active, retry_count)
• app/schemas/webhook.py — Pydantic Schemas
• app/services/webhook_service.py — Webhook-Service (send, retry, verify HMAC)
• app/routes/webhooks.py — CRUD-Routes /api/v1/webhooks
• app/core/webhook_dispatcher.py — Event-Bus-Subscriber
• alembic/versions/0036_webhooks.py — Migration

Neue Frontend-Dateien:

• frontend/src/pages/SettingsWebhooks.tsx — Webhook-Verwaltung
• frontend/src/components/webhooks/WebhookForm.tsx — Create/Edit Form
• frontend/src/components/webhooks/WebhookDeliveryLog.tsx — Delivery-Log
• frontend/src/api/webhooks.ts — API-Client

Modifizierte Dateien:

• app/main.py — Router registrieren
• app/core/event_bus.py — Webhook-Dispatcher subscriben
• frontend/src/routes/index.tsx — Route /settings/webhooks
• frontend/src/pages/Settings.tsx — Nav-Eintrag "Webhooks"
• frontend/src/i18n/de.json

Features:

• URL + Secret (HMAC-Signatur)
• Event-Auswahl (Multi-Select aus Event-Bus-Events)
• Aktiv/Pause Toggle
• Delivery-Log mit Status, Response-Code, Latenz
• Retry-Konfiguration
• Test-Button

Aufwand: ~1.5 Tage

---

4.2 Backup/Restore UI

Audit-Status: ✅ backup_check Cron-Job existiert (prüft last_backup_at, published Events). ❌ Keine Backup-Routes, keine Restore-Funktionalität, keine UI.

Backend-Ergänzung:

• app/routes/backups.py — /api/v1/backups (list, create, restore, delete)
• app/services/backup_service.py — Backup erstellen (pg_dump), Restore (pg_restore)
• app/models/backup.py — Backup-Modell
• alembic/versions/0037_backups.py — Migration

Neue Frontend-Dateien:

• frontend/src/pages/SettingsBackup.tsx — Backup-Verwaltung
• frontend/src/components/backup/BackupList.tsx — Liste der Backups
• frontend/src/components/backup/RestoreDialog.tsx — Restore-Bestätigung
• frontend/src/api/backups.ts — API-Client

Modifizierte Dateien:

• app/main.py — Router registrieren
• frontend/src/routes/index.tsx — Route /settings/backup
• frontend/src/pages/Settings.tsx — Nav-Eintrag "Backup & Restore"
• frontend/src/i18n/de.json

Aufwand: ~1 Tag

---

4.3 Onboarding/Tutorial

Audit-Status: ❌ Komplett fehlend.

Neue Dateien:

• frontend/src/components/onboarding/OnboardingTour.tsx — Guided Tour
• frontend/src/components/onboarding/WelcomeDialog.tsx — Willkommens-Dialog
• frontend/src/store/onboardingStore.ts — Zustand-Store

Modifizierte Dateien:

• frontend/src/components/layout/AppShell.tsx — OnboardingTour einbinden
• frontend/src/api/userPreferences.ts — onboarding_completed flag
• frontend/src/i18n/de.json

Tour-Schritte (8):

1. Willkommen
2. Sidebar-Navigation
3. Globale Suche
4. Kontakte erstellen
5. Kalender/Termine
6. KI Assistent
7. Einstellungen
8. Fertig

Bibliothek: react-joyride oder Custom Implementation

Aufwand: ~1 Tag

---

Implementations-Reihenfolge

Phase 1 (Kritisch)
  1.1 Workflows UI          ████████████████░░░  1.5 Tage
  1.2 Dedup/Merge UI        ███████████░░░░░░░░  1.0 Tag
  1.3 Import/Export UI      ████████████████░░░  1.5 Tage (inkl. Backend Export-Route)
  1.4 Print/PDF             █████░░░░░░░░░░░░░░  0.5 Tage

Phase 2 (Wichtig)
  2.1 Tags UI               ███████████░░░░░░░░  1.0 Tag
  2.2 Custom Fields UI      ████████████████░░░  1.5 Tage (inkl. Backend CRUD)
  2.3 Notifications Bell    █████░░░░░░░░░░░░░░  0.5 Tage

Phase 3 (Nice-to-have)
  3.1 Saved Filters UI      █████░░░░░░░░░░░░░░  0.5 Tage
  3.2 Entity History UI     █████░░░░░░░░░░░░░░  0.5 Tage
  3.3 Activity Timeline     █████░░░░░░░░░░░░░░  0.5 Tage
  3.4 API Docs Link         ██░░░░░░░░░░░░░░░░░  0.25 Tage

Phase 4 (Backend + Frontend)
  4.1 Webhooks              ████████████████░░░  1.5 Tage
  4.2 Backup/Restore UI     ███████████░░░░░░░░  1.0 Tag
  4.3 Onboarding/Tutorial   ███████████░░░░░░░░  1.0 Tag

Deployment-Strategie

Nach jeder Phase:

1. Frontend Build: cd frontend && npm run build
2. Git commit + push
3. Coolify Auto-Deploy
4. Verifikation im Browser

Abhängigkeiten

1.1 Workflows UI ← keine (API ready)
1.2 Dedup/Merge UI ← keine (API ready)
1.3 Import/Export UI ← Backend Export-Route hinzufügen (Service existiert)
1.4 Print/PDF ← keine

2.1 Tags UI ← keine (API ready)
2.2 Custom Fields UI ← Backend CRUD + Migration (neu)
2.3 Notifications Bell ← keine (API ready)

3.1 Saved Filters ← keine (API ready)
3.2 Entity History ← keine (API ready)
3.3 Activity Timeline ← Audit-API ggf. erweitern (Pagination)
3.4 API Docs Link ← keine

4.1 Webhooks ← Backend komplett neu + Migration
4.2 Backup/Restore ← Backend komplett neu + Migration
4.3 Onboarding ← User-Preferences API ggf. erweitern

Risiko-Bewertung

Feature	Risiko	Grund
Workflows UI	Mittel	Komplexe Step-Editor UI
Custom Fields UI	Hoch	Backend-Ergänzung + dynamisches Rendering
Webhooks	Hoch	Backend komplett neu, Security (HMAC, Retry)
Backup/Restore	Hoch	Datenverlust-Risiko bei Fehlern
Import/Export	Mittel	Backend Export-Route fehlt, Datei-Handling
Alle anderen	Niedrig	API existiert, nur UI

---

Entfallenes Feature

Permissions Management UI — BEREITS VORHANDEN

• SettingsRoles.tsx (531 Zeilen) hat vollständige Permission-Verwaltung
• ShareDialog.tsx (11KB) nutzt File-Permissions API
• roles.ts API-Client hat usePermissions(), useRoles(), useCreateRole(), useUpdateRole(), useDeleteRole()
• Backend /roles/permissions liefert alle System+Plugin-Permissions
• Backend Roles-CRUD erlaubt Permission-Zuweisung (grant/deny/field-level)

---

Plan erstellt am 26.07.2026, audit-korrigiert um 02:17 — bereit zur Umsetzung.