In unserer Beitragsserie „Arbeiten mit dem neuen GSBEditor/web“ haben Sie in meinen Beiträgen bisher über die neue Ablage, über die erweiterte Vorschau, über die Möglichkeiten des „Drag & Drop“ und über die Nutzung der veränderten Suchmöglichkeiten erfahren. In diesem Beitrag möchte ich Ihnen den zum GSBEditor/java etwas veränderten Umgang mit den Workflows zum Publizieren von Dokumenten nahebringen. Der Government Site Builder ist die Content-Management-Lösung des Bundes.
Grundlagen für die Workflows
Bevor ich Ihnen vorstelle, wie Sie die Workflows im GSBEditor/web bedienen, möchte ich Ihnen zunächst ein wenig Grundlagenwissen zum Thema Rollen, Rechte und Redaktionen vermitteln. Denn das ist ein Thema, zu dem ich auch in den Coachings bei den Redakteuren vor Ort oft befragt werde.
Die meisten von Ihnen wissen wahrscheinlich, dass jeder Nutzer im GSB eine „Grundausstattung“ an Regeln braucht, um dort vernünftig agieren zu können. Zu dieser Grundausstattung gehören eine Editorkonfiguration, mindestens eine Rechtegruppe und mindestens eine Rollengruppe.
In der Editorkonfiguration wird definiert, welche Dokumenttypen und welche Felder, innerhalb der Dokumenttypen, dem Redakteur in seiner Editoransicht zur Verfügung stehen. In den Rechtegruppen wird festgelegt,
- welche Dokumente der Redakteur im Verzeichnisbaum des Editors bearbeiten kann,
- wo er Dokumente nur Lesen darf und
- wo er Dokumente freigeben und publizieren darf.
Über eine Rollengruppe wird der Redakteur letztendlich einer Redaktion im Mandanten zugeordnet. Diese Zuordnung passiert in einer Redaktionsdefinition, in der festgeschrieben wird, welche Workflows der Redaktion und damit den einzelnen Redakteuren zur Verfügung stehen. Die Workflows stehen also nicht für sich alleine, sondern gehören zum Paket des Rollen- und Rechtekonzepts.
Wie Sie sehen, müssen einige Vorbereitungen getroffen werden, bevor das Arbeiten mit Workflows für die Redakteure wie gewünscht möglich ist. Wurden die Rechte und Rollengruppen aller Nutzer korrekt und zueinander kompatibel eingerichtet, steht dem Redakteur eine Auswahl an Workflow-Varianten (2-Augen, 4-Augen, depublizieren, publizieren etc.) genau für den von ihm verantworteten Bereich zur Verfügung.
Diese Voreinstellungen gelten übrigens unabhängig davon, ob Sie mit dem GSBEditor/web oder GSBEditor/java arbeiten.
So bedient man Workflows im GSBEditor/web
Nun zurück zum Hauptthema, denn ich will Ihnen ja zeigen, wie sich das Bearbeiten der Workflows im GSBEditor/web „anfühlt“. Ich setzte nun voraus, dass der Redakteur seine Dokumente soweit fertig bearbeitet und zurückgegeben hat und jetzt die Publikation des Dokuments anstoßen möchte.
In der Dokumentenansicht gibt es oben links ein Klappmenü, dessen erster Punkt meistens „Dokument publizieren“ heißt. Wenn Sie dieses Klappmenü öffnen, sehen Sie abhängig vom aktuellen Publikationsstatus des Dokuments die Punkte „Dokument depublizieren“, „Dokument freigeben“, „Dokument zurückziehen“ und dann die Workflows, die Sie für dieses Dokument starten könnten. Im Beispiel sind dies unterhalb der Überschrift „neuer Workflow“ folgende: „Publizieren (4-Augen)“und „Depublizieren (4-Augen)“. Zusätzlich finden Sie unten noch eine Überschrift „bestehenden Workflow erweitern:“. Hier gibt es zunächst keine weitere Auswahlmöglichkeit; auf die Details dieses Punkts komme ich später zurück.
Die ersten vier Punkte des Klappmenüs bilden quasi 1:1 die Schaltflächen zur Direktpublikation im GSBEditor/java ab (Stichworte dazu sind „Grüner Haken“ und „Grüner Ball“.) Redakteure, die nur über Workflows arbeiten müssen, sollten diese Auswahlpunkte eigentlich nicht haben. Jedoch ist die Grundkonfiguration im GSBEditor/web momentan so, dass alle Redakteure diese Optionen zur Verfügung gestellt bekommen würden. Das bedeutet, dass dieser Umstand bei der Absprache zum Rollen- und Rechtekonzept berücksichtigt und dass der GSBEditor/web für den Mandaten ggf. umkonfiguriert werden muss.
Klappmenü zum Aufruf eines Workflows
Nach einem Klick auf einen Workflow, ich gehe mal von „Publizieren (4-Augen)“ aus, werden Sie sich zunächst wundern, dass scheinbar nichts passiert. Als Nutzer des bisherigen GSBEditor/java erwarten Sie eigentlich, dass sich irgendwo ein Workflow-Fenster öffnet. Das ist beim GSBEditor/web aber nicht der Fall! Das heißt für Sie, dass Sie nun Eigeninitiative zeigen und selbst das Workflow-Fenster im Editor anklicken müssen. Ich bin mir aber sicher, dass Sie sich daran gewöhnen werden.
Im Workflow-Fenster erwartet Sie dann ein einigermaßen bekannter Anblick, nämlich die gleiche Aufteilung wie im GSBEditor/java, mit den Reitern „Eigener Workflow“, „Angebotene Aufgaben“ und „Eigene Aufgaben“. Nur eben nicht untereinander sondern als Reiter im linken Bereich. Ich denke, dass diese Darstellungsvariante für eine größere Anzahl von aktiven Workflows übersichtlicher ist, aber die Wahrscheinlichkeit, dass ein Fachredakteur eben diese größere Anzahl an Workflows hat, ist aus meiner Sicht eher klein.
Wie bisher auch, wählen wir im Reiter „Eigene Aufgaben“ die Aufgabe „Erstellen“ zum gerade gestarteten Workflow aus und haben nun die Möglichkeit, über die Schaltfläche „Dokument hinzufügen“ weitere Dokumente in diesen Workflow mit aufzunehmen. Diese Funktion dient dazu, alle anderen geänderten bzw. neu erstellten Dokumente, die zum Artikel gehören, im Paket publizieren zu können.
Leider gibt es an dieser Stelle keine Unterstützung durch eine Drag & Drop-Funktionalität. Auch die Funktion „vervollständigen“ aus dem GSBEditor/java steht uns hier leider nicht zur Verfügung. Sie müssen jedoch nicht jedes Dokument einzeln aus dem Verzeichnisbaum zusammenklicken, sondern können im Auswahlfenster Dokumente direkt aus der Ablage oder aus der Suche heraus einfügen.
An dieser Stelle will ich kurz auf die weiter oben erwähnte Überschrift „bestehenden Workflow erweitern:“ zurückkommen. Denn wenn Sie einen Workflow gestartet haben, finden Sie in der Dokumentenansicht beim Aufklappen des Menüs unter „Dokument publizieren“ unterhalb der Überschrift den Workflow, den wir gerade gestartet haben. Dort steht ein Eintrag wie „Publizieren (4-Augen) – coremedia …….“, mit dem Sie auf den ersten Blick nichts anfangen können.
„Publizieren (4-Augen)“ zeigt uns aber an, dass es um einen Workflow zum Publizieren geht, und die Nummer nach „coremedia:///“ gibt an, um welchen unserer Workflows es sich genau handelt. Vergleichen wir die dort angezeigten Nummernfolgen mit den Nummernfolgen unserer Workflows in der Workflow-Übersicht, können wir eindeutig den Workflow bzw. die Workflows finden, die damit gemeint sind.
Wenn wir bei einem Dokument den nun angebotenen Menüpunkt anklicken, wird das Dokument unserem Workflow hinzugefügt. Diese Funktion können wir z. B. sehr gut nutzen, wenn wir in der Dokumentenansicht noch alle frisch bearbeiteten Dokumente offen haben. Denn dann können wir die Dokumente schnell durchgehen und bei jedem Dokument den für uns richtigen bestehenden Workflow wählen und somit auch relativ zügig den Workflow händisch mit allen Dokumenten vervollständigen.
Die bisherige Unterscheidung im GSB zwischen einem „normalen“ und einem „zeitgesteuerten“ Workflow gibt es übrigens seit GSB 7 nicht mehr. Alle Workflows haben jetzt ein Feld „Publikationszeit“, das mit dem Zeitpunkt des Workflowstarts vorbelegt ist. Das bedeutet für Sie, dass Sie die Datums- und Zeitangabe in diesem Feld entsprechend anpassen müssen, wenn das Dokument erst in z. B. 48 Stunden live gehen soll und nicht sofort. Der Vollständigkeit halber ist noch die Schaltfläche „jetzt publizieren“ zu erwähnen, mit der Sie den Publikationszeitpunkt auf den aktuellen Tag und die aktuelle Uhrzeit (zurück)setzen können.
Wenn Sie alle Dokumente zusammengestellt haben, können Sie auf die Schaltfläche „zum Freigeben“ am rechten unteren Rand des Workflow-Fensters klicken und die Dokumente zur Freigabe an den oder die Chefredakteure weiterschicken. Und hier endet der Part des „Fachredakteurs“ in meinem Beispiel des „Publizieren (4-Augen)“-Workflows und das zweite Augenpaar muss nun übernehmen.
Die Sicht der Chefredakteure ist ebenfalls ähnlich zum GSBEditor/java aufgebaut. Als Chefredakteur finden Sie die Workflows, die Sie freigeben sollen, im mittleren Reiter „Angebotene Aufgaben“. Nach einem Klick auf eine der angebotenen Aufgaben und einem weiteren Klick auf die Schaltfläche „Annehmen“ rechts unten im Workflow-Fenster, können Sie dann die Weiterbearbeitung des 4-Augen-Workflows übernehmen. Die angebotene Aufgabe wird dazu automatisch auf den Reiter „Eigene Aufgaben“ verschoben.
Nachdem der Chefredakteur alle Dokumente des Workflows einzeln in der Dokumentenansicht kontrolliert hat, leitet er mit einem Klick auf die Schaltfläche „zum Publizieren“ den letzten Schritt des Workflows, die automatische Publikation der Dokumente, ein.
Klickt der Chefredakteur jedoch auf die Schaltfläche „zurück zum Erstellen“, wird der Workflow zum Redakteur zurückgeleitet. Falls er das tut, sollte er zumindest in den zur Verfügung stehenden Feldern einen Kommentar dazu schreiben, oder – was ich besser finde – den Kollegen kurz darauf ansprechen, warum das Dokument so nicht publiziert werden kann.
In diesem Zusammenhang noch der Hinweis, dass wir jederzeit die Versionen der in den Workflow aufgenommenen Dokumente ändern können. Als Beispiel dazu will ich einen „Klassiker“ beschreiben:
Sie haben den Workflow schon mit der Versionsnummer 8 des Dokuments gestartet. Erst dann fällt Ihnen auf, dass da noch ein Tippfehler im Text ist, den Sie natürlich sofort korrigieren und damit Version 9 des Dokuments erstellen. Um nicht einen neuen Workflow mit Version 9 starten zu müssen, können Sie im Workflow-Fenster die Version des Dokumentes im Workflow von Version 8 auf 9 ändern und dann den Workflow wie geplant weiter bearbeiten.
Die Schaltfläche „Zurückgeben“, im linken unteren Bereich des Workflow-Fensters, dient übrigens dazu die Aufgabe wieder an den Pool der angebotenen Aufgaben zurückzugeben, falls Sie versehentlich eine Aufgabe angenommen haben.
Abschluss und Ausblick
Ich hoffe, dass es mir mit diesem Artikel gelungen ist, Ihnen den Umgang mit Workflows im GSBEditor/web nahe zu bringen. Dem GSBEditor/web gehört die Zukunft, und deshalb war es mir ein Anliegen, Ihnen einige der aktuellen Funktionen näher zu erläutern. Den positiven Rückmeldungen zufolge, die mich seit Veröffentlichung des ersten Artikels erreicht haben, scheint dies bisher gelungen zu sein. Fairerweise möchte ich hier aber auch erwähnen, dass der GSBEditor/web in seinem jetzigen veröffentlichten Entwicklungsstand noch nicht alle Funktionen, die wir aus dem GSBEditor/java kennen, abdeckt. Aber: in zwei Jahren kann und wird noch eine Menge passieren!
Mit diesem Artikel beende ich die aktuelle Miniserie zum GSBEditor/web. Als nächstes werde ich Ihnen das GSB Adminportal vorstellen, das ebenfalls mit dem GSB 7 neu dazugekommen ist. Da ich Sie in diesem Artikel schon in das Rollen- und Rechtekonzept des GSB eingeführt habe, werde ich dieses Thema in meinem ersten Artikel der neuen Miniserie zum GSB Adminportal aufgreifen. Mit der neuen Miniserie werde ich Ihnen einige der administrativen Prozesse im Adminportal nahe bringen.
