PRD · P2503-105 · Konfigurationen

Publishing Workflows Konfiguration

Scope. Einführung eines Hard-Review-Editorial-Workflows für node.blog und node.page: vier Zustände (Draft → In Review → Published / Unpublished), neue Rolle content_manager als Freigeber, zeitgesteuerte Veröffentlichung via Scheduler aus dem Zustand in_review. node.vacancy bleibt ausgeschlossen (ADR-0026). Reine Drupal-Konfiguration — kein Custom-PHP.

Problem Statement

Redakteure können aktuell Inhalte direkt publizieren — ohne zweite Kontrollinstanz. Es gibt keinen strukturierten Review-Prozess, kein Vier-Augen-Prinzip und keine Möglichkeit, Inhalte zu einem geplanten Zeitpunkt automatisch live zu schalten. Fehlerhafte oder ungekürzte Inhalte gelangen direkt auf die öffentliche Website.

Zusätzlich fehlt ein klarer Pfad für Soft-Delete: unerwünschte Inhalte können nur vollständig gelöscht werden, nicht in einen Papierkorb verschoben werden, aus dem eine Wiederherstellung möglich wäre.

Solution

Einführung eines vierstufigen Hard-Review-Workflows auf Basis von Drupal Content Moderation. Inhalte durchlaufen zwingend die Stufe in_review bevor sie publiziert werden können. Eine neue Rolle content_manager trägt die Freigabe-Verantwortung. Der Scheduler erlaubt zeitgesteuerte Veröffentlichung aus der Review-Stufe heraus. Das Trash-Modul bleibt aktiv für Soft-Delete mit rollenbasierter Löschbefugnis.

Die Lösung ist vollständig konfigurationsbasiert — kein Custom-Code nötig. Bestehende publizierte Inhalte erhalten automatisch den Moderation-Status published.

User Stories

Als content_editor möchte ich einen neuen Inhalt als Entwurf (draft) anlegen, damit ich ihn ohne sofortige Veröffentlichung bearbeiten kann.
Als content_editor möchte ich einen fertigen Entwurf zur Review einreichen (submit_for_review), damit ein Freigeber ihn prüfen kann.
Als content_editor möchte ich eigene Drafts löschen (Soft-Delete in den Papierkorb), damit ich Fehlversuche bereinigen kann, ohne andere Inhalte zu gefährden.
Als content_editor möchte ich keinen direkten Publish-Button sehen, damit die Versuchung entfällt, den Review-Prozess zu umgehen.
Als content_manager möchte ich eingereichte Inhalte (in_review) prüfen und entweder freigeben (publish) oder zur Überarbeitung zurückschicken (request_changes).
Als content_manager möchte ich beim Freigeben ein zukünftiges Publish-Datum setzen können, damit Inhalte zeitgesteuert ohne manuelles Eingreifen live gehen.
Als content_manager möchte ich einen publizierten Inhalt auf unpublished setzen können, damit ich ihn kurzfristig aus dem öffentlichen Auftritt nehmen kann.
Als content_manager möchte ich unpublished Inhalte wieder zur Bearbeitung freigeben (create_new_draft), damit sie den vollen Review-Zyklus erneut durchlaufen.
Als content_manager möchte ich beliebige Inhalte löschen (Soft-Delete), damit ich als Freigeber auch Inhalte anderer Redakteure bereinigen kann.
Als administrator möchte ich alle Transitionen ausführen können, damit ich im Notfall eingreifen kann ohne Rollenwechsel.
Als Redakteur möchte ich eine klare Übersicht der Inhalte im Status in_review sehen, damit ich weiß, was auf Freigabe wartet.
Als Redakteur möchte ich eine Übersicht geplanter Veröffentlichungen sehen (Scheduler-Views), damit ich den Redaktionskalender überblicken kann.
Als Redakteur möchte ich, dass Stellenanzeigen (vacancy) weiterhin automatisch importiert und direkt publiziert werden, damit der Recruiting-Prozess nicht durch den Editorial-Workflow blockiert wird.

Implementation Decisions

Modul 1 — Editorial Workflow Config

Die bestehende Konfiguration workflows.workflow.basic_editorial wird um den Zustand in_review erweitert. Bestehende Zustände (draft, published, unpublished) bleiben erhalten. Der Default-Zustand bleibt draft.

Zustand	published	default_revision
`draft`	false	false
`in_review`	false	false
`published`	true	true
`unpublished`	false	true

