Formtest Entwicklerdoku

Appearance

Routing-Middleware ​

Die zentrale Workflow-Middleware ist app/middleware/determiner.ts. Sie leitet Einstiege aus Query-Parametern auf die richtige Route und erzwingt Zugriffsregeln für Signatur- und Finalisierungsschritte.

Die eigentliche Workflow-Guard-Logik für Signatur und Finalize liegt seit der Zentralisierung in app/utils/protocolWorkflow.ts. Die Middleware verwendet diesen Helper für Step-Zielpfade, Setup-Load und blockierende Validierungs-Redirects.

Hauptaufgaben ​

  • leitet vertragsbasierte Einstiege nach /create um
  • leitet ungültige Einstiegssituationen nach /history um
  • lädt den Acceptance-Zustand vor, wenn eine acceptance-Query vorhanden ist
  • verhindert Bearbeitung gesperrter Acceptances in / und /customer-view*
  • erlaubt /finalize nur für gesperrte Acceptances oder einen expliziten finalizeMode-Start
  • leitet zurück in den Editor, wenn die Kündigungsgrund-Validierung den nächsten Schritt blockiert

Query-gesteuerter Einstieg ​

?acceptance=<id> ​

  • lädt den Acceptance-Zustand über useAcceptanceStore()
  • prüft über dirtyHelpers.hasDirtyForAcceptance(), ob lokale Dirty-Daten vorhanden sind
  • entscheidet vor dem Routing, ob ein Server-Sync erzwungen werden soll

?contract=<id> ​

  • leitet nach /create um

?contract=<id>&type=<id> ​

  • leitet nach /create um und behält beide Query-Parameter bei

Keine unterstützte Query ​

  • leitet nach /history um

Verhalten bei gesperrten Acceptances ​

Die Middleware behandelt die folgenden Pfade für Lock-Prüfungen als Bearbeitungspfade:

  • /
  • /customer-view
  • /customer-view/signatures

Wenn die Acceptance-Metadaten einen gesperrten Zustand anzeigen, werden diese Routen nach /finalize umgeleitet.

Antwortet die Metadatenabfrage für GET /acceptance/<id> mit 404 oder 410, entfernt die Middleware die lokale Kopie der Acceptance und leitet nach /history?missingAcceptance=<id> um. Die Historie zeigt dazu ein Info-Modal. Dadurch werden weder Editor noch Kundenansicht mit veralteten IndexedDB-Daten gerendert.

Zugriffsschutz für Finalize ​

/finalize darf nur direkt geöffnet werden, wenn eine der folgenden Bedingungen erfüllt ist:

  • die Acceptance ist durch lockedAt finalisiert,
  • die Acceptance ist durch uploadPendingAt für manuellen Upload vorgemerkt, oder
  • die Route enthält einen gültigen Startmodus finalizeMode=auto|manual, der von der Signaturseite gesetzt wird

Wenn keine dieser Bedingungen erfüllt ist, leitet die Middleware nach /customer-view/signatures um.

Der Finalize-Modus ist nur ein kurzlebiger Routenparameter. Der fachliche Status bleibt Acceptance-Metadata und wird über app/utils/acceptanceStatus.ts ausgewertet.

Validierungs-Redirects ​

Bevor /customer-view/signatures oder /finalize erlaubt wird, startet die Middleware den Validierungsfluss für den Kündigungsgrund über resolveProtocolWorkflowBlockRedirect(...) aus app/utils/protocolWorkflow.ts.

  • das Setup wird bei Bedarf geladen
  • terminationReasonStore.markValidationAttempted() wird ausgelöst
  • terminationReasonStore.getValidationBlock(step) entscheidet, ob der nächste Schritt blockiert wird
  • blockierte Navigation leitet nach / um und ergänzt die Query aus createProtocolValidationBlockQuery(...)

Die Zielpfade der Workflow-Schritte (/customer-view/signatures und /finalize) werden ebenfalls zentral über getProtocolWorkflowStepPath(...) beschrieben, statt mehrfach als Literale verteilt zu sein.