Zielgruppe Site AdminVersion: GSB10.1Konfigurationsmöglichkeiten

Benutzer inaktiv schalten

Wenn Benutzer nicht anwesend sind (Urlaub, Krankheit etc.), können sie sich beim System inaktiv schalten, damit ihnen keine Aufgaben zur Bearbeitung angeboten werden. Dies ist ebenfalls durch den Site Manager möglich, falls eine Person selbst keine Möglichkeit dazu hat.

Dazu wird im Heimatordner jedes Benutzers eine Profilressource angelegt, auf die verschiedene Komponenten des CMS zugreifen können. Hier kann eine Eigenschaft zum Festlegen der Inaktivität vorgesehen werden, die jeder Workflow auswerten kann. Diese Ressource ist nur durch den Besitzer und bestimmte berechtigte Personen (Administratoren, Personalverantwortliche, etc.) änderbar.

Time-out-Werte

Bei einer ungeplanten Abwesenheit eines CMS-Nutzers, etwa durch Krankheit, hat dieser meist nicht die Möglichkeit, einen Abwesenheitsvermerk zu setzen und kann außerdem auch nicht seine Aufgaben wahrnehmen. Damit nun die Bearbeitung eines Dokuments nicht durch die unerwartete Abwesenheit eines CMS-Nutzers blockiert wird, hat ein CMS-Nutzer innerhalb eines Workflows nur ein bestimmtes Zeitfenster zur Verfügung, um die ihm zugewiesene Aufgabe durchzuführen.

Jede Redaktion kann für beliebige User-Tasks der Workflows den Time-out Wert für Annahme und Abarbeitung definieren.

E-Mail-Benachrichtigung

Eine Zuordnung von Benutzerkonten zu E-Mail-Adressen ist für den automatischen Mailversand bei anstehenden Workflow-Tasks notwendig.

Die E-Mail-Adressen könnten ebenfalls in den Profilressourcen der Benutzer abgelegt sein, damit jede Person die Möglichkeit hat, eine alternative Mailadresse für Benachrichtigungen anzugeben.

Für jeden Workflow-Task, in dem eine Interaktion mit den Anwendern erfolgt, ist prinzipiell eine E-Mail-Benachrichtigung der infrage kommenden Personen vorgesehen. Häufig ist dies aber nicht erwünscht, ebenso sollte der Text den individuellen Anforderungen Rechnung tragen. Deshalb wird in der Redaktionsdefinition (analog zu den Time-outs) festgelegt, bei welchem Task eine E-Mail verschickt werden soll und welchen Text sie beinhalten soll.

Hat ein Anwender keine E-Mail-Adresse eingetragen, kann ihm keine Workflow-Benachrichtigung zugeschickt werden. Bei Bedarf kann über eine Recherche festgestellt werden, ob alle Anwender E-Mail-Adressen hinterlegt haben.

Konfiguration der E-Mail Benachrichtigung

In den Redaktionsdefinitionen ist es möglich, für beliebige Usertasks (Compose, Approve, Publish) Form-Mails an alle beteiligten Personen (feste Mailadresse oder alle Personen einer Gruppe, denen der Workflow angeboten wird) zu schicken, die Ihre Mailaddresse in ihren eigenen Personendaten mit Namen "Personendaten" im User-Home-Verzeichnis) angegeben haben.

Folgende Platzhalter werden dabei im Haupttext und im Betreff ersetzt:

Platzhalter	Wird ersetzt durch
${workflowName}$	technischer Name des Workflows (z.B. FourEyesSubWorkflow - leider nicht eingedeutscht möglich!)
${workflowOwner}$	Name des Users, der den Workflow gestartet hat - ggf. mit Domain
${workflowOwnerShort}$	Wie workflowOwner, allerdings nie mit der Domain. Vermutlich häufigere Variante.
${resourceList}$	Liste der Ressourcen in Default-Formatierung. Nicht im Betreff verfügbar, da Zeilenumbrüche.
${resourceList:FORMAT}$	Ressourcenliste mit flexibler Konfigurationsmöglichkeit der Anzeige (s. Abschnitt weiter unten)
${resourceCount}$	Anzahl der Ressourcen in der Resourcenliste
${editorGroupName}$	Vollständiger Name der Redaktion (also in der Form Mandant/MeineRedaktion)

 E-Mail-Benachrichtigung zu einzelnem Workflow-Schritt ein- bzw. ausgeschalten