Transition	Von	Nach	Rollen
`submit_for_review`	draft	in_review	content_editor, content_manager, administrator
`request_changes`	in_review	draft	content_manager, administrator
`publish`	in_review	published	content_manager, administrator
`unpublish`	published	unpublished	content_manager, administrator
`create_new_draft`	unpublished, published, draft	draft	content_editor (eigene), content_manager, administrator

Entity-Types im Workflow: node.blog, node.page. node.vacancy bleibt ausgeschlossen (siehe ADR-0026).

Modul 2 — Neue Rolle content_manager

Neue Drupal-Rolle content_manager mit folgenden Berechtigungen: Ausführen aller Workflow-Transitionen (publish, request_changes, unpublish, create_new_draft), Zugriff auf Scheduler-Datumsfeld, Löschen beliebiger Nodes (Trash). Die Rolle ist nicht privilegiert für User-Management oder Site-Konfiguration.

Modul 3 — Scheduler Integration

Modul scheduler_content_moderation_integration muss aktiv sein. Scheduler wird für node.blog und node.page aktiviert (default_publish_enable: true). Das Scheduler-Datumsfeld wird nur für Rollen mit Publish-Berechtigung angezeigt — content_editor sieht es nicht (via Field-Permissions oder Form-Display-Konfiguration). Scheduling ist konzeptuell nur aus in_review sinnvoll, da nur content_manager Publish-Zugang hat.

Modul 4 — Trash-Berechtigungen

content_editor erhält die Berechtigung, eigene Nodes zu löschen (Soft-Delete in den Papierkorb). content_manager und administrator können beliebige Nodes löschen. Auto-Purge bleibt deaktiviert.

Bestandsinhalt

Beim Hinzufügen von node.blog und node.page zum Workflow setzt Drupal automatisch moderation_state: published für alle bereits publizierten Inhalte. Kein manueller Migrations-Aufwand.

Alle vier Module sind reine Drupal-Konfiguration (YAML). Kein Custom-PHP, keine Modul-Entwicklung. Die Konfiguration wird über config/sync/ versioniert und via drush cim deployed.

Testing Decisions

Ein guter Test prüft ausschließlich das externe Verhalten — welche Transitionen welche Rollen ausführen können — nicht die interne YAML-Struktur. Tests sollen gegen eine laufende Drupal-Instanz laufen (kein Mock des Workflow-Systems).

Zu testende Module

Workflow-Transitionen: Jede Transition wird einmal als berechtigte Rolle und einmal als nicht-berechtigte Rolle ausgeführt. Erwartet: berechtigte Rolle → Erfolg, nicht-berechtigte → Access Denied.
Hard-Review-Gate: content_editor versucht direkt Draft → Published zu springen. Erwartet: keine solche Transition verfügbar.
Scheduler-Feld-Sichtbarkeit: content_editor sieht kein Publish-Datum-Feld im Node-Edit-Form. content_manager sieht es.
Trash-Berechtigungen: content_editor löscht fremden Draft — erwartet: Access Denied. content_editor löscht eigenen Draft — erwartet: Erfolg.
Vacancy-Unberührtheit: vacancy-Node kann direkt publiziert werden (kein Moderation-Gate). Migration läuft unverändert durch.

Prior Art

Im Repo existieren keine bestehenden Workflow-Tests. Referenz: Drupal Core Content Moderation Tests (core/modules/content_moderation/tests/) als Muster für rollenbasierte Transition-Tests.

Out of Scope

E-Mail-Benachrichtigungen bei Statuswechsel (kein Notification-Modul im Scope).
Workflow für Media-Entities (Bilder, Dokumente bleiben ohne Moderation).
Workflow für node.vacancy — explizit ausgeschlossen, ADR-0026.
Benutzerdefinierte Workflow-States über die vier definierten hinaus.
Revisions-Diff-UI (kein Diff-Modul im Scope).
Auto-Purge im Trash (bleibt deaktiviert per Entscheidung).

Further Notes

Der Workflow-Name im Config bleibt basic_editorial — kein Rename, um bestehende Config-Referenzen stabil zu halten.
Scheduler-Views (views.view.scheduler_scheduled_content) sind bereits in der Config vorhanden und können direkt als Redaktions-Kalender genutzt werden.
Die Scheduler-Views für Taxonomy-Terms (views.view.scheduler_scheduled_taxonomy_term) und Media (views.view.scheduler_scheduled_media) können vorerst deaktiviert oder ausgeblendet werden, da Moderation nur für Nodes aktiviert wird.
Wenn das externe ATS-System künftig ersetzt wird, sollte ADR-0026 erneut bewertet werden (Einbau von moderation_state in die Vacancy-Migration).