In TicketTemplates gab es eine Lücke, dass Kunden auf alle Templates zugreifen konnten die für das Kundenportal aktiviert waren – unabhängig davon ob die Templates nur für bestimmte Gruppen erlaubt waren und die Kunden gar nicht zu der Gruppe gehörten. Es war nur notwendig, die ID des Templates zu kennen bzw. zu erraten.
In der Version 6.0.17 wurde dieses Problem behoben.
Unsere beiden Addons TicketChecklist und TicketTemplates helfen dabei, das Leben der Agent:innen zu vereinfachen. Letzteres um weniger Text bei der Erfassung von Tickets zu schreiben und einige Voreinstellungen wie Priorität, Queue etc. zu treffen und ersteres, damit man die ganzen Aufgaben im Zusammenhang mit einem Ticket im Überblick zu behalten.
In diesem Beitrag zeige ich, wie man beide Erweiterungen miteinander verknüpfen kann. Nehmen wir an, dass beim Onboarding von neuen Mitarbeitern in einem Tickettext ein Teil der Stammdaten erfasst werden, die für die Abarbeitung der Aufgaben notwendig sind.
Das Template könnte also wie folgt – oder so ähnlich – aussehen:
Und immer wenn das Ticket mit diesem Template erstellt wird, soll folgende Checkliste an das Ticket gehängt werden:
Eine direkte Verknüpfung zwischen den Modulen gibt es nicht. Aber eine indirekte Verknüpfung ist möglich: über den GenericAgent!
TicketTemplates setzt in der aktuellen Version das Dynamische Feld PSTicketTemplateID
auf die ID des Templates das genutzt wurde und ein GenericAgent kann auf Änderungen eines Dynamischen Feldes reagieren. In diesem GenericAgent-Job kann dann wiederum das GenericAgent-Modul genutzt werden, das TicketChecklist mitliefert.
Auf unserem Beispielsystem hat das Template die ID 18
(kann man herausbekommen, indem man mit der Maus in der Templateübersicht über den Namen des Templates fährt, oder in der URL wenn man die Vorlage bearbeitet):
Und die Checklistenvorlage die ID 1
.
Mit diesem Wissen ist es kein Problem mehr, den GenericAgent-Job einzurichten. Wir reagieren auf die Änderung des Dynamischen Feldes:
Und wir wollen nur die Checkliste anhängen, wenn das Ticket auf dem Template mit der ID 18
basiert. Dazu muss das passende Dynamische Feld als Filter ausgewählt werden:
Das ist also unser Ticket-Filter:
Das Anhängen der Checkliste funktioniert über das Custom-Modul Kernel::System::GenericAgent::AddChecklistToTicket
für den GenericAgent. Das bekommt noch die ID der Checklistenvorlage und die UserID 1 übergeben:
Das war's. Wenn wir jetzt ein Ticket erstellen, das Template auswählen und speichern, hängt die Checkliste an diesem Ticket.
Permalink: /2020-09-02-checklisten-und-templates
Seit der Version 5.0.4 von TicketTemplates gibt es die Möglichkeit, Ticket-Workflows zu erstellen. Ticket-Workflows bedeutet, dass es von einem Ticket ausgehend verschiedene Tasks geben kann, die auch von einander abhängen können. Stellen Sie sich vor, ein neuer Mitarbeiter möchte bei Ihnen im Unternehmen anfangen. Da fallen für ganz viele Abteilungen Arbeit an:
Aber die IT-Abteilung darf erst mit der Arbeit anfangen wenn der Vertrag da ist.
Diesen Ablauf können Sie mit TicketTemplates jetzt ganz einfach abbilden:
Legen Sie für alle Aufgaben jeweils eine Vorlage an. Darin können Sie bestimmen welcher Text das Ticket haben soll, welche Priorität, zu welcher Queue das Ticket gehören soll und noch vieles mehr.
In diesem Beispiel haben wir mal drei Vorlagen erstellt:
Als nächstes wird mit diesen Vorlagen der Workflow abgebildet. Im Adminbereich gibt es hierzu den Punkt Ticket-Templates-Workflows
Zu jedem Workflow wird der Name, ein Kommentar und die Gültigkeit eingetragen. Damit es für die Agenten bei vielen Workflows nicht zu unübersichtlich wird, kann die Sichtbarkeit eingeschränkt werden indem man dem Workflow Gruppen zuweist.
Als nächstes müssen Aufgaben/Tasks hinzugefügt werden. Jede Aufgabe bekommt einen Namen und muss ein Template zugewiesen bekommen. Die Angaben aus dem Template werden dazu genutzt das Ticket für die Aufgabe zu erstellen.
Weiterhin können die Abhängigkeiten festgelegt werden. In unserem Beispiel muss die Personalabteilung erst den Vertrag bekommen haben, bevor die IT tätig wird und das E-Mail-Konto sowie die Berechtigungen einrichtet. Genau das bilden die Abhängigkeiten ab. Das Aufgabe für die IT hängt von der Aufgabe für die Personalabteilung ab. Genau das ist hier eingetragen:
Für alle Aufgaben die von anderen Aufgaben abhängig sind, werden Tickets in einem speziellen Status angelegt. Wird dann das Ticket (z.B. das der Personalabteilung) geschlossen, werden alle abhängigen Aufgaben (Tickets für IT und Sonstiges) auf offen
gesetzt. Damit tauchen diese Tickets dann auch in den Übersichten der Agenten auf.
Als nächstes kann noch bestimmt werden, welche Inhalte von dynamischen Feldern aus dem Originalticket
übernommen werden. So kann man im Originalticket ein Dynamisches Feld für die benötigten Berechtigungen ausfüllen und das wird dann automatisch in das Ticket für die IT übernommen.
Ein Workflow kann von einem beliebigen Ticket aus gestartet werden. Im Ticketmenü befindet sich ein Dropdown, in dem alle verfügbaren Workflows aufgelistet sind. Bei Auswahl des passenden Workflows werden die Tickets gemäß den Aufgaben erstellt.
Zur besseren Auffindbarkeit wird jedes Ticket mit dem Ausgangsticket normal
verknüpft.
Weiterhin werden die Aufgaben ohne Abhängigkeiten direkt mit dem Ticket als WorkflowTask
verknüpft.
Die Aufgaben mit Abhängigkeiten werden jeweils mit dem Ticket der Abhängigkeit als WorkflowTask
verknüpft. So kann man immer im Workflow durchnavigieren und bekommt einen Überblick welche Aufgaben noch ausstehen.
Was ist der Nachteil gegenüber dem Prozessmanagement? Im Prozessmanagement ist man wesentlich flexibler. Es ist nicht vorgegeben welcher Status die Sub-Tickets haben. Außerdem kann man beim Prozessmanagement mit einigen Platzhaltern wie z.B. <OTRS_TICKET_Title>
arbeiten.
Was ist der Vorteil gegenüber dem Prozessmanagement? Templates können wiederverwendet werden - sie können sowohl als Vorlagen für Telefon- oder Emailtickets als auch für Tickets im Workflow benutzt werden. Die Konfiguration ist wesentlich einfacher: Für die Vorlagen gibt es eine eigene Administrationsoberfläche bei der man sich nicht nicht - wie im Prozessmanagement - merken muss wie die Parameter für z.B. den Betreff oder den Ticket-Text.
Über die Abhängigkeiten kann man bei den Workflows sehr einfach festlegen. Durch den eigenen Ticketstatus und das automatische öffnen der Tickets wenn Abhängigkeiten geschlossen werden, mussman sich keine Gedanken darüber machen wann welches Ticket sichtbar werden soll.
Haben wir Ihr Interesse an TicketTemplates geweckt? Dann nehmen Sie doch einfach Kontakt zu uns auf oder fordern Sie gleich Ihr Demosystem an.
Ausblick:
Unsere Erweiterungen werden ständig weiterentwickelt, so auch TicketTemplates. Als nächstes soll es die Möglichkeit geben Templates und Workflows zu exportieren und importieren. Damit soll ees leichter werden, Templates und Workflows von einem Testsystem auf das Produktivsystem zu übertragen. Außerdem soll ein Transaction-Modul für das Prozessmanagement entwickelt werden, dass es ermöglicht Tickets auf Basis von Templates zu erstellen und auch das Starten von Workflows soll ermöglicht werden.
Haben Sie noch weitere Ideen und Wünsche? Dann schreiben Sie uns bitte.
Permalink: /2016-11-19-tickettemplates-workflow