2026-07-26 02:35:44 +02:00
# LeoCRM — Implementationsplan: Fehlende Frontend-Features
> **Stand:** 26.07.2026 (Audit-korrigiert) | **Backend:** 352 Endpunkte | **Frontend:** 47 Pages, 38 API-Clients
2026-08-04 13:43:54 +02:00
> **Repo:** `/a0/usr/workdir/leocrm-fix` | **Branch:** `main` | **Deploy:** Coolify App `dx4pqdziu4uj6x9fxs1u5z0x`
2026-07-26 02:35:44 +02:00
---
## ⚠️ 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. *
