PowerOn/wiki
3
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
wiki/implementation/doc_automation_templates_db_and_editor_concept.md
ValueOn AG 92c9e37f1e updated concept documents
2026-02-04 10:13:46 +01:00

14 KiB
Raw Blame History

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.