Zielgruppe Site AdminVersion: GSB10.0Workflows

Ihre Hauptaufgaben liegen in der Steuerung des Ablaufs der einzelnen Arbeitsschritte und der Koordination der Nutzer. Ein Workflow bzw. ein Workflow-Template beschreibt eine Schablone für den Veröffentlichungsprozess. Die konkrete Ausprägung dieser Schablone wird „Job“ genannt. Beim GSB ermöglichen Workflows einen automatisierten Ablauf der Publikations- und Depublikationsprozesse.

Verfügbare Workflows

Der GSB liefert „technische Default-Workflows“, die auf Basis der „Default-Gruppen“ definiert sind. Die Implementierung dieser Workflows ist für alle Mandanten identisch. Um die Wünsche eines Mandanten zu berücksichtigen, können die Workflows mit mandantenspezifischen Konfigurationen parametrisiert werden. Somit sind zentrale Anpassungen und Korrekturen der Workflows einfach möglich, da lediglich die einmalig zentral vorliegenden Workflow-Definitionen und nicht alle Workflows innerhalb der einzelnen Mandanten modifiziert werden müssen.

Die verfügbaren GSB Workflows werden im Workflow-Konzept ausführlich beschrieben. Die im Folgenden beschriebenen Beispiele basieren auf den 2- und 4-Augen-Workflows des GSB. Ergänzende Angabe und Rollen für alle anderen Workflows finden Sie im Workflow-Konzept.

Rollengruppen

Ähnlich wie bei Dokumenten innerhalb des CMS, gibt es auch bei Workflows verschiedene Rechte, die verschiedenen Rollen zugeordnet werden können. CoreMedia sieht innerhalb von Workflows folgende Rechte vor:

• compose (erstellen)
• approve (freigeben)
• publish (publizieren)

Diese drei Rechte werden direkt auf die drei Standard-Rollen eines Workflows abgebildet. Die Rollen-Namen orientieren sich an den mit den Rollen verbundenen Rechten:

• Composer-Rolle
• Approver-Rolle
• Publisher-Rolle

Darüber hinaus ist im GSB die zusätzliche Rolle

• Supervisor-Rolle

eingeführt, mit der die Zuweisung im 2-Augen-Workflow vorgenommen wird. Diese Rolle fasst im Falle des 2-Augen-Workflows Composer, Approver und Publisher zusammen.

Diesen in den Workflows definierten Rollen werden in den Redaktionsdefinitionen konkrete Benutzergruppen zugewiesen, um für die damit verbundenen Benutzer die Freischaltungen für die entsprechenden Tasks in den Workflows zu konfigurieren.

Rollengruppennamen werden nach folgendem Schema zusammengesetzt:

• <mandant>:

• Kürzel des Mandanten

• <rolle>:

• Bezeichnung des Rollennamens

• <rollenausprägung>

• Optional ein Kürzel für eine Ausprägung der Rolle

Somit ergeben sich für den skizzierten Fall die beiden folgenden Gruppen:

• xyz_Redakteur

• xyz_SiteAdmin

Falls es zwei dedizierte Benutzerkreise gibt, die die konkreten Ausprägungen „Ersteller“ und „Qualitätsbeauftragter“ einnehmen, so ergeben sich daraus folgende Gruppen:

• xyz_Redakteur_RD

• xyz_Redakteur_QB

• xyz_SiteAdmin

Diesen Gruppen werden keine Ressourcenrechte zugeordnet. Über diese Gruppen werden keine Editorkonfigurationen zugewiesen.

Beispiel

Die drei Standard-Rollen eines Workflows müssen beim 2-Augen-Workflow zu einer konkreten Gruppe zusammengefasst werden. Die unten stehende Beschreibung macht kenntlich, dass in diesem Beispiel nur die Mitglieder der Rollengruppe „xyz_SiteAdmin“ den 2-Augen-Workflow ausführen bzw. bearbeiten können.

2-Augen-Workflow: Rolle	Gruppe
Supervisor	xyz_SiteAdmin

Die drei Standard-Rollen eines Workflows müssen beim 4-Augen-Workflow zu zwei konkreten Gruppen zusammengefasst werden. Die unten stehende Beschreibung macht kenntlich, dass nur die Mitglieder der Rollengruppe Innenpolitik den 4-Augen-Workflow innerhalb ihrer Redaktion ausführen können.

4-Augen-Workflow: Rolle	Gruppe
Composer	xyz_Redakteur_innenpolitik
Approver	xyz_Redakteur_innenpolitik
Publisher

Die drei Standard-Rollen eines Workflows entsprechen beim 6-Augen-Workflow auch den konkreten Gruppen. Die unten stehende Beschreibung macht kenntlich, dass nur die Mitglieder der Rollengruppe Innenpolitik den 6-Augen-Workflow in innerhalb ihrer Redaktion ausführen können. Hierbei wurde exemplarisch eine Aufteilung in zwei Rollen-Ausprägungen „Ersteller“ und „Qualitätsbeauftragter“ vorgenommen. Auch wenn die Ausprägung „Qualitätsbeauftragter“ hier den technischen Rollen „Approver“ und „Publisher“ zugewiesen ist, ist durch die Implementation der GSB Workflows das 6-Augen-Prinzip gewahrt. Analog gilt dies auch für den 4-Augen-Workflow.

6-Augen-Workflow: Rolle	Gruppe
Composer	xyz_Redakteur_innenpolitik_RD
Approver	xyz_Redakteur_innenpolitik_QB
Publisher	xyz_Redakteur_innenpolitik_QB

Variationen

Falls innerhalb einer Redaktion die Rollen zusätzlich spezifisch für einzelne Workflows vergeben werden, so können die Gruppen um die Angabe des Workflow-Kürzels erweitert werden. Im obigen Beispiel würden dann die folgenden Gruppen benötigt

• xyz_Redakteur_innenpolitik_RD_4wf
• xyz_Redakteur_innenpolitik_RD_6wf
• xyz_Redakteur_innenpolitik_QB_4wf
• xyz_Redakteur_innenpolitik_QB_6wf

Dokumente und Workflows

Da innerhalb des CMS Dokumente zunächst auch ohne Workflows bearbeitet werden können, ist es theoretisch möglich, die Workflow-Gruppen unabhängig von der Redaktionsrollen bzw. -gruppen zu definieren.

Die folgende Tabelle setzt die notwendigen Rechte an den Dokumenten, die innerhalb des Workflows bearbeitet werden, mit den Workflow-Rollen in Bezug.

Rechte: Workflows / Dokumente	compose	approve	publish
Lesen	X	X	X
Bearbeiten	X
Abnehmen		X
Publizieren und Depublizieren			X

Da sich die mit den jeweiligen Workflow-Rollen bzw. LRS-Gruppen verknüpften Rechte in bestimmten Teilen offensichtlich überschneiden bzw. diese Rechte bei manchen Workflow-Schritten auch zwingend vorausgesetzt werden, ist es empfehlenswert, die Workflow-Gruppen in Abhängigkeit der Benutzerrollen/-gruppen innerhalb einer Redaktion zu definieren bzw. aus diesen abzuleiten. Die Zuordnung der einzelnen Gruppen wird in den nachfolgenden Kapiteln diskutiert.

nach oben