Automatisierung — Zentrale Administration aller Workflows

Beschreibung und Kontext

Die Seite "Automatisierung" in "Meine Sicht" zeigt aktuell nur ein Dashboard mit Workflow-Run-Metriken und einer Runs-Tabelle. Was fehlt, ist eine zentrale Verwaltung ALLER Workflows, auf die der User gemäss RBAC Zugriff hat — über alle Mandanten und Feature-Instanzen hinweg.

Business-Treiber: Admins und Power-User brauchen eine Übersicht über alle Workflows ohne in jede einzelne graphicalEditor-Instanz navigieren zu müssen. Berechtigungen (View/Edit/Delete/Execute) sollen pro Workflow-Zeile sichtbar sein.

Abhängigkeiten:

routeWorkflowDashboard.py — bestehender System-Dashboard-Endpunkt (nur Runs)
GraphicalEditorWorkflowsPage.tsx — Referenz-Implementierung für Instanz-Workflows
FormGeneratorTable — Backend-driven Table mit Paginierung
Tabs-Komponente — existiert bereits

Risiko bei Nicht-Umsetzung: Admins müssen manuell durch jede Instanz navigieren, um Workflows zu finden/verwalten. Keine zentrale Kontrolle.

Fokus und kritische Details

RBAC-Scoping muss konsistent mit bestehender _scopedRunFilter-Logik sein
Dashboard-Tabelle nutzt aktuell KEINE Backend-Paginierung (nur Client-seitig) — muss korrigiert werden
AutoWorkflow hat mandateId + featureInstanceId — Enrichment mit Labels nötig
Per-Workflow RBAC-Permissions (canEdit, canDelete, canExecute) müssen vom Backend geliefert werden
t() konsequent für alle Sprachtexte

Ziel und Nicht-Ziele

Ziel: 2 Tabs auf der Automatisierung-Seite (Dashboard + Workflows), zentraler Workflow-Manager mit RBAC
Ziel: Dashboard-Tabelle auf saubere Backend-Paginierung via hookData
Explizit NICHT: Workflow-Editor in der zentralen Ansicht (Edit navigiert zur Instanz)
Explizit NICHT: Neue Workflows erstellen aus der zentralen Ansicht

Betroffene Module

Gateway: routeWorkflowDashboard.py — Endpunkt GET /api/system/workflow-runs/workflows
Frontend: AutomationsDashboardPage.tsx — Tabs, Backend-Paginierung, WorkflowsTab
DB-Migration: nein
Andere Komponenten: keine

Entscheidungen

Datum	Entscheidung	Begründung
2026-04-12	Neuer Endpunkt unter bestehendem Router `/api/system/workflow-runs` als `/api/system/workflow-runs/workflows`	Konsistenz mit bestehendem Prefix, kein neuer Router nötig
2026-04-12	RBAC-Permissions pro Workflow-Row vom Backend	Frontend muss nicht selbst RBAC-Logik duplizieren
2026-04-12	Bestehende `Tabs`-Komponente verwenden	Bereits vorhanden und getestet

Umsetzungs-Checkliste

API-Endpunkt: GET /api/system/workflow-runs/workflows
DB-Schema / Migration: nicht nötig (keine Änderung)
Frontend: Tabs-Struktur in AutomationsDashboardPage
Frontend: Dashboard-Tab mit Backend-Paginierung
Frontend: WorkflowsTab mit zentraler Workflow-Verwaltung
RBAC / Permissions: Scoping + per-row Permissions
Neutralisierung betroffen? Nein
Navigation / Routing: keine Änderung (Route /automations unverändert)
Billing-Impact? Nein

Akzeptanzkriterien

#	Kriterium (Given-When-Then)	Prio
1	Given User auf /automations, When Seite lädt, Then 2 Tabs sichtbar (Dashboard, Workflows)	must
2	Given Dashboard-Tab aktiv, When Daten laden, Then Metriken + Runs-Tabelle mit Backend-Paginierung	must
3	Given Workflows-Tab aktiv, When Daten laden, Then alle RBAC-berechtigten Workflows mit Mandant/Instanz-Spalten	must
4	Given Workflow mit Edit-Recht, When Zeile angezeigt, Then Edit/Delete/Rename/Execute-Aktionen sichtbar	must
5	Given Workflow ohne Edit-Recht, When Zeile angezeigt, Then nur View-Icon, keine Mutationsaktionen	must
6	Given Filter "Aktiv" gewählt, When Tabelle aktualisiert, Then nur aktive Workflows	should

Abschluss

b-reference/ aktualisiert — b-reference/gateway/automation.md (Abschnitt System-Automatisierung)
TOPICS.md — Verweis unter „Aktive Arbeiten“ ergänzt
Dieses Dokument → z-archive/ verschieben (nach Abnahme / wenn kein offenes Follow-up)

4.3 KiB Raw Blame History