Die Workflow-Konfiguration befindet sich im Ordner:

/MANDANT/__EditorConfig/Workflows

Für jede Redaktion ist hier eine Definition in folgender Form zu hinterlegen (siehe Standardlösung)

Beispiel Administrator-Redaktion:

<Definition name="administrator-redaktion">
 <lrs>standardlsg_lrs_Alles@standardlsg</lrs>
<Workflow name="twoeyesworkflow">
<Startgroups>
<startgroup>standardlsg_red_Administration_RD@standardlsg</startgroup>
 </Startgroups>
<Tasks>
 <Compose>
<groups>standardlsg_red_Administration_RD@standardlsg</groups>
 </Compose>
 <MailPublicationFailed>  (1)
 <mailToAssigneeFromTask>Compose</mailToAssigneeFromTask>
<mailToCandidatesFromTask />  (2)
 <mailtemplate>twoeyesworkflow/publicationFailedTemplate</mailtemplate>
<standardEmailReceiver>gregor.janus@materna.de</standardEmailReceiver>
 </MailPublicationFailed>
<MailPublicationSuccessful>
 <mailToAssigneeFromTask>Compose</mailToAssigneeFromTask>
<mailToCandidatesFromTask />
 <mailtemplate>twoeyesworkflow/publicationSuccessfulTemplate</mailtemplate>
<standardEmailReceiver>gregor.janus@materna.de</standardEmailReceiver>
</MailPublicationSuccessful>
 </Tasks>
</Workflow>
</Definition>

(1)	Der hier konfigurierte Empfänger erhält im Erfolgs- oder Misserfolgsfall eine E-Mail. Kann leer gelassen werden, falls nicht erwünscht.
(2)	Der Benutzer von dem der Task abgeschlossen soll benachrichtigt werden (optional)

E-Mail-Vorlagen

... müssen im Ordner

/MANDANT/_config/workflows/mailvorlagen 

liegen und sind vom Dokumenttyp: Konfiguration-Richtext 1.0

Beispiel Mailvorlage:

/standardlsg/_config/workflows/mailvorlagen/twoeyesworkflow/publicationFailedTemplate

Beispiel Betreff-Text:

/standardlsg/_config/workflows/mailvorlagen/twoeyesworkflow/publicationFailedTemplate_subject

Aufbau einer Vorlage

Der Vorlagentext kann in der Property „Wert“ gepflegt werden
Es können folgende Platzhalter verwendet werden:
${workflowOwner}$ Benutzer der den Workflow gestartet hat in Langform (standardlsgAdmin@standardlsg)
${workflowOwnerShort}$ Benutzer der den Workflow gestartet hat in Kurzform (standardlsgAdmin)
${workflowName}$ Name des Workflows
${resourceList:* PARAMETER}$ Auflistung der Workflow-Ressourcen (Beispiel: ${resourceList:* P/NR V - M - D - SRR}$)

Der Platzhalter ${resourceList:PARAMETER}$ erlaubt die Angabe von Formatierungsinformationen für die Ressourcenliste. FORMAT ist ein beliebiger String außer }$ und Zeilenumbrüchen.

Platzhalter	wird ersetzt durch
P	Pfad
N	Name
I	ID
V	Version (nur Document)
M	Modification date (nur Document)
C	Creation date
Q	Publication date (nur Document)
E	Creator (Login des Benutzers)
D	Document type (wenn Document), sonst "Folder"
S	Live-Status (ob sich die Ressource momentan auf dem Livesystem befindet / publiziert ist)
L	Linebreak (Unix-Format)
R	Carriage Return, Linebreak (Windows-Format)

Beispiele für Formatierungen:

In diesem Mail-Formtext wurden alle Platzhalter (bis auf den Windows-Zeilenumbruch) verwendet:

