Diese Funktion erlaubt Ihnen in OTRS Prozesse (Work-Flows) zu modellieren. Die grundlegende Idee ist wiederkehrende Prozesse zu definieren und die Arbeit an verschiedene Personen zu delegieren, genauso um den Prozess in verschiedene Richtungen, basierend auf bestimmten Kriterien, zu führen.
Zur Demonstration schauen wir uns ein Beispiel an. Wir wollen die Bestellung eines Buches in einem Prozess abbilden.
Bevor eine Bestellung abgesetzt wird, wird die Anforderung eines Mitarbeiters von Literatur gespeichert. Das folgende Buch wird in unserem Beispiel benötigt:
Titel: Prozessmanagement für Dummies Autor: Thilo Knuppertz ISBN: 3527703713
Der Abteilungsleiter des Mitarbeiters muss über die Bestellung entscheiden. Im Falle einer Verweigerung sollte ein Grund vom Manager angegeben werden. Im Falle einer Genehmigung wird die Bestellung zur Einkauf-Abteilung weitergeleitet.
Die Einkauf-Abteilung muss nun herausfinden, wo das Buch zu den besten Konditionen bestellt werden kann. Wenn es ausverkauft ist kann das in der Bestellung vermerkt werden. Im Falle einer erfolgreichen Bestellung wird die Einkauf-Abteilung den Lieferanten, den Preis und das Lieferdatum aufnehmen.
Wenn wir davon ausgehen, dass sich ein Ticket in diesem Work-Flow wie ein Begleitdokument verhält, das Veränderungen als Notizen empfängt, dann haben wir schon ein klares Bild der Prozess-Tickets.
Nach der Analyse des Beispielprozesses, konnten wir folgende nötigen Elemente identifizieren:
Möglichkeiten zur Datenaufnahme, hier Aktivitäten-Dialoge,
Kontrollen, die automatisch auf geänderte Daten reagieren kann, nennen wir sie Übergänge,
Änderungen, die sich auf ein Prozess-Ticket nach erfolgreichem Übergang eines Prozess-Ticket angewendet werden können, nennen wir sie Übergangsaktionen.
Wir brauchen noch ein zusätzliches Element, was nicht so offensichtlich sein könnte:
Eine Möglichkeit mehr als nur einen Aktivitätsdialog zur Verfügung zustellen. In unserem Beispiel ist das erforderlich, wenn die Führungskraft zwischen "Genehmigen" und "Ablehnen" zu entscheiden hat. Nennen wir sie Aktivität .
Mit Aktivitäten, Aktivitätsdialogen, Übergängen und Übergangsaktionen haben wir die notwendigen Werkzeuge, um die einzelnen Schritte unseres Beispiels zu modellieren. Was ist noch fehlt, ist ein Bereich, wo für jeden Arbeitsablauf die Reihenfolge der Schritte festgelegt wird. Nennen wir diesen Prozess. Um uns auf all diese Personen später beziehen zu können, werden wir ihnen in Klammern eine Abkürzung zuweisen. Diese Abkürzungen basieren auf einem internen Identifikations-Mechanismus namens EntityIDs.
Die EntityIDs werden mit einem oder zwei Buchstaben (je nach Prozessteil) und einer fortlaufenden Nummer gebildet, Beispiel:
Prozess: 'P1', 'P2' ... 'Pn'.
Aktivität: 'A1', 'A2' ... 'An'.
Aktivitätsdialog: 'AD1', 'AD2' ... 'ADn'.
Übergang: 'T1', 'T2' ... 'Tn'.
Übergangsaktivität: 'TA1', 'TA2' ... 'TAn'.
Vor der Erstellung des Prozesses und seiner Abschnitte ist es notwendig, das System vorzubereiten, wir müssen sowohl einige Queues, Nutzer und Dynamic Fields definieren, als auch ein paar SysConfig-Optionen festlegen.
Erstellen Sie die folgenden Queues:
Management
Mitarbeiter
Einkauf
Post
Erstellen Sie die folgenden Benutzer:
Manager
Mitarbeiter
Erstellen Sie die folgenden DynamicFields
Titel
Beschriftung | Titel |
Typ | Text |
Objekt | Ticket |
Autor
Beschriftung | Autor |
Typ | Text |
Objekt | Ticket |
ISBN
Beschriftung | ISBN |
Typ | Text |
Objekt | Ticket |
Status
Beschriftung | Status |
Typ | Einfachauswahl |
Objekt | Ticket |
mögliche Werte |
|
Bemerkung: Bitte benutzen Sie exakt diese möglichen Werte für "Schlüssel" und "Wert" in den DynamicField-Einstellungen
Lieferant
Beschriftung | Lieferant |
Typ | Text |
Objekt | Ticket |
Preis
Beschriftung | Preis |
Typ | Text |
Objekt | Ticket |
LieferDatum
Beschriftung | Liefertermin |
Typ | Datum |
Objekt | Ticket |
Eingangsdatum
Beschriftung | Datum des Eingangs |
Typ | Datum |
Objekt | Ticket |
Setzen Sie die folgenden SysConfig-Einstellungen:
'Ticket::Responsible': Ja
'Ticket::Frontend::AgentTicketZoom###ProcessWidgetDynamicFieldGroups':
Schlüssel: | Inhalt: |
---|---|
Buch | Titel, Autor,ISBN |
Allgemein | Status |
Auftrag | Preis, Lieferant,Liefertermin |
Lieferung | Eingangsdatum |
'Ticket::Frontend::AgentTicketZoom###ProcessWidgetDynamicField':
Schlüssel: | Inhalt: |
---|---|
Autor | 1 |
Eingangsdatum | 1 |
LieferDatum | 1 |
ISBN | 1 |
Preis | 1 |
Status | 1 |
Lieferant | 1 |
Titel | 1 |
Fangen wir mit dem realen Prozessmanagement an. Im nächsten Schritt werden wir die einzelnen Objekte, die wir benötigen, definieren.
Um einen neuen Prozess zu erstellen ist es notwendig auf den Link "Prozess Management" in der Systemverwaltungs-Box im Admin-Menü zu klicken, anschließend gelangen wir zur Prozessmanagement-Übersicht. Nachdem der Prozess erstellt wurden, können wir alle anderen Objekte (oder Prozessteile) erstellen.
Aktivitäten, Aktivitätsdialoge, Übergänge und Übergangsaktionen die in einem Prozess definiert wurden, sind ebenfalls für alle anderen Prozesse im System verfügbar.
Abbildung.: OTRS Administrationsbereich.
Klicken Sie auf "Neuen Prozess erstellen" im Adminmenü
Abbildung.: Neuen Prozess hinzufügen.
Füllen Sie die Prozessinformationen aus, definieren Sie einen Prozessname und die Beschreibung für diesen Prozess, wir belassen den Prozessstatus auf "inaktiv", bis wir alle Aufgaben erledigt haben. Speichern Sie den Vorgang.
Abb.: Neuen Prozess hinzufügen.
Klicken Sie auf den neuen Prozessnamen in der Prozessmanagement-Übersichtsbild, dann in den "verfügbaren Prozess Elementen" klicken Sie auf "Activity Dialoge" (diese Aktion wird die möglichen Dialogoptionen erweitern), anschließend klicken Sie auf "Neuen Aktivitätsdialog erstellen".
Abbildung: Erstelle neue Aktivitätsdialog.
In the opened popup screen fill the "Activity dialog Name" as well as the "Description (short)" fields, for this example we will leave all other fields as the default, to assign fields to the Activity Dialog simple drag the required field from the "Available Fields" pool and drop into the "Assigned Fields" pool. The order in the "Assigned Fields" pool is the order as the fields will have in the screen, to modify the order simply drag and drop the filed within the pool to rearrange it in the correct place.
Abbildung: Neuen Aktivitätsdialog hinzufügen.
As soon as the fields are dropped into the "Assigned Fields" pool another popup screen is shown with some details about the field, we will leave the default options and only for Article fields we should make sure that the ArticleType field is set to "note-internal".
Abbildung: Felddetails bearbeiten (Artikel).
Nachdem alle Felder zugewiesen wurden, klicken Sie auf übermitteln in der PopUp-Oberfläche damit die Änderungen gespeichert werden.
In this example we will use Article field for comments, but another option could be to create a TextArea type Dynamic Field, the rest of the mentioned fields in the lines below are the Dynamic Fields that we define before.
Please be aware that in this screen all the Dynamic Fields has the prefix "DynamicField_" as in "DynamicField_Title", Do not confuse with the field "Title" that is the Ticket Title.
Erstellen Sie die folgenden Aktivitätsdialoge:
"Aufnahme der Nachfrage" (AD1)
Ein Aktivitätsdialog, welcher alle erforderlichen Felder für die Daten der Bestellung enthält (Titel, Autor und ISBN) und ein Statusfeld mit der Möglichkeit "Approval" zu wählen.
"Genehmigung verweigert" (AD2)
Ein Aktivitätsdialog mit einem Kommentarfeld (Artikel) und einem Statusfeld mit der Möglichkeit "Approval denied".
"Genehmigt" (AD3)
Hier benötigen Sie das Statusfeld mit der Option "Genehmigt".
"Bestellung abgelehnt" (AD4)
Ein Aktivitsdialog, welcher es ermöglicht eine unmögliche Bestellung abzulehnen (Buch ist nicht auf Lager). Hier wird ebenfalls ein Kommentarfeld und ein Statusfeld mit der Option "Order denied" benötigt.
"Bestellung aufgegeben" (AD5)
Ein Aktivitätsdialog mit den Feldern Lieferant, Preis und Lieferdatum und dem Statusfeld mit der Option "Bestellung abgegeben".
"Sendung empfangen" (AD6)
Eine Aktivität für die Poststelle mit einem Feld für das Empfangsdatum und dem Statusfeld mit der Option "Bestellung empfangen".
Um das Statusfeld zu beschränken, benötigen wir für jeden Aktivitätsdialog mindestens eine ACL in Kernel/Config.pm oder in einer neuen Perl-Datei in Kernel/Config/Files.
$Self->{TicketAcl}->{'P1-AD1-1'} = { Properties => { Process => { ActivityDialogEntityID => ['AD1'], }, }, Possible => { Ticket => { DynamicField_Status => ['Approval'], }, }, }; $Self->{TicketAcl}->{'P1-AD2-1'} = { Properties => { Process => { ActivityDialogEntityID => ['AD2'], }, }, Possible => { Ticket => { DynamicField_Status => ['Approval denied'], }, }, }; $Self->{TicketAcl}->{'P1-AD3-1'} = { Properties => { Process => { ActivityDialogEntityID => ['AD3'], }, }, Possible => { Ticket => { DynamicField_Status => ['Approved'], }, }, }; $Self->{TicketAcl}->{'P1-AD4-1'} = { Properties => { Process => { ActivityDialogEntityID => ['AD4'], }, }, Possible => { Ticket => { DynamicField_Status => ['Order denied'], }, }, }; $Self->{TicketAcl}->{'P1-AD5-1'} = { Properties => { Process => { ActivityDialogEntityID => ['AD5'], }, }, Possible => { Ticket => { DynamicField_Status => ['Order placed'], }, }, }; $Self->{TicketAcl}->{'P1-AD6-1'} = { Properties => { Process => { ActivityDialogEntityID => ['AD6'], }, }, Possible => { Ticket => { DynamicField_Status => ['Shipment received'], }, }, };
Klicken Sie in den "Verfügbaren Prozesselementen" auf "Übergänge", anschließend klicken Sie auf "Erstelle neue Übergans-Aktion".
Abbildung: Neuen Übergang hinzufügen.
In dem öffnenden Popup füllen Sie bitte den "Übergangsnamen" aus, anschließend tragen Sie die benötigten Zustände ein. In diesem Beispiel werden wir nur einen Zustand und nur ein Feld benutzen. Für diese beiden lassen für den Linktyp auf "and" und wir werden den Match-Type-Wert als "String" nutzen.
Abildung: Neuen Übergang hinzufügen.
Nachdem alle Parameter und Werte gesetzt worden sind, klicken Sie auf die "Übermitteln"-Schaltfläche um die Werte zu speichern.
Erstellen Sie die folgenden Übergänge:
"Genehmigung" (T1)
Ein Übergang, der überprüft ob das Statusfeld auf "Genehmigung" gesetzt ist.
"Genehmigung verweigert" (T2)
Ein Übergang, der überprüft ob das Statusfeld auf "Genehmigung verweigert" gesetzt ist.
"Genehmigt" (T3)
Ein Übergang, der überprüft ob das Statusfeld auf "Genehmigung erteilt" gesetzt ist.
"Bestellung abgelehnt" (T4)
Ein Übergang, der überprüft ob das Statusfeld auf "Bestellung verweigert" gesetzt ist.
"Bestellung aufgegeben" (T5)
Ein Übergang, der überprüft ob das Statusfeld auf "Bestellung aufgegeben" gesetzt ist.
"Sendung empfangen" (T6)
Ein Übergang, der überprüft ob das Statusfeld auf "Sendung empfangen" gesetzt ist.
Klicken Sie auf "Übergangs-Aktionen" in den "Verfügbaren Prozesselementen", anschließend klicken Sie auf "Erstelle neue Übergans-Aktion".
Abbildung: Erstelle neue Übergangsaktion.
In dem öffnenden Popup füllen Sie bitte den "Übergangsnamen" und das "Übergangsaktionsmodul" aus, dann tragen Sie die benötigten und optionalen Parameternamen und Werte ein.
Alle Übergangsaktionsmodule befinden sich in Kernel/System/ProcessManagement/TransitionAction und die folgende Liste zeigt Ihnen alle Übergangsaktionen die mit diesem Release ausgeliefert werden
DynamicFieldSet
TicketArticleCreate
TicketCreate
TicketCustomerSet
TicketLockSet
TicketOwnerSet
TicketQueueSet
TicketResponsibleSet
TicketServiceSet
TicketSLASet
TicketStateSet
TicketTitleSet
TicketTypeSet
Jedes Modul hat seine eigenen und verschiedenen Parameter. Eine Übersicht aller benötigten und optionalen Parameter finden Sie unter Moduldokumentation.
From OTRS 4.0.1, parameters are not longer mandatory fixed values, but instead, they can inherit from the original ticket using format: <OTRS_Ticket_property>.
From OTRS 4.0.6, the format <OTRS_TICKET_property> is now supported, older format is still usable, but deprecated as it will be dropped in further versions.
Abbildung: Hinzufügen einer Übergangsaktion.
Nachdem alle Parameter und Werte gesetzt worden sind, klicken Sie auf die "Übermitteln"-Schaltfläche um die Werte zu speichern.
Erstellen Sie die folgenden Übergangs-Aktionen:
"Verschiebe das Prozessticket in die Management-Queue" (TA1)
Diese Aktion wird vermutlich ausgeführt wenn der Übergang "Approval" (T1) angewandt wurde.
"Ändere den Ticket-Verantwortlichen zu 'Manager'" (TA2)
Wird ausgeführt, wenn der Übergang "Approval" (T1) ausgeführt wurde.
"Verschiebe das Prozessticket in die 'Employees'-Queue" (TA3)
Wird ausgeführt, wenn:
Der Übergang "Approval denied" (T2) wird ausgeführt
Der Übergang "Order denied" (T4) wird ausgeführt.
Der Übergang "Shipment received" (T6) wird ausgeführt
Ändere den Ticket-Verantwortlichen zu 'Employee'" (TA4)
Wird ausgeführt, wenn:
Der Übergang "Approval denied" (T2) wird ausgeführt
Der Übergang "Order denied" (T4) wird ausgeführt
Der Übergang "Shipment received" (T6) wird ausgeführt
"Verschiebe das Prozessticket in die 'Purchasing'-Queue" (TA5)
Wird ausgeführt, wenn der Übergang "Approved" (T3) ausgeführt wurde.
"Verschiebe das Prozessticket in die 'Post office'-Queue" (TA6)
Wird ausgeführt, wenn der Übergang "Order placed (T5) ausgeführt wurde.
"Ticket erfolgreich schließen" (TA7)
Wird ausgeführt, wenn:
Der Übergang "Shipment received" (T6) wird ausgeführt
Ticket erfolglos schließen" (TA8)
Wird ausgeführt, wenn:
Der Übergang "Approval denied" (T2) wird ausgeführt
Der Übergang "Order denied" (T4) wird ausgeführt
Wie Sie sehen, gibt es Orte an denen gleiche Übergangsaktionen ausgeführt werden sollen. Deshalb ist es sinnvoll Übergangsaktionen frei mit Übergängen zu verknüpfen, um sie wiederverwenden zu können.
We chose the approach to see Activities as a basket which can contain one or more Activity Dialogs.
Klicken Sie auf "Aktivitäten" in den verfügbaren "Prozesselementen", anschließend klicken Sie auf "Erstelle neue Aktivität".
Abbildung: Erstelle neue Aktivitätsschaltfläche.
In the opened popup screen fill the "Activity Name", Then drap the required Activity Dialogs from the "Available Activity Dialogs" pool, and drop then into to the "Assigned Activity Dialogs" pool. This dialogs will be presented (in the ticket zoom screen) in the same order as it is defined on this screen translating from top to bottom, to left to right.
This order is specially important in the first Activity, since the first Activity Dialog for this activity is the only one that is presented when the process starts
Erstellen Sie die folgenden Aktivitäten:
"Aufnahme der Nachfrage" (A1)
Beinhaltet die Aktivität "Aufnahme der Nachfrage" (AD1)
"Genehmigung" (A2)
Beinhaltet die Aktivitäsdialoge "Genehmigung verweigert" (AD2) und "Genehmigt" (AD3)
"Bestellung" (A3)
Beinhaltet die Aktivitätsdialoge "Bestellung abgelehnt" (AD4) und "Bestellung aufgegeben" (AD5)
Eingehend (A4)
Beinhaltet den Aktivitätsdialog "Bestellung erhalten" (AD6)
"Prozess beendet" (A5): Das ist eine Aktivität ohne mögliche Aktivitätsdialoge. Sie wird nach "Genehmigung verweigert", "Genehmigt", "Bestellung abgelehnt", "Bestellung aufgegeben" oder "Bestellung erhalten" angezeigt und stellt das Ende des Prozesses dar.
Now we can clearly see that Activities are precisely defined states of a process ticket. After a successful Transition a process ticket moves from one Activity to another.
Let us conclude our example with the last missing piece in the puzzle, the Process as the a flow describer. In our case this is the whole ordering work-flow. Other processes could be office supply ordering or completely different processes.
The process has a starting point which consists of the start Activity and the start Activity Dialog. For any new book order, the start Activity Dialog (first Activity Dialog for the first Activity) is the first screen that is displayed. If this is completed and saved, the Process ticket will be created and can follow the configured work-flow.
The process also contains the directions for how the process ticket can move through the Process. Let's call this the "Path". It consists of the start Activity, one or more Transitions (possibly with Transition Actions), and other Activities.
Assuming that the Activities has already assigned their Activity Dialogs drag an Activity from the accordion (in the left part of the screen) and drop it into the canvas area (below process information). Notice that an arrow from the process start (green circle) to the Activity is placed automatically. (This is the first Activity and its first Activity Dialog is the first screen that will be shown when the process starts).
Abbildung: Ziehen der ersten Aktivität in die Arbeitsfläche.
Next, drag another Activity into the canvas too. now we will have two Activities in the canvas the first one is connected to the start point and the second has no connections, you can hover the mouse over each activity to reveal their own Activity Dialogs.
Abbildung: Ziehen der zweiten Aktivität in die Arbeitsfläche.
Then let's create the "Path" (connection) between this two Activities, for this we will use the Transitions, Click on Transitions in the accordion drag a Transition and drop it inside the first Activity, notice that the Activity change its color indicating that the Transition is attached, as soon as the Transition is dropped the end point of the Transition arrow will be placed next to the process start point. Drag the Transition arrow end point and drop it inside the other Activity to create the connection between the Activities.
Abbildung: Ziehen des Überganges in die Arbeitsfläche.
Now that the "Path" between the Actions is defined, then we need to assign the Transition Actions to the Transition, double click the Transition label (in the canvas), this will open a new popup window.
Abbildung: Verbinden von Aktivitäten mit Übergängen.
Drag the needed Transition Actions from Available Transition Actions pool and drop them into the Assigned Transition Actions pool and click on submit button.
Abbildung: Zuweisen von Übergangsaktionen. Assign Transition Actions.
Then back in the main process edit screen click on save button below the canvas to save all other changes.
Vervollständigen Sie den "Pfad" und fügen Sie folgende Aktivitäten, Übergänge und Übergangsaktionen hinzu:
Aufnahme der Nachfrage bis zur "Approval"
Startpunkt: Aktivität "Aufnahme der Nachfrage" (A1)
Möglicher Übergang: Approval (T1)
Wenn die Bedingung der Aktivität erfüllt ist, wird das Ticket in die Aktivität: Approval (A2) geschoben.
Zusätzlich werden die folgenden Übergangs-Aktionen ausgeführt:
"Verschiebe das Ticket in die 'Managment' Queue (TA1)
"Setze den Ticketverantwortlichen auf 'Manager'" (TA2)
The Activity: "Recording the demand" (A1) is a defined step of the process ticket, where there is the possibility for the Transition: "Approval" (T1). If this applies, the ticket will move to the next Activity: "Approval" (A2), and the Transition Actions: "Moving the ticket into the 'Management' Queue" (TA1) and "Set ticket responsible to 'manager'" (TA2) are executed. In the Activity: "Approval" (A2), the Activity Dialogs: "Approval denied" (AD2) and "Approved" (AD3) are available.
Genehmigung
Startpunkt: Aktivität "Approval" (A2)
Mögliche Übergänge:
"Genehmigung verweigert" (T2)
Wenn dies zutrifft, wird das Ticket in die Aktivität: "Process complete (A5) geschoben.
Zusätzlich werden die folgenden Übergangs-Aktionen ausgeführt:
"Verschiebe das Ticket in die 'Employees' Queue (TA3)
"Setze den Ticketverantwortlichen auf 'Employee'" (TA4)
Ticket erfolglos schließen" (TA8)
"Genehmigt" (T3)
Wenn dies zutrifft, wird das Ticket in die Aktivität: "Order" (A3) geschoben.
Zusätzlich werden die folgenden Übergangs-Aktionen ausgeführt:
"Verschiebe das Ticket in die 'Purchasing' Queue (TA5)
We can see that from the current Activity, which defines a step of the process ticket, there are one or more possibilities for Transition which have exactly one target Activity (and possibly one or more Transition Actions).
Auftrag
Startpunkt: Aktivität "Order" (A3)
Mögliche Übergänge:
"Bestellung abgelehnt" (T4)
Wenn dies zutrifft, wird das Ticket in die Aktivität: "Process complete (A5) geschoben.
Zusätzlich werden die folgenden Übergangs-Aktionen ausgeführt:
"Verschiebe das Ticket in die 'Employees' Queue (TA3)
"Setze den Ticketverantwortlichen auf 'Employee'" (TA4)
Ticket erfolglos schließen" (TA8)
"Bestellung aufgegeben" (T5)
Wenn dies zutrifft, wird das Ticket in die Aktivität: "Incoming" (A5) geschoben.
Zusätzlich werden die folgenden Übergangs-Aktionen ausgeführt:
"Verschiebe das Ticket in die 'Post office' Queue (TA6)
Eingehend
Startpunkt: Aktivität "Incoming" (A4)
Mögliche Übergänge:
"Sendung empfangen" (T6)
Wenn dies zutrifft, wird das Ticket in die Aktivität: "Process complete (A5) geschoben.
Zusätzlich werden die folgenden Übergangs-Aktionen ausgeführt:
"Verschiebe das Ticket in die 'Employees' Queue (TA3)
"Setze den Ticketverantwortlichen auf 'Employee'" (TA4)
"Ticket erfolgreich schließen" (TA7)
Der komplette Pfad für den Buchbestellprozess schaut wie folgt aus:
Abbildung: vollständiger Buchbestellprozesspfad.
After you finish the process path please click on "Save" button in the lower part of the canvas and then click on "Synchronize All Processes" button. This will gather all processes information form the Database and create a cache file (in Perl language). This cache file is acctually the processes configuration that the system will use to create or use process tickets.
Any change that is made of the process (in the GUI) will require to re-synchronize the cache file in order to get the change reflected in the system.
It is also possible to import the whole process from a YAML file, but it is still necessary to create all Dynamic Fields, Users, Queues, etc that are needed by each process before the import.
Notice that if the process requires the use of ACLs those are also needed to be set manually.
Im folgenden sehen Sie die komplette YAML-Datei für den Buchbestellprozess:
--- Activities: A1: ActivityDialogs: - AD1 ChangeTime: 2012-11-23 14:49:22 Config: ActivityDialog: 1: AD1 CreateTime: 2012-11-23 11:49:38 EntityID: A1 ID: 151 Name: Recording the demand A2: ActivityDialogs: - AD2 - AD3 ChangeTime: 2012-12-13 00:55:12 Config: ActivityDialog: 1: AD2 2: AD3 CreateTime: 2012-11-23 11:50:11 EntityID: A2 ID: 152 Name: Approval A3: ActivityDialogs: - AD4 - AD5 ChangeTime: 2012-11-23 18:12:14 Config: ActivityDialog: 1: AD4 2: AD5 CreateTime: 2012-11-23 11:50:35 EntityID: A3 ID: 153 Name: Order A4: ActivityDialogs: - AD6 ChangeTime: 2012-11-23 18:12:35 Config: ActivityDialog: 1: AD6 CreateTime: 2012-11-23 11:51:00 EntityID: A4 ID: 154 Name: Incoming A5: ActivityDialogs: [] ChangeTime: 2012-11-23 11:51:33 Config: {} CreateTime: 2012-11-23 11:51:33 EntityID: A5 ID: 155 Name: Process complete ActivityDialogs: AD1: ChangeTime: 2012-12-06 02:16:21 Config: DescriptionLong: '' DescriptionShort: Recoding the demand FieldOrder: - DynamicField_Author - DynamicField_ISBN - DynamicField_Title - DynamicField_Status Fields: DynamicField_Author: DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 DynamicField_ISBN: DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 DynamicField_Status: DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 DynamicField_Title: DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 Interface: - AgentInterface Permission: '' RequiredLock: 0 SubmitAdviceText: '' SubmitButtonText: '' CreateTime: 2012-11-23 14:34:43 EntityID: AD1 ID: 154 Name: Recording the demand AD2: ChangeTime: 2012-11-23 14:57:41 Config: DescriptionLong: '' DescriptionShort: Approval denied FieldOrder: - Article - DynamicField_Status Fields: Article: Config: ArticleType: note-internal DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 DynamicField_Status: DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 Interface: - AgentInterface Permission: '' RequiredLock: 0 SubmitAdviceText: '' SubmitButtonText: Deny Request CreateTime: 2012-11-23 14:36:39 EntityID: AD2 ID: 155 Name: Approval denied AD3: ChangeTime: 2012-12-14 03:14:23 Config: DescriptionLong: '' DescriptionShort: Approved FieldOrder: - DynamicField_Status Fields: DynamicField_Status: DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 Interface: - AgentInterface Permission: '' RequiredLock: 0 SubmitAdviceText: '' SubmitButtonText: Approve Request CreateTime: 2012-11-23 14:37:35 EntityID: AD3 ID: 156 Name: Approved AD4: ChangeTime: 2012-11-23 14:58:52 Config: DescriptionLong: '' DescriptionShort: Order rejected FieldOrder: - Article - DynamicField_Status Fields: Article: Config: ArticleType: note-internal DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 DynamicField_Status: DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 Interface: - AgentInterface Permission: '' RequiredLock: 0 SubmitAdviceText: '' SubmitButtonText: Reject Order CreateTime: 2012-11-23 14:38:48 EntityID: AD4 ID: 157 Name: Order rejected AD5: ChangeTime: 2012-12-06 02:20:12 Config: DescriptionLong: '' DescriptionShort: Order placed FieldOrder: - DynamicField_DeliveryDate - DynamicField_Price - DynamicField_Supplier - DynamicField_Status Fields: DynamicField_DeliveryDate: DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 DynamicField_Price: DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 DynamicField_Status: DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 DynamicField_Supplier: DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 Interface: - AgentInterface Permission: '' RequiredLock: 0 SubmitAdviceText: '' SubmitButtonText: Place Order CreateTime: 2012-11-23 14:41:28 EntityID: AD5 ID: 158 Name: Order placed AD6: ChangeTime: 2012-11-23 14:42:43 Config: DescriptionLong: '' DescriptionShort: Shipment received FieldOrder: - DynamicField_DateOfReceipt - DynamicField_Status Fields: DynamicField_DateOfReceipt: DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 DynamicField_Status: DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 Interface: - AgentInterface Permission: '' RequiredLock: 0 SubmitAdviceText: '' SubmitButtonText: '' CreateTime: 2012-11-23 14:42:43 EntityID: AD6 ID: 159 Name: Shipment received Process: Activities: - A1 - A2 - A3 - A4 - A5 ChangeTime: 2012-12-06 02:31:59 Config: Description: The process to order a book Path: A1: T1: ActivityEntityID: A2 TransitionAction: - TA2 - TA1 A2: T2: ActivityEntityID: A5 TransitionAction: - TA3 - TA4 - TA8 T3: ActivityEntityID: A3 TransitionAction: - TA5 A3: T4: ActivityEntityID: A5 TransitionAction: - TA3 - TA4 - TA8 T5: ActivityEntityID: A4 TransitionAction: - TA6 A4: T6: ActivityEntityID: A5 TransitionAction: - TA3 - TA4 - TA7 A5: {} StartActivity: A1 StartActivityDialog: AD1 CreateTime: 2012-11-23 11:45:12 EntityID: P1 ID: 94 Layout: A1: left: 172 top: 63 A2: left: 402 top: 156 A3: left: 649 top: 255 A4: left: 774 top: 391 A5: left: 194 top: 410 Name: Book ordering State: Active StateEntityID: S1 TransitionActions: - TA1 - TA2 - TA3 - TA4 - TA8 - TA5 - TA3 - TA4 - TA8 - TA6 - TA3 - TA4 - TA7 Transitions: - T1 - T2 - T3 - T4 - T5 - T6 TransitionActions: TA1: ChangeTime: 2012-11-23 16:01:37 Config: Config: Queue: Management Module: Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet CreateTime: 2012-11-23 15:50:59 EntityID: TA1 ID: 61 Name: Move the process ticket into the "Management" queue TA2: ChangeTime: 2012-11-23 16:02:12 Config: Config: Responsible: manager Module: Kernel::System::ProcessManagement::TransitionAction::TicketResponsibleSet CreateTime: 2012-11-23 15:58:22 EntityID: TA2 ID: 62 Name: Change ticket responsible to "manager" TA3: ChangeTime: 2012-11-24 14:27:02 Config: Config: Queue: Employees Module: Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet CreateTime: 2012-11-23 16:02:54 EntityID: TA3 ID: 63 Name: Move the process ticket into the "Employees" queue TA4: ChangeTime: 2012-11-23 16:04:06 Config: Config: Responsible: Employee Module: Kernel::System::ProcessManagement::TransitionAction::TicketResponsibleSet CreateTime: 2012-11-23 16:04:06 EntityID: TA4 ID: 64 Name: Change ticket responsible to "Employee" TA5: ChangeTime: 2012-12-06 02:18:34 Config: Config: Queue: Purchasing Module: Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet CreateTime: 2012-11-23 16:04:54 EntityID: TA5 ID: 65 Name: Move process ticket into the "Purchasing" queue TA6: ChangeTime: 2012-12-06 02:18:48 Config: Config: Queue: Post office Module: Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet CreateTime: 2012-11-23 16:06:20 EntityID: TA6 ID: 66 Name: Move process ticket into the "Post office" queue TA7: ChangeTime: 2012-12-06 02:29:55 Config: Config: State: closed successful Module: Kernel::System::ProcessManagement::TransitionAction::TicketStateSet CreateTime: 2012-12-06 02:29:27 EntityID: TA7 ID: 67 Name: Close ticket successfully TA8: ChangeTime: 2012-12-06 02:31:12 Config: Config: State: closed unsuccessful Module: Kernel::System::ProcessManagement::TransitionAction::TicketStateSet CreateTime: 2012-12-06 02:31:12 EntityID: TA8 ID: 68 Name: Close ticket unsuccessfully Transitions: T1: ChangeTime: 2012-11-23 15:12:20 Config: Condition: 1: Fields: DynamicField_Status: Match: Approval Type: String Type: and ConditionLinking: and CreateTime: 2012-11-23 11:53:52 EntityID: T1 ID: 94 Name: Approval T2: ChangeTime: 2012-11-23 15:12:50 Config: Condition: 1: Fields: DynamicField_Status: Match: Approval denied Type: String Type: and ConditionLinking: and CreateTime: 2012-11-23 11:54:26 EntityID: T2 ID: 95 Name: Approval denied T3: ChangeTime: 2012-11-23 15:13:29 Config: Condition: 1: Fields: DynamicField_Status: Match: Approved Type: String Type: and ConditionLinking: and CreateTime: 2012-11-23 11:54:54 EntityID: T3 ID: 96 Name: Approved T4: ChangeTime: 2012-11-23 15:14:08 Config: Condition: 1: Fields: DynamicField_Status: Match: Order denied Type: String Type: and ConditionLinking: and CreateTime: 2012-11-23 11:55:25 EntityID: T4 ID: 97 Name: Order denied T5: ChangeTime: 2012-11-23 18:30:33 Config: Condition: 1: Fields: DynamicField_Status: Match: Order placed Type: String Type: and ConditionLinking: and CreateTime: 2012-11-23 11:56:15 EntityID: T5 ID: 98 Name: Order placed T6: ChangeTime: 2012-11-23 15:15:30 Config: Condition: 1: Fields: DynamicField_Status: Match: Shipment received Type: String Type: and ConditionLinking: and CreateTime: 2012-11-23 11:56:48 EntityID: T6 ID: 99 Name: Shipment received
Ein Prozess modelliert den Pfad eines Workflows/Prozess. Die Wegpunkte auf diesem Pfad können Aktivitäten oder Übergänge sein. Auf diese wird später noch genauer eingegangen.
Die Prozesskonfiguration kann in der Datei
Kernel/Config.pm
vorgenommen werden, aber es wird
dringend empfohlen neue Dateien, wie
Kernel/Config/Files/MeinProzess.pm
, zu
erstellen. Beachten Sie das die GUI die Datei
Kernel/Config/File/ZZZProcessManagement
automatisch
generiert, somit sollte dieser Dateiname nicht für eigene Prozesse verwendet
werden. Andererseits wird diese Datei überschrieben, sobald Sie Prozesse
synchronisieren. Anbei eine Beispielprozesskonfiguration (aus dem
Prozesscache):
$Self->{'Process'} = { 'P1' => { Name => 'Book order', CreateTime => '16-02-2012 13:37:00', CreateBy => '1', ChangeTime => '17-02-2012 13:37:00', ChangeBy => '1', State => 'Active', StartActivity => 'A1', StartActivityDialog => 'AD1', Path => { 'A1' => { 'T1' => { ActivityEntityID => 'A2', }, }, 'A2' => { 'T2' => { ActivityEntityID => 'A3', }, }, }, }, 'P2' => { Name => 'IT order', CreateTime => '26-02-2012 13:37:00', CreateBy => '1', ChangeTime => '27-02-2012 13:37:00', ChangeBy => '1', State => 'Active', StartActivity => 'A2', StartActivityDialog => 'AD2', Path => { 'A2' => { 'T3' => { ActivityEntityID => 'A4', }, }, }, } };
Der Name des Prozesses, dieser kann vom Agenten ausgewählt werden, wenn ein neues Prozessticket erstellt wird.
Definiert den Status eines Prozesses. Möglich Werte sind:
'Active' sind alle Prozesse, welche in neuen Prozesstickets genutzt werden können.
'FadeAway' sind Prozesse, welche nicht mehr für neue Tickets genutzt werden können, aber bereits existierende Tickets können diesen Prozess immer noch ausführen.
'Inactive' Prozesse sind deaktiviert und können nicht neue und bereits existierende Tickets genutzt werden.
Wenn ein neues Prozessticket erstellt wird, muss eine Startaktivität definiert werden. Sobald das Ticket erstellt wurde, wird diese Aktivität gesetzt und als Basis für die erste Prüfung des Übergangs genutzt.
Für neue Prozesstickets muss ein StartActivityDialog definiert werden. Dieser wird angezeigt, wenn ein neues Prozessticket erstellt wird (nachdem der Prozess ausgewählt wurde). Das Ticket existiert noch nicht, wird aber nach Übermittlung des StartActivityDialog erstellt.
Der Pfad beinhaltet die aktuelle Prozessstruktur der Aktivitäten und möglichen Übergänge zwischen ihnen.
'A1' => { 'T1' => { ActivityEntityID => 'A2', }, 'T2' => { ActivityEntityID => 'A3', }, 'T3' => { ActivityEntityID => 'A4', TransitionAction => ['TA1', 'TA2'], }, },
Wenn ein Prozessticket in Aktivität 'A1' ist, hat es 3 mögliche Wege um zu einer anderen Aktivität zugelangen. In den Übergängen 'T1' bis 'T3' wurden Bedingungen festgelegt, die ein Prozessticket erfüllen muss um zu einer anderen Aktivität zu gelangen.
If in this case all the values of the process ticket and its dynamic fields that are needed for the Transition 'T2' are correct, the ticket will be moved from Activity 'A1' to 'A3'. After an ActivityDialog is submitted, or any other change is made to a ticket, it will be checked for possible Transitions from the current Activity. If multiple Transitions are possible, the first one will be used (based on nummerical sorting of the TransitionIDs).
Additionally, it is possible to assign Transition Actions to Transitions in the Path configuration. These are modules which are executed after a successful Transition. They have to be specified in array form as in the example, we'll talk about the details later.
An Activity contains one or more Activity Dialogs and models a 'step' in the process. All Activity Dialogs of the current Activity are displayed in the ticket zoom and can be used until the conditions of a Transition are fulfilled.
Hier sehen Sie eine Beispiel Aktivitätskonfiguration:
$Self->{'Process::Activity'} = { 'A1' => { Name => 'Activity 1 optional', CreateTime => '16-02-2012 13:37:00', CreateBy => '1', ChangeTime => '17-02-2012 13:37:00', ChangeBy => '1', ActivityDialog => { 1 => 'AD1', }, }, 'A2' => { Name => 'Activity 2 optional', CreateTime => '16-02-2012 13:37:00', CreateBy => '1', ChangeTime => '17-02-2012 13:37:00', ChangeBy => '1', ActivityDialog => { 1 => 'AD5', 2 => 'AD6', 3 => 'AD1', }, }, };
Ein Aktivitätsdialog ist eine besondere Oberfläche und kann in verschiedenen Aktivitäten wiederverwendet werden.
Hier sehen Sie eine Beispiel Konfiguration:
$Self->{'Process::ActivityDialog'} = { 'AD1' => { Name => 'ActivityDialog 1 optional', DescriptionShort => 'Basic info', DescriptionLong => 'Please insert the necessesary basic information for IT orders', CreateTime => '28-02-2012 13:37:00', CreateBy => '1', ChangeTime => '29-02-2012 13:37:00', ChangeBy => '1', Fields => { PriorityID => { DescriptionShort => 'Priority ID', DescriptionLong => 'Enter the priority here', Display => 2, }, }, FieldOrder => [ 'PriorityID' ], SubmitAdviceText => 'Note: If you submit the form...', SubmitButtonText => 'Send request', }, 'AD2' => { Name => 'ActivityDialog 2 optional', DescriptionShort => 'Basic info', DescriptionLong => 'Please insert the necessesary basic information for Book orders', CreateTime => '28-02-2012 13:37:00', CreateBy => '1', ChangeTime => '29-02-2012 13:37:00', ChangeBy => '1', Fields => { StateID => { DescriptionShort => 'State ID', DescriptionLong => 'Enter the state here', Display => 2, DefaultValue => '2', }, Queue => { DescriptionShort => 'Queue ID', DescriptionLong => 'Enter the queue here', Display => 2, DefaultValue => 'Raw', }, Title => { DescriptionShort => 'Title', DescriptionLong => 'Enter the title here', Display => 1, DefaultValue => 'Default Title', }, DynamicField_Anzahl => { DescriptionShort => 'Amount', DescriptionLong => 'Enter the amount here', Display => 2, DefaultValue => '4', }, }, FieldOrder => [ 'DynamicField_Anzahl', 'StateID', 'Queue', 'Title' ], SubmitAdviceText => 'Note: If you submit the form...', SubmitButtonText => 'Send request', }, };
Beinhaltet alle Felder, welche in diesem Aktivitätsdialog angezeigt werden können. Die folgenden Felder können zurzeit benutzt werden:
Title State StateID Priority PriorityID Lock LockID Queue QueueID Customer CustomerID CustomerNo CustomerUserID Owner OwnerID Type TypeID SLA SLAID Service ServiceID Responsible ResponsibleID PendingTime DynamicField_$FieldName # for all dynamic fields
Beispielkonfiguration eines einfachen Feldes:
StateID => { DescriptionShort => 'State ID', DescriptionLong => 'Enter the state here', Display => 2, DefaultValue => '2', },
The field "Article" is a special case. If it is present in a "Fields" configuration, the Activity Dialog will contain a complete Richtext editor with subject field and attachment handling. The entered text will then be added to the ticket as an article and sent by email. Let's see an example Article field configuration:
Article => { DescriptionShort => 'Please insert your comment here.', DescriptionLong => '', Display => 1, Config => { ArticleType => 'note-internal', LabelSubject => '', LabelBody => '', }, },
Werfen wir einen Blick auf die Optionen der Konfigurationsfelder:
Optionale längere Beschreibung, welche bei MouseOver über dem Feld angezeigt wird. Zum Beispiel Hinweise, wie das Feld ausgefüllt werden soll.
Steuert, ob das Feld angezeigt und/oder verpflichtend ist. Möglich Werte:
'0': Das Feld ist unsichtbar. Das kann hilfreich sein, wenn Feld-Werte automatisch gesetzt werden sollen. Der konfigurierte Standard-Wert wird in diesem Fall gespeichert.
'1': Das Feld ist sichtbar, aber optional.
'2': Das Feld ist sichtbar und verpflichtend. Die folgenden Felder können nur unsichtbar oder verpflichtend sein:
QueueID Queue State StateID Lock LockID Priority PriorityID Type TypeID
Wenn Felder als optional konfiguriert sind und kein Wert vom Benutzer eingegeben wurde, wird der Standard-Wert übernommen, wenn der Aktivitätsdialog vom Benutzer übermittelt wurde.
For fields with 'ID' (like QueueID, OwnerID), this refers to the database ID of the value. For other fields without 'ID' (like Queue, Owner), the DefaultValue must contain the value itself. Example:
Queue => { DescriptionShort => 'Queue', DescriptionLong => 'Hier die Queue eingeben', Display => 2, DefaultValue => 'Raw', },
Here the display order of the fields is configured. IMPORTANT: Invisible fields also must be configured here, because only configured fields will be considered when saving. Fields which are not configured will not be saved.
Optionaler Text, der direkt über der Übermitteln-Schaltfläche angezeigt wird und zusätzliche Hilfestellungen oder Ratschläge gibt.
Ein Übergang entscheidet - basierend auf konfigurierbaren Bedingungen - welchen Pfad der Prozess nimmt, zum Beispiel zu welcher Aktivität das Prozessticket spring.
Hier sehen Sie ein Beispiel:
$Self->{'Process::Transition'} = { 'T1' => { Name => 'Transition 1', CreateTime => '14-03-2012 13:37:00', # optional CreateBy => '1', # optional ChangeTime => '15-03-2012 13:37:00', # optional ChangeBy => '15-03-2012 13:37:00', # optional Condition => { Cond1 => { Fields => { StateID => { Type => 'String', Match => '1', }, }, }, }, }, 'T2' => { Name => 'Transition 2 optional', CreateTime => 'DATE', # optional CreateBy => 'USERID', # optional ChangeTime => 'DATE', # optional ChangeBy => 'USERID', # optional Condition => { Cond1 => { Queue => 'Raw', DynamicField_Farbe => '2', DynamicField_Anzahl => '1', }, }, }, };
Beinhaltet alle Bedingungen, die notwendig sind, damit der Übergang wirksam ist. Beispiel:
Condition => { Type => 'and', Cond1 => { Type => 'and', Fields => { StateID => { Type => 'String', Match => '1', }, DynamicField_Marke => { Type => 'String', Match => 'VW', }, }, Cond2 => { Type => 'and', Fields => { Queue => { Type => 'String', Match => 'Raw', }, }, }, },
Werfen wir einen Blick auf den Zustand der Konfiguration im Detail.
Specifies the way the different condition elements are connected to each other. Possible values:
'UND': Das ist der Standard. Alle Bedingungen müssen erfüllt sein damit der Übergang angewendet wird.
'ODER': Mindestens eine Bedingung muss erfüllt sein.
'XOR': Genau eine Bedingung muss erfüllt sein, nicht mehr.
This is the name of an example condition. It can be freely chosen. Conditions are evaluated in sorted order.
Specifies the way how the individual field tests of this condition are connected to each other. Possible values:
'UND': Das ist der Standard. Alle Feldtests müssen erfüllt sein damit die Bedingung erfüllt ist.
'ODER': Mindestens ein Feldtest muss erfüllt sein.
'XOR': Genau ein Feldtest muss erfüllt sein, nicht mehr.
Specifies the particular fields whose values should be tested. From our example:
Fields => { StateID => { Type => 'String', Match => '1', },
Beispiel für einen Feldnamen. Die folgenden Ticketfelder können verwendet werden:
Title State StateID Priority PriorityID Lock LockID Queue QueueID Customer CustomerID CustomerNo CustomerUserID Owner OwnerID Type TypeID SLA SLAID Service ServiceID Responsible ResponsibleID DynamicField_$FieldName # for all DynamicFields
Beim Testen eines Feldes mit "ID" (wie SLAID), wird die Datenbank-ID des Feldes für die Prüfung verwendet werden, für andere Bereiche (wie SLA) wird der Ist-Wert für den Test verwendet.
Bestimmt die Art der Feldtests. Mögliche Werte:
'String': Vergleicht den Feldwert mit der in 'Match' angegebene Zeichenfolge. Stimmt überein, wenn sie genau gleich sind.
'Hash': Vergleicht den Feldwert (Hash) mit dem in 'Match' angegebenen Hash. Alle Hash-Werte müssen identisch sein.
'Array': Vergleicht den Wert des Feldes (Array) mit dem in 'Match' angegebene Array. Beide Listen müssen gleich sein.
'Regex': The field value can be tested with a regular expression. It is important that 'Match' contains qr{}xms as a base condition. Between the braces the actual regular expression can be noted.
'Module': Allows you to use a perl module for condition checking. If it
returns 1, the check was positive. You can find an example module in
Kernel/System/ProcessManagement/TransitionValidation/ValidateDemo.pm
.
Transition Actions are actions which can be triggered after successfully applied transitions (when a process ticket moves from one activity to another). These Transition Actions can be used to perform different changes on the ticket, e. g. change the Queue or the Owner of the ticket, and you can also create your own Transition Actions to perform other complex changes.
Hier sehen Sie ein Beispiel:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Queue Move', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet', Config => { Queue => 'Junk', UserID => 123, }, }, };
This parameter contains all settings which are required for the module. Its content depends on the particular Transition Action module which is used. Please see the documentation of the individual modules for details. In our example, only the Queue must be specified, Nevertheless we are also sending UserID parameter, by using the UserID parameter, the transition action will be executed impersonating the user with the given UserID.
The use of UserID inside the "Config" parameter of a Transition Action is accepted by all Transition Actions (since OTRS 3.2.4), in this example it could be particularly important if the user that triggers the Transition does not have permissions to move the ticket to the queue 'Junk', while the user with the UserID 123 might have.
Um Übergangs-Aktions-Module mehrfach zu verwenden, können Sie einfach verschiedene Übergangsaktionen konfigurieren. Beispiel:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Queue Move Junk', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet', Config => { Queue => 'Junk', }, }, 'TA2' => { Name => 'Queue Move Raw', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet', Config => { Queue => 'Raw', }, }, };
Here the same module is used to move a process ticket into the 'Raw' queue, and another time to move it into the junk queue. The Transition Action which must be used for a particular Transition is determined from the 'Path' setting of the Process configuration.
OTRS comes with several Transition Actions that can be used in your processes. Here you can find their documentation and how they need to be configured.
Fügt eins oder mehrere dynamischen Felder an ein Prozessticket an. Beispiel:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Set DynamicField Master to Master and Approved to 1', Module => 'Kernel::System::ProcessManagement::TransitionAction::DynamicFieldSet', Config => { MasterSlave => 'Master', Approved => '1', }, }, };
'Name' definiert den Namen der konfigurierten Übergangsaktion.
'MasterSlave' and 'Approved' are given as examples of DynamicField names. The values of the fields ('Master' and '1') will be set by this TransitionAction.
Erzeugt einen Artikel und wird verwendet um Notizen oder E-Mail Antworten erzeugen. Beispiel:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Article Create Note Internal', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketArticleCreate', Config => { ArticleType => 'note-internal', # note-external|phone|fax|sms|... # excluding any email type SenderType => 'agent', # agent|system|customer ContentType => 'text/plain; charset=ISO-8859-15', # or optional Charset & MimeType Subject => 'some short description', # required Body => 'the message text', # required HistoryType => 'OwnerUpdate', # EmailCustomer|Move|AddNote|PriorityUpdate|WebRequestCustomer|... HistoryComment => 'Some free text!', From => 'Some Agent <email@example.com>', # not required but useful To => 'Some Customer A <customer-a@example.com>', # not required but useful Cc => 'Some Customer B <customer-b@example.com>', # not required but useful ReplyTo => 'Some Customer B <customer-b@example.com>', # not required InReplyTo => '<asdasdasd.12@example.com>', # not required but useful References => '<asdasdasd.1@example.com> <asdasdasd.12@example.com>', # not required but useful NoAgentNotify => 0, # if you don't want to send agent notifications AutoResponseType => 'auto reply', # auto reject|auto follow up|auto reply/new ticket|auto remove ForceNotificationToUserID => [ 1, 43, 56 ], # if you want to force somebody ExcludeNotificationToUserID => [ 43, 56 ], # if you want full exclude somebody from notfications, # will also be removed in To: line of article, # higher prio as ForceNotificationToUserID ExcludeMuteNotificationToUserID => [ 43, 56 ], # the same as ExcludeNotificationToUserID but only the # sending gets muted, agent will still shown in To: # line of article }, }, };
'Name' specifies the name of the configured TransitionAction. It can be freely chosen, but should reflect the purpose of the configured action.
'ArticleType' definiert den Typ des Artikels, der erstellt werden soll. Mögliche Werte: phone, fax, sms, webrequest, note-internal, note-external and note-report.
SenderType definiert den Absendertyp des Artikel. Mögliche Werte sind: Agent, System, Customer.
'ContentType' definiert den Inhaltstyp des Artikels. Mögliche Werte: 'text/plain; charset=ISO-8859-15' or any other valid charset and mime type.
'Betreff' definiert den Artikeltitel. Verfplichtend.
'Body' definiert den Artikelinhalt. Verpflichtend
Der Historientyp definiert den Typ des Historieneintrages. Mögliche Werte sind: AddNote, ArchiveFlagUpdate, Bounce, CustomerUpdate, EmailAgent, EmailCustomer, EscalationResponseTimeNotifyBefore, EscalationResponseTimeStart, EscalationResponseTimeStop, EscalationSolutionTimeNotifyBefore, EscalationSolutionTimeStart, EscalationSolutionTimeStop, EscalationUpdateTimeNotifyBefore, EscalationUpdateTimeStart, EscalationUpdateTimeStop, FollowUp, Forward, Lock, LoopProtection, Merged, Misc, Move, NewTicket, OwnerUpdate, PhoneCallAgent, PhoneCallCustomer, PriorityUpdate, Remove, ResponsibleUpdate, SendAgentNotification, SendAnswer, SendAutoFollowUp, SendAutoReject, SendAutoReply, SendCustomerNotification, ServiceUpdate, SetPendingTime, SLAUpdate, StateUpdate, Subscribe, SystemRequest, TicketDynamicFieldUpdate, TicketLinkAdd, TicketLinkDelete, TimeAccounting, TypeUpdate, Unlock, Unsubscribe, WebRequestCustomer.
'HistoryContent' definiert den Inhalt von Historieneinträgen.
'Von', 'An', 'Cc' und 'ReplyTo' nehmen E-Mailadressen in der oben angegebenen Schreibweise.
'InReplyTo' und 'References' nehmen E-Mailnachrichten-IDs
'NoAgentNotify' - Ist dieser Wert auf 1 gesetzt, werden keine E-Mailbenachrichtigungen an Agenten verschickt.
'AutoResponseType' kann die folgenden Werte annehmen: Auto FollowUp, Auto-Reject, Auto-Remove, Auto-Reply, Auto-Reply/New Ticket.
'ForceNotificationToUserID', 'ExcludeNotificationToUserID', 'ExcludeMuteNotificationToUserID' können eine Liste verschiedener User beinhalten, die entweder immer benachrichtigt, nie benachrichtigt oder als benachrichtigt aufgeführt werden, aber keine Benachrichtigungs-EMail erhalten.
Erstellt ein Ticket mit einem Artikel, das neue Ticket kann mit einem Prozessticket verlinkt werden. Beispiel:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Ticket Create', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketCreate', Config => { # ticket required: Title => 'Some Ticket Title', Queue => 'Raw', # or QueueID => 123, Lock => 'unlock', Priority => '3 normal', # or PriorityID => 2, State => 'new', # or StateID => 5, CustomerID => '123465', CustomerUser => 'customer@example.com', OwnerID => 'someuserlogin', # or OwnerID => 123, # ticket optional: TN => $TicketObject->TicketCreateNumber(), # optional Type => 'Incident', # or TypeID => 1, not required Service => 'Service A', # or ServiceID => 1, not required SLA => 'SLA A', # or SLAID => 1, not required ResponsibleID => 123, # not required ArchiveFlag => 'y', # (y|n) not required PendingTime => '2011-12-23 23:05:00', # optional (for pending states) PendingTimeDiff => 123 , # optional (for pending states) # article required: ArticleType => 'note-internal', # note-external|phone|fax|sms|... # excluding any email type SenderType => 'agent', # agent|system|customer ContentType => 'text/plain; charset=ISO-8859-15', # or optional Charset & MimeType Subject => 'some short description', # required Body => 'the message text', # required HistoryType => 'OwnerUpdate', # EmailCustomer|Move|AddNote|PriorityUpdate|WebRequestCustomer|... HistoryComment => 'Some free text!', # article optional: From => 'Some Agent <email@example.com>', # not required but useful To => 'Some Customer A <customer-a@example.com>', # not required but useful Cc => 'Some Customer B <customer-b@example.com>', # not required but useful ReplyTo => 'Some Customer B <customer-b@example.com>', # not required MessageID => '<asdasdasd.123@example.com>', # not required but useful InReplyTo => '<asdasdasd.12@example.com>', # not required but useful References => '<asdasdasd.1@example.com> <asdasdasd.12@example.com>', # not required but useful NoAgentNotify => 0, # if you don't want to send agent notifications AutoResponseType => 'auto reply' # auto reject|auto follow up|auto reply/new ticket|auto remove ForceNotificationToUserID => [ 1, 43, 56 ], # if you want to force somebody ExcludeNotificationToUserID => [ 43,56 ], # if you want full exclude somebody from notifications, # will also be removed in To: line of article, # higher prio as ForceNotificationToUserID ExcludeMuteNotificationToUserID => [ 43,56 ], # the same as ExcludeNotificationToUserID but only the # sending gets muted, agent will still shown in To: # line of article TimeUnit => 123 # other: DynamicField_NameX => $Value, LinkAs => $LinkType, # Normal, Parent, Child, etc. (respective original ticket) UserID => 123, # optional, to override the UserID from the logged user }
'Name' specifies the name of the configured TransitionAction. It can be freely chosen, but should reflect the purpose of the configured action.
'Title' Der Ticket-Titel
'Queue' oder 'QueueID' gibt den Namen oder die ID der Queue an, in der das neue Ticket erstellt werden soll
'Lock' oder 'LockID' setzt den "gesperrt"-Status des Tickets.
'Priority' oder 'PriorityID' gibt den Namen oder die ID der Priorität des neuen Tickets an.
'State' oder 'StateID' gibt den Namen oder die ID des Status des neuen Tickets an.
'CustomerID', die Kundennummer die im neuen Ticket gesetzt werden soll.
'CustomerUser', der Login des Kunden der dem Ticket zugewiesen wird.
'Owner' or 'OwnerID', specifies the login or id of the agent that will be the new ticket owner.
'TN', eigene Nummer für das neue Ticket.
'Type' oder 'TypeID' gibt den Namen oder die ID des Tickettyps an, der im neuen Ticket verwendet werden soll.
'Service' oder 'ServiceID' gibt den Namen oder die ID des Services an, der im neuen Ticket verwendet wird.
'SLA' oder 'SLAID' gibt den Namen oder die ID an, die im neuen Ticket verwendet werden soll.
'ResponsibleID', die ID des Agenten, der Verantwortlich für das neue TIcket ist.
'PendingTime', eine vordefinierte Zeit um die Warten-Zeiten zu setzen, wenn der Ticket-Status zu einem Warten-Statustyp gehört.
'PendingTime', ist eine dynamische vordefinierte Zeit (in Sekunden vom aktuellen Datum/Zeit) um die Warten-Zeiten zu setzen, wenn der Ticket-Status zu einem Warten-Statustyp gehört.
'ArticleType' definiert den Typ des Artikels, der erstellt werden soll. Mögliche Werte: phone, fax, sms, webrequest, note-internal, note-external and note-report.
SenderType definiert den Absendertyp des Artikel. Mögliche Werte sind: Agent, System, Customer.
'ContentType' definiert den Inhaltstyp des Artikels. Mögliche Werte: 'text/plain; charset=ISO-8859-15' or any other valid charset and mime type.
'Betreff' definiert den Artikeltitel. Verfplichtend.
'Body' definiert den Artikelinhalt. Verpflichtend
'HistoryType' definiert den Typ des Historien-Eintrages. Möglich Werte: AddNote, ArchiveFlagUpdate, Bounce, CustomerUpdate, EmailAgent, EmailCustomer, EscalationResponseTimeNotifyBefore, EscalationResponseTimeStart, EscalationResponseTimeStop, EscalationSolutionTimeNotifyBefore, EscalationSolutionTimeStart, EscalationSolutionTimeStop, EscalationUpdateTimeNotifyBefore, EscalationUpdateTimeStart, EscalationUpdateTimeStop, FollowUp, Forward, Lock, LoopProtection, Merged, Misc, Move, NewTicket, OwnerUpdate, PhoneCallAgent, PhoneCallCustomer, PriorityUpdate, Remove, ResponsibleUpdate, SendAgentNotification, SendAnswer, SendAutoFollowUp, SendAutoReject, SendAutoReply, SendCustomerNotification, ServiceUpdate, SetPendingTime, SLAUpdate, StateUpdate, Subscribe, SystemRequest, TicketDynamicFieldUpdate, TicketLinkAdd, TicketLinkDelete, TimeAccounting, TypeUpdate, Unlock, Unsubscribe, WebRequestCustomer.
'HistoryContent' definiert den Inhalt von Historieneinträgen.
'Von', 'An', 'Cc' und 'ReplyTo' nehmen E-Mailadressen in der oben angegebenen Schreibweise.
'InReplyTo' und 'References' nehmen E-Mailnachrichten-IDs
'NoAgentNotify' - Ist dieser Wert auf 1 gesetzt, werden keine E-Mailbenachrichtigungen an Agenten verschickt.
'AutoResponseType' kann die folgenden Werte annehmen: Auto FollowUp, Auto-Reject, Auto-Remove, Auto-Reply, Auto-Reply/New Ticket.
'ForceNotificationToUserID', 'ExcludeNotificationToUserID', 'ExcludeMuteNotificationToUserID' können eine Liste verschiedener User beinhalten, die entweder immer benachrichtigt, nie benachrichtigt oder als benachrichtigt aufgeführt werden, aber keine Benachrichtigungs-EMail erhalten.
'TimeUnit', ist die investierte Zeit in den aktuellen Ticketartikel die in Sekunden, Minuten, Stunden, etc. ausgedrückt wird.
'DynamicField_NameX' where DynamicField_ is a required prefix and NameX is the name of a Dynamic Field to be set in the new ticket (on ticket level, not article levels)
'LinkAs' to define the new ticket relation with originator ticket, from the new ticket point of view, for example Normal, Parent, Child etc.
Legt den Kunden für ein Prozessticket fest. Beispiel:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Customer Set Customer to test', Module => 'Kernel::System::Process::TransitionAction::TicketCustomerSet', Config => { No => 'test', User => 'client-user-123', # or in other words # CustomerID => 'client123', # CustomerUserID => 'client-user-123', }, }, };
'Name' definiert den Namen der konfigurierten Übergangsaktion.
No oder CustomerID setzt die Kundennummer des Kunden.
User oder CustomerUserID setzt den Benutzernamen des Kunden
Ändert die Sperre eines Prozessticket. Beispiel:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Set Lock to lock', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketLockSet', Config => { Lock => 'lock', # or LockID => 2, }, }, };
'Name' definiert den Namen der konfigurierten Übergangsaktion.
'Lock' definiert den neuen Sperrstatus des Prozesstickets.
'LockID' definiert die interne ID des neuen Sperrstatus.
Ändert den Besitzer eines Prozesstickets. Beispiel:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Owner Set root@localhost', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketOwnerSet', Config => { Owner => 'root@localhost', # or OwnerID => 1, }, }, };
'Name' definiert den Namen der konfigurierten Übergangsaktion.
'Owner' definiert den Loginnamen des neuen Beistzers.
'OwenerID' definiert die interne ID des neuen Besitzers.
Verschiebt das Ticket in eine Ziel-Queue. Beispiel:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Queue Move Raw', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet', Config => { Queue => 'Raw', # or # QueueID => '2', }, }, };
'Name' definiert den Namen der konfigurierten Übergangsaktion.
'Queue' definiert den Namen der Ziel-Queue.
'QueueID' definiert die interne ID der Ziel-Queue.
Ändert den Verantwortlichen eines Prozesstickets. Beispiel:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Responsible Set root@localhost', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketResponsibleSet', Config => { Responsible => 'root@localhost', # or ResponsibleID => 1, }, }, };
'Name' definiert den Namen der konfigurierten Übergangsaktion.
'Responsible' definiert den Loginnamen des neuen Verantwortlichen
'ResponsibleID' definiert die interne ID des neuen Verantwortlichen.
Ordnet einem Prozessticket einen Service zu. Das Ticket benötigt einen Kunden und der Service muss diesem Kunden zugeordnet sein. Beispiel:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Set MyService service', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketServiceSet', Config => { Service => 'MyService', # or ServiceID => 123, }, }, };
'Name' definiert den Namen der konfigurierten Übergangsaktion.
'Service' definiert den neuen Service des Prozesstickets. Es wird der vollständige Name des Service benötigt. (zum Beispiel: GramdFatherService::FatherService::SonService ).
'ServiceID' definiert die interne ID des neuen Services.
Ordnet eine Service-Level-Vereinbarung einem Prozessticket zu. Das Ticket muss einen Service haben und das SLA muss diesem Service zugeordnet sein. Beispiel:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Set MySLA SLA', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketSLASet', Config => { SLA => 'MyService', # or SLAID => 123, }, }, };
'Name' definiert den Namen der konfigurierten Übergangsaktion.
'SLA' definiert die neue Service-Level-Vereinbarung des Prozesstickets.
'SLAID' definiert die interne ID des neuen SLA.
Ändert den Status eines Prozesstickets. Beispiel:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Set State to open', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketStateSet', Config => { State => 'open', # or StateID => 4, PendingTimeDiff => 123, }, }, };
'Name' definiert den Namen der konfigurierten Übergangsaktion.
'State' definiert den neuen Status des Prozesstickets.
'StateID' definiert die interne ID des neuen Status.
'PendingTimeDiff' used only for pending type states, defines the time difference in seconds relative (relative to the Transition Action execution time) to set ticket pending time (e.g. 3600 means that the pending time is 1hr after the Transition Action is executed).
Setzt den Tickettitel eines Prozesstickets. Beispiel:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Set Ticket Title to Ticket-title', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketTitleSet', Config => { Title => 'Ticket-title', }, }, };
'Name' definiert den Namen der konfigurierten Übergangsaktion.
'Title' definiert den neuen Titel des Tickets.
Setzt den Tickettyp eines Prozesstickets. Beispiel:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Set Ticket Type to default', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketTypeSet', Config => { Type => 'default', # or # TypeID => '1', }, }, };
'Name' definiert den Namen der konfigurierten Übergangsaktion.
'Type' definiert den Namen des Tickettyps.
'TypeID' definiert die interne ID des Tickettyps.
Mit der Hilfe von ACLs, können Sie die auswählbaren Werte in Prozesstickets limitieren. Weitere Beschreibungen der ACL-Syntax finden Sie in der ACL-Referenz
ACLs können nur in der Kernel/Config.pm
definiert
werden. Beispiel:
$Self->{TicketAcl}->{'001-ACL-ProcessProperties'} = { Properties => { Process => { ProcessEntityID => ['P1'], ActivityEntityID => ['A1'], ActivityDialogEntityID => ['AD1'], } }, Possible => { ActivityDialog => ['AD1', 'AD3'], }, PossibleNot => { ActivityDialog => ['AD3'], }, };
Name der ACL-Regel. Für weitere Informationen über ACL-Regeln konsultieren Sie bitte das Kapitel über ACLs.
This is the section that is used to check if an ACL must be applied. If it has the specified values, the rule is applied. The following values can be used:
The ID of a process that the process. Matches if the ticket is assigned to this process.
Hier können Sie eine Liste von Aktivitätsdialogen-Nummern definieren. Diese Liste beschränkt die möglichen Aktivitätsdialoge die dem Agenten in der TicketZoom-Oberfläche angeboten werden.
'Möglich' listet die Aktivitätsdialoge auf, die erlaubt sind. Durch diese Einstellung wird nur 'AD1' und 'AD3' in der Liste der konfigurierten Aktivitätsdialoge angezeigt.
'Nicht Möglich' listet die Aktivitätsdialoge auf, die nicht erlaubt sind. Im oberen Beispiel wird diese Einstellung 'AD3' aus der Liste der konfigurierten Aktivitätsdialoge entfernen.
If both 'Possible' and 'PossibleNot' are specified, the list of configured Activity Dialogs will first be filtered by 'Possible', leaving only 'AD1' and 'AD3' in our example. Then 'PossibleNot' will be applied and filter out 'AD3', so that only 'AD1' remains and is shown as a possible Activity Dialog that the user can use.
Wenn mehrere ACL-Regeln übereinstimmen, wird der Durchschnitt aller passenden Regeln berechnet um die möglichen Aktivitätsdialoge zu bestimmen. Beispiel:
Konfigurierte Aktivitätsdialoge: 'AD1', 'AD2', 'AD3', 'AD4', 'AD5', 'AD6', 'AD7'.
$Self->{TicketAcl}->{'001-ACL-Status'} = { Properties => { Ticket => { Status => 'new', } }, Possible => { ActivityDialog => ['AD1', 'AD2', 'AD3', 'AD6', 'AD7'], }, }; $Self->{TicketAcl}->{'002-ACL-Queue'} = { Properties => { Ticket => { Queue => ['Raw'] } }, Possible => { ActivityDialog => ['AD2', 'AD3', 'AD4', 'AD7'], }, }; $Self->{TicketAcl}->{'003-ACL-Priority'} = { Properties => { Ticket => { Priority => ['3 normal'] } }, PossibleNot => { ActivityDialog => ['AD3', 'AD4'], }, };
Wenn ein Prozessticket den Zustand "Neu" hat, in der "Raw"-Queue ist und eine Priorität "3 normal" hat, dann werden alle drei ACL-Regeln angewendet werden.
Die erste Regel reduziert die Aktivitätsdialoge von 'AD1', 'AD2', 'AD3', 'AD4', 'AD5', 'AD6', 'AD7' to 'AD1', 'AD2', 'AD3', 'AD6', 'AD7' und verbietet 'AD4' and 'AD5'.
Die zweite Regel reduziert die verbleibende Aktivitätsdialoge weiter. In unserem Beispiel werden 'AD2', 'AD3', 'AD 7' bleiben.
Nun wird die dritte Regel die Liste durch 'PossibleNot' weiter reduzieren. 'AD3' wird von der Liste entfernt. 'AD4' wird nicht entfernt, da er in der Liste nicht an erster Stelle steht. Am Ende bleiben 'AD2' und 'AD 7' als mögliche Aktivitätsdialoge, die der Benutzer verwenden kann.
It is also possible to limit the processes that can be displayed in the "New process ticket" screen, the functionality is similar to limiting the ActivityDialogs with one exception: The ACLs could only be based on Users.
Siehe Beispiele:
$Self->{TicketAcl}->{'200-ACL-Process'} = { # match properties Properties => { User => { UserID => [2, 3], }, }, Possible => { Process => ['P1', 'P2', 'P3'], }, PossibleNot => { Process => ['P4'], }, };
$Self->{TicketAcl}->{'201-ACL-Process'} = { # match properties Properties => { User => { Group_rw => [ 'MyGroup' ], }, }, Possible => { Process => ['P1', 'P2', 'P3'], }, PossibleNot => { Process => ['P4'], }, };
$Self->{TicketAcl}->{'202-ACL-Process'} = { # match properties Properties => { User => { Role => [ 'MyRole' ], }, }, Possible => { Process => ['P1', 'P2', 'P3'], }, PossibleNot => { Process => ['P4'], }, };