Files
Laufzettel/docs/issues/004-epic-phase-4.md
T
Florian WildeandClaude Opus 5 abacad1cb7
Prüfung / pruefung (push) Canceled after 0s
Prüfung / pruefung (pull_request) Canceled after 0s
Prüfung / e2e (push) Canceled after 0s
Prüfung / e2e (pull_request) Canceled after 0s
feat(vorlagen): Versionierung, Unveraenderlichkeit und JSON-Austausch
Eine veroeffentlichte Vorlagen-Version ist fuer immer unveraenderlich — daran
haengt, dass ein archivierter Lauf in zehn Jahren noch genau die Schritte zeigt,
mit denen er gestartet wurde. Die Regel steht deshalb zweimal: im Service, der
die verstaendliche Meldung gibt, und in der Datenbank, die die Garantie gibt.
Vier Trigger fangen Schreibzugriffe ab, die nicht durch den Service kommen —
Migrationen, psql, der Seed und ab Phase 4 die Connectoren — und versperren den
Rueckweg nach ENTWURF, der alles andere ausgehebelt haette.

- Service: anlegen, Kopfdaten bearbeiten, Entwurf als tiefe Kopie der letzten
  veroeffentlichten Version, speichern, veroeffentlichen, verwerfen,
  duplizieren, archivieren
- Hoechstens ein Entwurf je Vorlage, durchgesetzt vom partiellen Index; zwei
  gleichzeitige Klicks auf „Bearbeiten“ bekommen denselben Entwurf statt eines
  Fehlers
- Optimistisches Sperren ueber geaendertAm: wer auf einem ueberholten Stand
  speichert, wird abgewiesen statt die Arbeit des anderen spurlos zu ersetzen
- JSON-Export und -Import samt Format-Dokumentation; der Export ist nachsichtig,
  der Import streng
- src/lib/validierung.ts als einzige Zod-Quelle mit deutschen Meldungen, per
  ESLint-Regel erzwungen

Der unabhaengige Review fand drei Blocker, alle an der Mandantengrenze: der
Suchfilter brachte ein zweites OR mit und ueberschrieb die Kundenbedingung,
Historie und Aufbau einer Version filterten gar nicht. Zu queries/vorlagen.ts
gab es keinen Test — jetzt gibt es tests/vorlagen-sicht.test.ts.

428 Tests gruen (vorher 336).

Schliesst #009

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-25 08:09:21 +02:00

1.9 KiB
Raw Blame History

#004 Phase 4: Aktionen, Connectors, REST-API

Status: offen Meilenstein: v0.4.0 Labels: phase-4 Geschätzt: – Tatsächlich: –

Ziel

Nicht im MVP umsetzen. Der Weg dorthin wird im MVP aber bewusst freigehalten: Die in den Vorlagen vorbereiteten PowerShell-Befehle sind die Vorstufe von Schritten, die die App selbst ausführt.

Aufgaben

  • Schritt-Typ AKTION mit Connector und Parametern aus Variablen und Person
  • Connectors: LDAP/AD schreibend über eigenes Dienstkonto, Microsoft Graph (Entra ID, Exchange Online, Intune), authentik-API, später Ticketsystem und RMM
  • Onboarding als Aktion: Konto anlegen, Initialpasswort erzeugen und sicher übergeben, Gruppen laut Abteilung, Postfach und Lizenz
  • Offboarding als Aktion: Konto sperren, Sitzungen widerrufen, Postfach in Shared Mailbox wandeln
  • Vorschau „das wird passieren“, ausdrückliche Bestätigung, Ergebnis-Log am Schritt, Rollback-Hinweis
  • Fehler setzen den Schritt auf FEHLGESCHLAGEN mit Meldung
  • Berechtigung je Connector und Rolle, Geheimnisse verschlüsselt, alle Aufrufe im Protokoll
  • Wiederkehrende Läufe (v0.5.0)
  • REST-API und Webhooks, Start aus Ticketsystem und Wartungsplaner (v0.5.0)
  • Zeiterfassung je Lauf, automatische Prüfschritte per RMM-API, Auswertungen, Aufbewahrungsfristen, NFC-Tags (v0.5.0)

Vorleistung im MVP

  • SchrittTyp ist ein Enum, dem AKTION ohne Migration bestehender Daten hinzugefügt werden kann; konfig (Json) trägt dann Connector und Parameter
  • Schrittergebnis.wert ist ein Json, das ein Aktionsergebnis mit Log, IDs und Zeitstempeln aufnimmt
  • Kein Codepfad nimmt an, dass ein Schritt nur von einem Menschen erledigt wird — aktualisiertVonId ist optional und ein Systemlauf ist darstellbar
  • Das Krypto-Modul für das LDAP-Bind-Passwort (#006) ist schon der Platz für Connector-Geheimnisse
  • NFC nutzt dieselbe URL {APP_URL}/t/{tagCode} wie der QR-Code