Die folgenden ${resourceCount}$ Ressourcen sollen publiziert werden:${resourceList:09:27, 8. Dez. 2011 (CET)[[Benutzer:Admin|Admin]]L*** P/N I V L M C Q (creator)EL D SL09:27, 8. Dez. 2011 (CET)[[Benutzer:Admin|Admin]]LL}$

Die versendete Mail sieht dann so aus:

Die folgenden 3 Ressourcen sollen publiziert werden:09:27, 8. Dez. 2011 (CET)[[Benutzer:Admin|Admin]]*** /Sites/Tests/WorkflowTests/RedaktionA/extlink1 ID:7044 Version:1 ModDate:26.01.2006 14:32:09 CreationDate:22.07.2004 16:38:29 (creator)Creator:admin DocType:ExternalLink Live:false09:27, 8. Dez. 2011 (CET)[[Benutzer:Admin|Admin]]09:27, 8. Dez. 2011 (CET)[[Benutzer:Admin|Admin]]*** /Sites/Tests/WorkflowTests/RedaktionA/Metadaten_fuer_testdoc_bereits_abgelaufen ID:22954 Version:4 ModDate:11.01.2006 15:29:08 CreationDate:23.11.2004 12:14:27 (creator)Creator:tester1 DocType:MetaEnt Live:false09:27, 8. Dez. 2011 (CET)[[Benutzer:Admin|Admin]]09:27, 8. Dez. 2011 (CET)[[Benutzer:Admin|Admin]]*** /Sites/Tests/WorkflowTests/RedaktionA/Blah ID:4389 CreationDate:26.01.2006 14:31:45 (creator)Creator:testerGott Folder Live:false09:27, 8. Dez. 2011 (CET)[[Benutzer:Admin|Admin]]

Man beachte hier, dass nicht Platzhalter, die konkret nicht zutreffen, leer bleiben. So ist etwa des Q in der Mail nicht zu sehen, da es kein Publikationsdatum gibt (der Platzhalter ist für Depublikationsworkflows vorgesehen). Ein Folder hat prinzipiell keine Version, deshalb ist die Version hier bei "Blah" leer, bei den beiden anderen Dokumenten aber ersetzt.

In der Redaktionsdefinition kann man das Subject setzen. Hier sind Platzhalter möglich:

<Redaktion name="XYZ_redaktion" default="ja"> <Mailconfig server="localhost" betreff="Notfall-Workflow: Gestartet von ${workflowOwnerShort}$, ${resourceCount}$ Ressourcen publizieren" absender="marc.habiger@materna.de"/> .... .... <Workflow name="TwoEyesPublicationSubWorkflow"> <Mail task="Publish" vorlage="notfall"/> </Workflow> ....

Das Mail-Element in der Redaktionsdefinition kann um eine fixe Angabe von Empfängern erweitert werden:

<Mail task="Publish" vorlage="testmail" standardEmpfaenger="max@moritz.de,vaeterchen.frost@suite025.net" />

Somit erhalten Max und Väterchen Frost immer eine Mail bei einer Publikation (in dieser Redaktion bei diesem Workflow), selbst, wenn sie niemals von Workflows gehört haben. Sinnvoll ist an dieser Stelle ein weiteres Attribut, das den Versand an die beteiligten Redakteure unterdrückt:

<Mail task="Publish" vorlage="testmail" standardEmpfaenger="max@moritz.de,vaeterchen.frost@suite025.net" nurStandardEmpfaenger="ja" />

So kann man individuell entscheiden, ob die Benachrichtigung tatsächlich ein Arbeitsangebot für Annahmeberechtigte sein soll, oder ob lediglich der Chef von einer Publikation in Kenntnis gesetzt wird. Der Default für nur StandardEmpfaenger ist natürlich "nein".

Bearbeiten von Dokumenten durch den Approver oder Publisher

Üblicherweise kann der Approver und der Publisher ein Dokument nut Approven, bzw. Publishen aber nicht mehr selbst überarbeiten. Ist dies doch gewünscht, so kann dies nun in der Redaktionsdefinition konfiguriert werden.

