Implementiert ab Version 4.1 Enterprise!

Die Workflowverwaltung dient zur Steuerung der Arbeitsabläufe im Backend. Er arbeitet dazu eng mit der Tabellenverwaltung und der Formularverwaltung zusammen.

Die Konfiguration der Workflowverwaltung wird dabei anhand der Datei workflow.xml vorgenommen. Die Workflow-Datei wird im Verzeichnis /modules/workflowmanager/workflows gesucht und wenn sie dort nicht gefunden wird im Verzeichnis /media/workflowmanager/workflows.

<?xml version="1.0" encoding="UTF-8"?>
<workflowEngine version="Versionsnummer">
   // die Versionsnummer ist optional und dient zur Kompatibilitätskontrolle (aktuell und Standardwert ist Version 1.0)
   <workflowDefiniton>
      <workflowName><![CDATA[Workflow-Name]]></workflowName>
         // über den Workflow-Namen erfolgt die Auswahl am Formular des Formularmanagers
      <workflowDescription><![CDATA[Kurzbeschreibung]]></workflowDescription>
         // optionales Feld zur Beschreibung und Anzeige als Tooltip
      <workflowStep>
         <stepButton type="Button-Typ">
            // Typ des Buttons (submit, reset, click - weitere Typen möglich), submit ist Standard
            <buttonTitle>Button-Beschriftung</buttonTitle>
            <buttonSortNo>Button-Reihenfolge</buttonSortNo>
               // optionales Feld um Reihenfolge der Anzeige festzulegen
               // fehlt diese oder wird sie mehrfach vergeben, wird dieser Button hinter den Anderen dargestellt
            <buttonClass>Button-CSS-Klasse</buttonClass>
               // optionales Feld um eine CSS-Klasse angeben zu können, welche den Standard des Button-Typs überschreibt
            <buttonDescription><![CDATA[Beschreibung des Buttons bzw. der damit verbunden Aktion(en)]]></buttonDescription>
               // optionales Feld, es sollte aber snnvoll gefüllt werden, da dessen Inhalt zur Nutzerinformation angezeigt wird
         </stepButton>
         <stepConditions>
            <conditionCombination>
               // alle Bedingungs-Kombinationen werden mit OR-Verknüpfung geprüft
               // alle Bedingungs-Arten (status, role, dbright, dbcol) werden mit AND-Verknüpfung geprüft
               // fehlende Bedingungsarten werden als nicht relevant und damit als erfüllt angesehen
               <statusConditions type="Bedingungs-Typ">
                  // einschliessender oder ausschliessender Typ (inclusion, exclusion), inclusion ist der Standardwert
                  <condition>Status-Name</condition>
                     // innerhalb einer Bedingungs-Art wird mit OR-Verknüpfung geprüft
                  ... beliebige Anzahl an Statusbedingungen
               </statusConditions>
               <roleConditions type="Bedingungs-Typ">
                  <condition>Rollen-Name</condition>
                  ... beliebige Anzahl an Rollenbedingungen
               </roleConditions>
               <dbrightConditions type="Bedingungs-Typ">
                  <condition>DB-Recht</condition>
                  // bisher existieren folgende tabellenbezogene Rechte: alter, delete, edit, publish, show
                  // diese orientieren sich an üblichen DB-Rechten, können aber bei Bedarf erweitert werden
                  // Vorsicht bei der Verwendung von (noch) nicht existierenden Rechten und dem Typ exclusion
                  ... beliebige Anzahl an Rechtebedingungen
               </dbrightConditions>
               <dbcolConditions type="Bedingungs-Typ">
                  <condition>
                     <parameter type="colName">DB-Spaltename</parameter>
                     <parameter type="operator"><![CDATA[Operator]]></parameter>
                        // CDATA-Feld mit gebräuchlichen Vergleichsoperatoren (=, >, <, <>, >=, <=, exists)
                     <parameter type="staticValue">statischer Wert</parameter>
                        // statischer Vergleichswert, wird erst in den Typ der DB-Spalte konvertiert
                     <parameter type="dynamicValue">dynamischer Wert</parameter>
                        // dynamischer Vergleichswert, wird als PHP-Anweisung interpretiert (bspw. time)
                        // es wird nur der 1. Value-Parameter pro Condition akzeptiert
                        // beim Operator exists sind Value-Parameter nicht sinnvoll
                  </condition>
                  ... beliebige Anzahl an Spaltenbedingungen
               </dbcolConditions>
            </conditionCombination>
            ... beliebige Anzahl an Bedingungskombinationen
         </stepConditions>
         <stepActions>
            <action name="Aktions-Name" />
               // Aktion mit diesem Namen soll ausgeführt werden
            ... beliebige Anzahl von Aktionsschritten, welche in der aufgeführten Reihenfolge ausgeführt werden
         </stepActions>
         <targetStatus>Zielstatus</targetStatus>
            // optionales Feld, ermöglicht den Zielstatus statisch zu setzen (sonst ist Zielstatus das Ergebnis der Aktionen)
            // zur Zeit existieren enabled, preview, feedback, pending, disabled
      </workflowStep>
      ... beliebige Anzahl von Workflow-Schritten
   </workflowDefiniton>
   ... beliebige Anzahl von Workflow-Beschreibungen
   <actionDefinitions>
       <action name="Aktions-Name" errorcheck="Fehlerprüfung">
            // Aktionsname aus dem Workflow-Schritt, das optionale Attribut errorcheck konfiguriert die Art der 
            // Fehlerprüfung mögliche Werte (none, return, exception), none ist der Standardwert
            <parameter type="Parameter-Typ">Parameter-Wert</parameter>
           ... beliebige Anzahl an Parametern
       </action>
       ... beliebige Anzahl von Aktionen (müssen alle aus den Workflow-Schritten sein)
   </actionDefinitions>
