Architecture Decision Record · 0026

Vacancy-Ausschluss aus dem Editorial-Workflow

Entscheidung. Der Content-Moderation-Workflow (draft → in_review → published) wird für node.blog und node.page eingeführt. node.vacancy bleibt ausgeschlossen, weil Stellenanzeigen vollautomatisch per XML-Migration (solcom_vacancy) importiert und direkt mit status: 1 publiziert werden. Ein manueller Review-Pfad würde diesen Import blockieren.

Kontext

Im Rahmen von P2503-105 wird ein Hard-Review-Workflow für die SOLCOM-Website eingeführt: Redakteure (content_editor) reichen Entwürfe zur Freigabe ein, eine neue Rolle content_manager approved und veröffentlicht. Direkte Draft → Published Transitionen sind blockiert. Zeitgesteuerte Veröffentlichung ist nur aus dem Zustand in_review heraus möglich.

Die Website hat drei Node-Types: blog, page (inkl. Canvas-Pages) und vacancy. Bei der Frage, ob alle drei in den Workflow aufgenommen werden sollen, wurde die Migration migrate_plus.migration.solcom_vacancy analysiert.

Befund: Die Migration bezieht Stellenanzeigen aus einem externen XML-Feed (data_fetcher_plugin: http, data_parser_plugin: xml) und setzt status: constants/status mit dem Wert 1 — direkt publiziert, ohne Moderation. Würde vacancy in den Workflow aufgenommen, würden importierte Stellenanzeigen im Zustand draft landen und nie automatisch live gehen.

Die Migration hat keinen moderation_state-Mapping-Schritt. Ein nachträglicher Einbau wäre möglich, erfordert aber Kenntnis des externen Feed-Schemas und birgt das Risiko, laufende Imports zu unterbrechen.

Entscheidung

node.vacancy wird nicht in den basic_editorial-Workflow aufgenommen. Der Content-Moderation-Workflow gilt ausschließlich für node.blog und node.page. Die Migration solcom_vacancy bleibt unverändert und importiert Stellenanzeigen weiterhin direkt als published.

Begründung: Stellenanzeigen sind systemgenerierte Inhalte — Verantwortung liegt beim externen ATS, nicht beim Redakteur. Ein manueller Review-Pfad würde keinen Qualitätsmehrwert bringen, aber den automatischen Import blockieren.

Rejected alternatives

Vacancy in Workflow mit angepasster Migration: Die Migration würde moderation_state: published direkt setzen (bypassed Review). Technisch machbar, aber semantisch inkonsistent — Hard-Review wäre für Vacancies eine Hülle ohne Inhalt. Außerdem: jede Änderung an der Migration erhöht das Risiko bei zukünftigen Feed-Änderungen.
Eigener leichter Workflow für Vacancy (Draft → Published, ohne Review): Trennt die Modellierung sauber, verdoppelt aber den Konfigurationsaufwand und erzeugt eine parallele Workflow-Welt, die Redakteure verwirrt, wenn sie versehentlich manuell eine Vacancy anlegen.

Consequences

Die Migration solcom_vacancy läuft ohne Änderung weiter — kein Migrations-Risiko, kein Deploymentstress.
Manuell angelegte Vacancies (außerhalb der Migration) unterliegen keinem Workflow — sie sind sofort publizierbar. Das ist ein bewusstes Restrisiko: die Annahme ist, dass manuelle Vacancy-Erstellung kein realer Anwendungsfall ist.
Wenn das externe ATS-System künftig ersetzt oder die Migration auf eine API-Basis umgestellt wird, sollte dieser ADR erneut bewertet werden — dann ist der Einbau von moderation_state in die Migration der richtige Zeitpunkt.
Die Workflow-Konfiguration workflows.workflow.basic_editorial listet vacancy nicht unter entity_types.node — das ist der kanonische Anker für diese Entscheidung.