Hierzu ist in der entsprechenden Redaktionsdefinitionen bei dem entsprechenden Workflow der zu modifizierende Task einzusetzen. Als Angabe ist hier Approve und Publish erlaubt. Mehrere Angaben sind durch ein Komma zu trennen.

Hier ein Beispiel einer 4-Augen-Workflow Konfiguration:

<Workflow name="FourEyesSubWorkflow" modifizierendeTasks="Publish" > </Workflow>

Hinweis:
Soll der Publisher in der Lage sein ein Dokument zu überarbeiten, so ist darauf zu achten, dass in der Editor.xml der Publisher auch in der Lage ist das Dokument zu approven.

<Task name="Publish">... <AggregationVariable editorClass="de.bundonline.basis.editor.DynamicPermissionChangeSetEditor" name="changeSet" approveTask="Publish" />...</Task>

Verhalten nach Publikationsfehlern bei 6-Augen Publizierungs Workflows

Normalerweise wird beim Auftreten eines Publikationsfehlers innerhalb eines 6-Augen-Publizierungs-Workflows das Dokument zum Composer übergeben.

Mit Hilfe eines Konfigurationswertes ist es möglich zu erreichen dass nach einem Publikationsfehler das Dokument beim Approver bzw. Publisher landet.

Hierzu ist bei dem Eintrag taskNachPublikationsfehler ein Compose,Approve oder Publish einzutragen.

Hier ein Beispiel:

<Workflow name="SixEyesPublicationSubWorkflow" taskNachPublikationsfehler="Approve" > </Workflow>

Spezielles Verhalten nach Nichtfreigabe/Nichtpublizierung eines Dokumentes bei leeren Kommentar.

In der Praxis hat sich gezeigt, dass der Approver, bzw Publisher häufig vergisst den Approvement-Haken zu setzen obwohl er das Dokument freigeben wollte.

Mit Hilfe eines Konfigurationswertes ist es möglich zu erreichen dass bei einem nichtfreigegeben Dokument und leerem Kommentarfeld, eine Meldung erscheint, dass der Approver/Publisher entweder das Dokument approven muss, bzw- einen Kommentar eingeben muss.

Hierzu ist bei dem Eintrag ueberpruefeEingabeFreigabe bzw. ueberpruefeEingabePublizierung ein „true“ einzutragen.

Hier ein Beispiel:

<Workflow name="SixEyesPublicationSubWorkflow" ueberpruefeEingabeFreigabe="true" ueberpruefeEingabePublizierung="true"> </Workflow>

Anzeige von zusätzlichen Workflowinformationen:

Es gibt die Möglichkeit weitere Aufgabeninformationen in der Workflowübersicht anzuzeigen.

Dieses sind der Betreff der Aufgabe und ein fls rekonfigurierbarer Text aus der Redaktionsdefinition.

Innerhalb des Workflowfensters des Java-Editors sieht das dann so aus:

Konfiguriert werden muss dieses Feature in der editor.xml und in der Redaktionsdefinition.

Der entsprechende Abschnitt in der editor.xml sieht so aus:

 <Workflow>
    <TableDefinition rowHeight="25">
      <ColumnDefinition class="hox.corem.editor.workflow.columns.WorklistDetailColumn" weight="0.7">
       <ComponentFactory class="de.bundonline.basis.editor.workflow.GsbDataPanelFactory" processName="SixEyesPublicationSubWorkflow" />
        <ComponentFactory class="de.bundonline.basis.editor.workflow.GsbDataPanelFactory" processName="FourEyesSubWorkflow" />
      </ColumnDefinition>
    <ColumnDefinition class="hox.corem.editor.workflow.columns.WorklistProcessColumn" weight="0.3">
     </ColumnDefinition>
    </TableDefinition>
  </Workflow>

In der Redaktionsdefinition kann nun noch der frei vergebbare Text eingetragen werden:

<Workflow name="FourEyesSubWorkflow" listenkommentar="Newsredaktion: wichtig"/>

nach oben