</workflowEngine>

Beispiel für Aufbau der Bedingungen:

<stepConditions>
   <conditionCombination>
      <statusConditions>
         <condition>revised</condition>
         <condition>unpublished</condition>
      </statusConditions>
      <roleConditions type="exclusion">
         <condition>Gast</condition>
         <condition>Shopuser</condition>
      </roleConditions>
      <dbrightConditions>
         <condition>show</condition>
         <condition>edit</condition>
      </dbrightConditions>
   </conditionCombination>
   <conditionCombination>
      <statusConditions>
         <condition>revised</condition>
         <condition>unpublished</condition>
      </statusConditions>
      <roleConditions>
         <condition>Admin</condition>
      </roleConditions>
   </conditionCombination>
</stepConditions>

Zu interpretieren als:

WENN (status == (revised OR unpublished)) AND (role != (Gast OR Shopuser)) AND (recht == (show OR edit))
ODER (status == (revised OR unpublished)) AND role = Admin)
DANN ausführen

Die erste zutreffende Bedingungs-Kombination führt zur Anzeige des Workflowschrittes. Die Definition von Einschränkungen gilt nur in der jeweiligen Bedingungs-Kombination. Ein Verbot durch eine excludierende Bedingung in einer anderen Bedingungs-Kombination hat darauf keinen Einfluß.

Beispiel für Aufbau der Aktionen:

<actions>
   <action name="rowPublish" errorcheck="return">
      <parameter type="table">versionrel_id</parameter>
         // Parameter kommt dann aus dieser Tabellenspalte
      <parameter type="session">user_id</parameter>
         // Parameter kommt dann aus dieser Sessionvariable, komplexere Angaben (Arrays) sind möglich
   </action>
   <action name="sendMail" errorcheck="exception">
      <parameter type="staticValue">giveFeedback</parameter>
         // Parameter wird dann statisch als String übergeben
      <parameter type="dynamicValue">time()</parameter>
         // Parameter wird dann dynamisch als PHP-Anweisung interpretiert und übergeben
      <parameter type="form">email_address</parameter>
         // Parameter kommt dann aus diesem Formularfeld
   </action>
</actions>

Diese Aktionen werden dann über ein include-Befehl auf eine gleichnamige PHP-Datei eingebunden.
Diese wird im Verzeichnis /modules/workflowmanager/actions gesucht und wenn nicht gefunden im Verzeichnis /media/workflowmanager/actions. Dort sind diese Aktionen dann entweder direkt implementiert oder deligieren an geeignete Klassen (bpsw. publish-Aktionen am DB-Manager).
Die Dateieinbindung bedingt eine Limitation der verwendbaren Zeichen für den Aktionsnamen.
Die Empfehlung ist nur A-Z, a-z, 0-9, und die Zeichen _ - . zu verwenden, wobei in Kleinbuchstaben umgewandelt wird.
Definitv verboten sind die Zeichen < > ? “ : | \ / *.
Die Aktions-Parameter sind zu interpretieren als Methoden mit folgendem Aufbau:

rowPublish($versionrel_id, $_SESSION['user_id']);
sendMail('giveFeedback', 1234567890, $email_address);
1234567890 steht als Beispiel für den Timestamp von time()
'' Die Fehlerprüfung bei errorcheck=„exception“ interpretiert das Auftreten einer unbehandelten Exception als Fehler (und catcht diese Exception). Die Fehlerprüfung bei errorcheck=„return“ beinhaltet errorcheck=„exception“ und kontrolliert zusätzlich den Rückgabewert, wobei false und void als Auftreten eines Fehlers interpretiert werden.