# Automation Templates in DB und Editor – Konzept ## Übersicht Templates werden von der Python-Datei in die Datenbank verschoben. Placeholders gehören nicht zum Template, sondern nur zur konkreten **Anwendung** (AutomationDefinition). Template-Liste und **CRUD auf Templates** (Anlegen/Ändern/Löschen) gemäss **RBAC** – Nutzer verwalten ihre **eigenen** Templates (z.B. MY-Level); SysAdmin macht nur den **Bootstrap** (initialer Seed). Im UI: **Verwaltung der Automation-Objekte** (bereits vorhanden) und ein **Automation Editor** mit Modus „Definition“ oder „Template“. --- ## 1. Datenmodell ### 1.1 Bestehend: AutomationDefinition (weiter nutzbar) - **Datei:** `gateway/modules/features/automation/datamodelFeatureAutomation.py` - **Tabelle:** `AutomationDefinition` (Namespace `data.automation`), RBAC bereits: MY-Level (user-owned). - **Felder (Auszug):** - `id`, `mandateId`, `featureInstanceId`, `label`, `schedule`, `active`, `eventId`, `status`, `executionLogs` - **`template`** (string): JSON des Workflow-Plans. Wird aus einem **AutomationTemplate** übernommen, wenn der User „Aus Template erstellen“ wählt – danach keine Referenz mehr, die Definition kann unabhängig weiterbearbeitet werden. Kann auch frei (ohne Template) gepflegt werden. - **`placeholders`** (Dict[str, str]): Nur hier – Werte für `{{KEY:name}}` bei der **spezifischen Anwendung**. Templates enthalten keine Placeholders. **Fazit:** AutomationDefinition bleibt zentrales Modell; **keine** `templateId`-Referenz. Beim Erzeugen aus einem Template wird der Template-Inhalt in die Definition kopiert; danach wird nur noch die Definition im Editor bearbeitet. Eine Definition kann ihrerseits **als neues Template gespeichert** werden – Berechtigung dazu gemäss **RBAC** (wer create auf AutomationTemplate hat). ### 1.2 Neu: AutomationTemplate (nur DB, ohne Placeholders) - **Zweck:** Vordefinierte Workflow-Vorlagen **ohne** Platzhalter. CRUD gemäss **RBAC** – Nutzer ihre eigenen (z.B. MY); Bootstrap (initialer Seed) nur durch SysAdmin/System. - **Vorschlag Felder:** - `id` (PK, UUID) - `label` (**MultiLanguage**, z.B. `{"en": "SharePoint Summary", "de": "SharePoint Zusammenfassung"}`): Anzeigename z.B. „SharePoint Themen Zusammenfassung“ - `overview` (**MultiLanguage**, optional): Kurzbeschreibung - **`template`** (string): JSON der Workflow-Struktur **mit** Platzhaltern im Format `{{KEY:placeholderName}}`. Enthält z.B. `overview`, `tasks` mit `actionList`, `execMethod`, `execAction`, `execParameters` (dort die Keys). Keine konkreten Werte für Placeholders – die kommen erst in AutomationDefinition.placeholders. - `_createdAt`, `_updatedAt`, `_createdBy` (Systemfelder, optional je nach bestehendem Muster) **Keine** `placeholders`-Spalte in AutomationTemplate. Placeholders existieren nur in AutomationDefinition bei der Nutzung eines Templates. ### 1.3 Beziehung (ohne Referenz) - Beim **„Aus Template erstellen“**: Inhalt von `AutomationTemplate.template` wird in eine **neue** AutomationDefinition kopiert (`template` + leere oder vorgeschlagene `placeholders`). Das **Label** wird in der **Sprache des aktuellen Users** übernommen (`definition.label = template.label[userLanguage]`). Es wird **keine** Referenz (templateId) angelegt – die Definition ist danach eigenständig und kann beliebig geändert werden. - Eine **bestehende AutomationDefinition** wird ausschließlich im Editor bearbeitet (template + placeholders). - **„Als Template speichern“**: Aus einer AutomationDefinition kann ein neues AutomationTemplate angelegt werden – Inhalt von `template` wird übernommen, **ohne** konkrete Placeholder-Werte (nur `{{KEY:...}}` bleibt). Berechtigung gemäss **RBAC** (wer create auf AutomationTemplate hat). --- ## 2. RBAC und Bootstrap ### 2.1 AutomationTemplate - **Bootstrap:** Beim ersten Start (oder Migration) werden die bisherigen Vorlagen aus `subAutomationTemplates.py` in die Tabelle **AutomationTemplate** eingespielt – **ohne scharfe Parameter** (keine konkreten Placeholder-Werte aus den bisherigen `parameters`-Blöcken). Nur die reinen Template-JSON-Strukturen mit `{{KEY:...}}`. - **RBAC:** Gemäss RBAC-System – Sichtbarkeit und **CREATE/UPDATE/DELETE** auf AutomationTemplate nach RBAC-Regeln (z.B. Nutzer können **ihre eigenen** Templates anlegen/ändern/löschen, MY-Level). SysAdmin nur für **Bootstrap** (initialer Seed der Vorlagen aus Python). - **UI-Context:** `ui.feature.automation.templates` – Sichtbarkeit und Aktionen (lesen, erstellen, bearbeiten, löschen) nach RBAC. ### 2.2 AutomationDefinition (unverändert) - SysAdmin: kann alle AutomationDefinition-Einträge sehen/bearbeiten (z.B. über bestehende RBAC-Logik mit mandateId/context). - User: nur eigene AutomationDefinition-Einträge (MY). Scheduling-Verwaltung: SysAdmin kann alle Schedulings bearbeiten, jeder User nur die eigenen Automations. --- ## 3. Backend-Logik ### 3.1 AutomationTemplate CRUD - **Neue API** unter z.B. `/api/automation-templates` (oder unter bestehendem Router mit Präfix). **Zugriff gemäss RBAC** – Nutzer sehen/bearbeiten/löschen nur ihre eigenen Templates (z.B. MY; Filter/Prüfung über `_createdBy` bzw. RBAC-Regeln für `data.automation.AutomationTemplate`). - `GET /api/automation-templates` – Liste (evtl. paginiert), gefiltert nach RBAC - `GET /api/automation-templates/{id}` – Einzelabruf (nur wenn berechtigt) - `POST /api/automation-templates` – Anlegen (wer create hat) - `PUT /api/automation-templates/{id}` – Aktualisieren (wer update auf diesen Eintrag hat) - `DELETE /api/automation-templates/{id}` – Löschen (wer delete auf diesen Eintrag hat) - **Bootstrap/Migration (nur SysAdmin/System):** Einmalig Daten aus `subAutomationTemplates.py` lesen, pro „template“-Eintrag einen AutomationTemplate-Datensatz anlegen (nur `label`/`overview` + JSON-`template` mit `{{KEY:...}}`, keine `parameters` speichern). Danach CRUD nur noch über RBAC. ### 3.2 Template-API und Sichtbarkeit - **GET /api/automations/templates** (bzw. neuer Endpoint für AutomationTemplate): Liste aus **DB** (AutomationTemplate). **Sichtbarkeit gemäss RBAC** – Nutzer sehen die Templates, auf die sie Zugriff haben (z.B. eigene + ggf. Gruppen); CREATE/UPDATE/DELETE über gleiche API, Berechtigung pro Request per RBAC. ### 3.3 Nutzbare Actions (Katalog, RBAC-gefiltert) - **Endpoint** z.B. `GET /api/automations/actions`: - **Datenquelle:** Pro Action die bestehende **WorkflowActionDefinition** nutzen (`actionId`, `description`, `parameters` mit Typ, `frontendType`, etc.) – diese Daten sind pro Action bereits verfügbar (Method-Basis / methodDiscovery). - **RBAC:** Nur Actions zurückgeben, für die der aktuelle User Berechtigung hat (RESOURCE-Context, `actionId` – z.B. `_checkActionPermission(actionId)`). So entsteht die „Übersicht aller nutzbaren Actions“ nach RBAC. - **Format:** Pro Action die Action-Definition ausliefern (actionId, description, parameters-Schema); optional ein **Beispiel-JSON-Snippet** pro Action (minimales action-Objekt: execMethod, execAction, execParameters, execResultLabel) für Copy/Paste ins Template-JSON. ### 3.4 JSON-Validierung und Placeholder-Extraktion - Beim Speichern einer AutomationDefinition im Editor (oder in einem separaten „Validate“-Schritt): - **JSON validieren:** `template`-String parsen, Syntax-Check; bei Fehler Meldung anzeigen. - **Placeholder-Extraktion:** Regex oder Parser über den `template`-String, alle Vorkommen von `{{KEY:placeholderName}}` sammeln und als vorgeschlagene Keys in `placeholders` anzeigen bzw. bestehende `placeholders` anpassen (neue Keys hinzufügen, nicht mehr vorkommende optional entfernen oder behalten). --- ## 4. UI – Admin-Seiten (frontend_nyla) ### 4.1 Seite: Verwaltung der Automation-Objekte und Scheduling (existiert) - **Route/Seite:** Bereits vorhanden (z.B. AutomationsPage, Route `automations`). - **Funktion:** Liste der AutomationDefinition-Einträge; Erstellen, Bearbeiten, Löschen, Ausführen, Logs. - **Berechtigung:** SysAdmin kann alle Automations und deren Scheduling bearbeiten; normale User nur die eigenen. Entspricht dem bestehenden MY-Level plus Admin-Logik (z.B. isSysAdmin sieht alle). ### 4.2 Seite: Automation Editor (neu) – ein Editor, zwei Modi - **Zweck:** Im Editor wird **entweder** ein **AutomationTemplate** bearbeitet **oder** eine **AutomationDefinition** erstellt/bearbeitet. Entscheidend ist ein **Modus-Flag** im Editor (nicht templateId). **Modus-Flag im Editor:** - **„Definition bearbeiten / neu erstellen“** (Standard für normale User): - Inhalt kommt aus einer bestehenden AutomationDefinition oder aus „Aus Template erstellen“ (dann wird Template-Inhalt in eine **neue** Definition kopiert). - Speichern → **AutomationDefinition** wird erstellt bzw. aktualisiert (template + placeholders). Keine Referenz zum Template. - **„Template bearbeiten“**: - Inhalt kommt aus einem AutomationTemplate (oder „Neu“ für leeres Template). Sichtbar/bearbeitbar gemäss **RBAC** (Nutzer nur eigene). - Speichern → **AutomationTemplate** wird erstellt bzw. aktualisiert. Keine placeholders im Template. - **„Als Template speichern“** (von einer Definition aus): Aus der aktuell geöffneten AutomationDefinition wird ein neues AutomationTemplate angelegt (nur template-JSON mit `{{KEY:...}}`, keine scharfen Werte). Erlaubt für Nutzer, die gemäss **RBAC** create auf AutomationTemplate haben. **Saubere Trennung:** Derselbe Editor (gleiche UI: JSON + Platzhalter-Key/Value + Actions-Katalog). Nur das Zielobjekt und die Speicher-Logik unterscheiden sich je nach Modus: Save schreibt entweder in AutomationDefinition oder in AutomationTemplate. Keine templateId nötig. **Editor-Funktionen (unabhängig vom Modus):** 1. **JSON bearbeiten (Text, Copy/Paste, Validierung)** - Großes Textfeld (oder Code-Editor) mit dem Inhalt von `template` (aus Definition oder Template). - Nach Bearbeitung: „Validieren“-Button oder beim Speichern: JSON parsen; bei Fehler Meldung anzeigen. - Nach Validierung: **Platzhalter anpassen** – aus dem JSON alle `{{KEY:xyz}}` extrahieren und in der Placeholder-Verwaltung als Keys anzeigen/aktualisieren. (Bei Template-Modus: Placeholder-UI nur zur Anzeige/Vorschau; gespeichert wird nur das Template ohne Werte.) 2. **Platzhalter als dynamische Key/Value-Objekte** - Liste aller in `template` vorkommenden Placeholder-Keys (aus Extraktion). - Pro Key: Wert eingeben. **Typ:** Aus der **Action-Definition** (WorkflowActionParameter, frontendType) der Action, in der der Key vorkommt. - Werte werden nur bei **Definition** gespeichert (`AutomationDefinition.placeholders`). Beim Template-Modus keine Werte persistiert. 3. **Übersicht nutzbarer Actions (RBAC)** - Bereich „Nutzbare Actions“: Daten von `GET /api/automations/actions` – pro Action die **Action-Definition** (actionId, description, parameters-Schema). - **Copy/Paste:** Pro Action ein JSON-Snippet (action-Objekt) anzeigen, Buttons „Copy JSON“ / „Insert at cursor“ zum Einfügen ins Template-JSON. **Navigation:** Von der Automations-Verwaltung: „Neu“ (leer oder „Aus Template erstellen“) bzw. „Bearbeiten“ → Editor im **Definitions-Modus**. Wer gemäss RBAC Templates verwalten darf: „Template bearbeiten“ / „Templates verwalten“ → Editor im **Template-Modus** oder Liste AutomationTemplate (nur eigene bzw. nach RBAC sichtbare). ### 4.3 Template-Verwaltung - **Seite:** „Templates verwalten“. Sichtbar/verfügbar gemäss **RBAC** – Nutzer sehen und verwalten **ihre eigenen** Templates (CRUD nach RBAC, z.B. MY). - **Inhalt:** CRUD für **AutomationTemplate**. Liste mit Bearbeiten/Neu/Löschen; beim Bearbeiten: `label`, `overview`, `template` (JSON mit `{{KEY:...}}`, ohne konkrete Placeholder-Werte). Template-Liste gefiltert nach Berechtigung („Aus Template erstellen“ nutzt dieselbe Liste). --- ## 5. Zusammenfassung | Thema | Inhalt | |------|--------| | **Datenmodell** | AutomationDefinition unverändert, **keine** templateId. Neu: AutomationTemplate (nur DB, ohne placeholders). Definition aus Template = Kopie des Inhalts; Definition kann als Template gespeichert werden. | | **Templates** | Von Python in DB; Bootstrap: nur Template-JSON mit `{{KEY:...}}`, **keine scharfen Parameter**. | | **Placeholders** | Nur in AutomationDefinition; nie im Template. | | **RBAC Templates** | Sichtbarkeit und CREATE/UPDATE/DELETE gemäss RBAC – Nutzer ihre **eigenen** Templates (z.B. MY); SysAdmin nur **Bootstrap** (initialer Seed). | | **RBAC Automations** | Unverändert: SysAdmin alle, User nur eigene (Scheduling + Definition). | | **Backend** | AutomationTemplate CRUD gemäss **RBAC** (Nutzer eigene); Bootstrap nur SysAdmin/System; GET nutzbare Actions mit **Daten pro Action-Definition** (WorkflowActionDefinition), RBAC-gefiltert; JSON-Validierung + Placeholder-Extraktion. | | **UI** | Verwaltung Automations + Scheduling (existiert); ein **Automation Editor** mit **Modus-Flag**: Template bearbeiten vs. Definition erstellen/bearbeiten; „Als Template speichern“ aus Definition (gemäss RBAC). | --- ## 6. Erledigte Klarstellungen - **Keine templateId:** Eine AutomationDefinition wird aus einem Template **erzeugt** (Inhalt kopiert), danach keine Referenz – die Definition wird im Editor bearbeitet und kann sich vom Template unterscheiden. Eine Definition kann ihrerseits **als neues Template gespeichert** werden – Berechtigung gemäss **RBAC**. - **Bootstrap:** Templates dürfen **keine scharfen Parameter** haben (nur `{{KEY:...}}`). **Nur SysAdmin/System** führt den initialen Bootstrap (Seed aus Python) aus; danach CRUD auf Templates **gemäss RBAC** (Nutzer ihre eigenen). - **GET nutzbare Actions:** **Daten pro Action-Definition** nutzen (WorkflowActionDefinition) – pro Action verfügbar. - **Template-Liste und CRUD:** Sichtbarkeit und CREATE/UPDATE/DELETE AutomationTemplate **gemäss RBAC** – Nutzer verwalten ihre **eigenen** Templates; SysAdmin nur Bootstrap. - **Editor sauber mit Modus-Flag:** Ein Flag im Editor steuert, ob ein **Template** oder eine **Definition** bearbeitet wird. Je nachdem schreibt Speichern in AutomationTemplate oder AutomationDefinition. „Als Template speichern“ erzeugt aus einer Definition ein neues Template – erlaubt für jeden mit RBAC-Recht create auf AutomationTemplate. Dieses Dokument kann als Basis für Implementierungs-Tickets (Backend: Modelle, API, Bootstrap; Frontend: Editor mit Modus, Template-Verwaltung) verwendet werden.