TicketChecklisten im Prozessmanagement
Unsere Erweiterung TicketChecklist kann auch im Prozessmanagement eingebunden werden. Wie das funktioniert zeigt dieser Beitrag. Als Beispiel soll ein Prozess gestartet werden wenn eine neue Mitarbeiterin eingestellt werden soll. In einer Checkliste am Ticket sollen einige Dinge vermerkt sein, die so erledigt werden müssen:
Ein einfacher Prozess – der für den Beitrag stark verkürzt ist – könnte so aussehen, dass zu Beginn einfach ein Name eingetragen werden soll. Und ist das der Fall, steht als nächste Aktivität einfach nur die Erfassung an, dass der Vertrag da (und unterschrieben) ist. Ist das der Fall, geht der Prozess zu einer Aktivität ohne Dialog etc. (Prozessende).
Wenn der Prozess gestartet wird, also beim Übergang Daten eingegeben, soll die Checklistenvorlage zum Ticket hinzugefügt werden. Dazu muss eine neue Übergangsaktion erstellt werden. Dort muss das Aktionsmodul AddChecklist ausgewählt werden. Bei den Parametern wird nur der Schlüssel TemplateID benötigt und als Wert die ID der Vorlage.
Die TemplateID bekommt man, wenn man bei der Verwaltung der Checklistenvorlagen die Vorlage bearbeitet und in der URL nach dem Parameter ID schaut.
Zu Beginn ist nur die Aufgabe sign contract offen, die restlichen Aufgaben stehen auf warten. Das soll geändert werden, sobald der Vertrag unterschrieben ist. Dass der Vertrag unterschrieben ist, wird in der Aktivität Erfassung Vertrag und dem dazugehörigen Aktivitätsdialog erfasst.
Wenn der Vertrag unterschrieben ist, geht das Ticket im Prozess auch ein Stück weiter (hier: zu Prozessende). Das heißt, dass es einen Übergang gibt, den wir auch nutzen können um die erste Aufgabe zu schließen und andere Aufgaben zu öffnen. Dazu nutzen wir wieder Übergangsaktionen:
Als Aktionsmodul wird ChangeChecklistItems ausgewählt. Bei den Parametern muss immer festgelegt werden, welche Aufgaben (Items) geändert werden sollen. Das passiert über den Schlüssel Item_#. Die Reihenfolge in der die Aufgaben nummeriert werden ist meistens egal (außer man nutzt die Bedingungen und Aktionen der Checklistenvorlagen).
Als Wert zu Item_# muss der Text der Aufgabe wie in der Vorlage genutzt eingetragen werden. Darüber werden die Aufgaben identifiziert.
Mit der gleichen Nummer können die Änderungen an der Aufgabe definiert werden. In diesem Beispiel nutzen wir nur den Schlüssel Status_#, um den Status zu ändern. Schlüssel mit gleichem Wert für #
gehören zusammen, also Item_1 und Status_1 etc.
Neben Stauts_# können noch folgende Schlüssel verwendet werden:
- Responsible_# um den Aufgabenverantwortlichen zu ändern
- DueDate_# um das Fälligkeitsdatum zu ändern und
- Priority_# um die Priorität zu ändern.
Permalink: /2022-01-11-ticketchecklisten-im-prozessmanagement
TicketChecklist – Startdatum für Aufgaben
Neben den vielen kleinen Neuerungen, gibt es auch eine etwas größere. Wer sich die Screenshots aus dem letzten Blogartikel genauer angeschaut hat, hat es vielleicht schon gesehen: Es gibt jetzt auch ein Startdatum
für Aufgaben und nicht nur ein Fälligkeitsdatum.
Um dieses neue Feature nutzen zu können, muss es in der Systemkonfiguration mittels der Einstellung TicketChecklist::Feature::DateStart aktiviert werden.
Ab der Aktivierung taucht das neue Feld an den verschiedenen Stellen auf. Es kann über die Ticketansicht und dem Menüpunkt Checkliste auch bei bereits existierenden Aufgaben gesetzt werden:
Auch bei den Details in der Ticketansicht ist das Startdatum zu sehen:
Und im Dashboardwidget mit den Checklistenaufgaben taucht das Datum auch auf und man kann danach sortieren. Somit können die Agenten sich anschauen, welche Aufgaben als nächstes anstehen.
Das Startdatum hat einen weiteren Vorteil: Man kann die Aufgabe erstmal in einen Warten
-Status setzen (welche das genau sind, kann über die Systemkonfiguration eingestellt werden). Der Daemon prüft regelmäßig, ob bei einer Aufgabe in einem Warten
-Status mit Startdatum dieses Datum erreicht ist. Ist das der Fall, wird die Aufgabe automatisch in einen anderen Status versetzt (auch der ist konfigurierbar).
Der Aufgabenverantwortliche wird auch bei einem bevorstehenden Start der Aufgabe informiert.
Somit ist das Startdatum
ein weiteres Puzzleteil für einen kompletten Workflow mit der TicketChecklist.
Permalink: /2021-09-03-ticketchecklist-a-startdatum-fuer-aufgaben
TicketChecklist - Neuerungen
Wir müssen uns mal wieder bei unseren Kunden bedanken, die uns immer wieder wertvolles Feedback zu unseren Addons geben. Diesmal haben wir wieder von ein paar Neuerungen in TicketChecklist zu berichten.
Standardmäßige Sichtbarkeit von Checklisten im Kundenportal
Sollen die Checklisten von Tickets in bestimmten Queues standardmäßig im Kundenportal sichtbar sein, muss die Systemkonfigurations-Einstellung Queues::CustomerVisibility aktiviert werden. Als Schlüssel muss der (komplette) Queuename eingetragen werden und bei Wert eine 1.
Namen der Verantwortlichen statt nur deren Login
Für eine Aufgabe kann eine Verantwortliche Person definiert werden. Bisher wurde immer der Login des Agenten angezeigt.
Wird die Einstellung TicketChecklist::Widget::ShowResponsibleFullname akvitiert, wird stattdessen der volle Name der Person angezeigt:
Oder
-Verknüpfung bei Status in den Conditions and Actions
Über die Bedinungen und Aktionen
in Checklisten-Vorlagen können Aktionen bei Änderung des Status einer Aufgabe ausgelöst werden. Bisher war es nur möglich zu sagen, wenn die Aufgabe den Status 'erledigt' bekommt, setze andere Aufgaben in den Status 'offen'
. Möchte man ein und dieselbe Aktion bei mehreren Statusänderungen machen, musste man bisher mehrere Bedingungen anlegen:
Nach der Aktivierung der Einstellung TicketChecklist::Condition::MultiState kann man einfach mehrere Status auswählen:
Möglichkeit, als Agent Benachrichtigungen abzubestellen
Die Checklisten verschicken unter Umständen einige Benachrichtigungen, z.B. wenn sich der Status ändert, das Fälligkeitsdatum bald erreicht ist oder noch vieles mehr. Mit der neuesten Version ist es jetzt möglich, als Agent diese Benachrichtigungen abzubestellen.
In den Persönlichen Einstellungen im Bereich Benachrichtigungseinstellungen können die Benachrichtigungen aktiviert und deaktiviert werden:
Deaktivieren von Benachrichtigungen für Queues
Für manche Queues sollen vielleicht gar keine Benachrichtigungen geschickt werden, weil dort vielleicht Tickets einfach gelöscht werden oder es eine Queue zum Testen von neuen Einstellungen ist. Für solche Queues können die Benachrichtigungen über die Systemkonfiguration deaktiviert werden.
In der Einstellung TicketChecklist::NotificationQueueExclude muss der komplette Name der Queue (z.B. Oberqueue::Unterqueue1::Unterqueue2) angegeben werden.
Permalink: /2021-09-02-ticketchecklist-neuerungen
Neuerungen in TicketChecklist
Gibt es Aufgaben an einem Ticket, können diese in der neuesten 6.0.x-Version per Mail geändert werden. Ein Beispiel: Am Ticket gibt es die Aufgabe Büro einrichten
Sollen Aufgaben per Mail geändert werden, wird ein Postmaster-Filter benötigt. Mit Postmaster-Filtern können eingehende Mails mit Regulären Ausdrücken überprüft werden und über erweiterte Mailheader können Tickets geändert werden.
TicketChecklist trägt in der SysConfig-Option PostmasterX-Header einige zusätzliche Mailheader ein, die für diesen Zweck genutzt werden können.
Postmaster-Filter sind mächtig und man kann viele Dinge relativ einfach automatisieren. Ein Problem mit Postmaster-Filtern ist aber, dass man sich mit den Personen die die Mails schreiben, auf ein Format des Inhalts einigen muss.
In diesem Fall legen wir fest, dass in der Mail der feste Wert *Todo schließen: *stehen muss und der Name der zu ändernden Aufgabe folgt, also:
Damit sieht der Beispiel-Postmaster-Filter im Suchteil wie folgt aus:
Hier wird also der Mailheader Subject mit dem Regulären Ausdruck Todo schließen: (.\*) geprüft. Je nach Vereinbarung kann der Reguläre Ausdruck auch anders aussehen und/oder es können wietere Mailheader geprüft werden.
Durch die runden Klammern im Regulären Ausdruck wird alles nach dem Schlüsselterm gespeichert
und steht zur weiteren Verwendung im Postmaster-Filter zur Verfügung. In dem Beispiel-Betreff wäre das dann Büro einrichten.
Diesen gespeicherten Wert werden wir auch noch Nutzen. Der beschreibt nämlich den Titel der Aufgabe, die geändert werden soll. Was geändert werden soll, legen wir im Bereich Email-Header setzen fest:
Mit \[\*\*\*\] greifen wir auf den gespeicherten Wert zu. Das heißt, dass in dem Beispiel der Mailheader X-OTRS-TicketChecklistItem-1 auf Büro einrichten gesetzt wird, und X-OTRS-TicketChecklistItem-1-Status auf done.
Ein Modul der Erweiterung sorgt dann dafür, dass die Aufgabe angepasst wird. Zum Testen erstellen wir eine Datei (z.B. MailChecklist.eml), in die der Mailinhalt geschrieben wird:
To: ticketchecklist@feature-addons.de
From: checklist@feature-addons.de
Subject: =?UTF-8?Q?[Ticket#2020112440000018] Todo_schlie=c3=9fen=3a_B=c3=bcro_einrichten?=
Date: 2020-11-24 16:02:30+0200
Das ist ein Test
Das ist also eine Mail für das oben gezeigte Ticket. Der Betreff sieht hier zwar komisch aus, ist so aber richtig. Wenn man nicht weiß, wie die eigenen gewünschten Mails aussehen, kann an das OTRS eine Mail schicken. Wenn die SysConfig-Option Ticket::Frontend::PlainView aktiviert ist, steht in der Ticketansicht ein Link Unformatierte Ansicht zur Verfügung. Dort sieht man dann alle Mailheader.
Über das Skript otrs.Console.pl kann diese Mail jetzt eingespielt werden:
perl bin/otrs.Console.pl Maint::PostMaster::Read < MailChecklist.eml
Wenn das durchgelaufen ist, sollte die Aufgabe geschlossen sein:
Permalink: /2020-11-24-neuerungen-ticketchecklist
Checklisten und Templates nutzen
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
Neues zu TicketChecklist (August 2020)
In letzter Zeit hat sich bei unserem Addon TicketChecklist einiges getan. Neben kleineren Bugfixes gibt es auch wieder neue Features, die ich gerne an dieser Stelle vorstellen möchte. Die neuen Features sind:
- Sichtbarkeit von Checklisten im Kundenportal
- Checklisten-Status in Abhängigkeit der Queue
- Statistik über Checklisten-Status
Sichtbarkeit von Checklisten im Kundenportal
Bei diesem Feature geht es darum, dass man Kunden/Kundinnen den aktuellen Stand der Bearbeitung mitteilen möchte. Ein Kunde schickt vielleicht ein Gerät zur Reparatur und über die Checkliste werden die einzelnen Schritte bestimmt.
Der Agent/die Agentin kann z.B. über eine Vorlage eine Checkliste erstellen und dann für jede Checkliste individuell bestimmen, ob diese Checkliste für den Kunden sichtbar sein soll:
Meldet sich der Kunde/die Kundin am Kundenportal an und öffnet das Ticket, sieht er/sie sofort den aktuellen Stand der Checkliste:
Dieses Feature muss über die Systemkonfiguration im Parameter TicketChecklist::Feature::CustomerVisibility aktiviert werden.
Checklisten-Status in Abhängigkeit der Queue
Benutzen viele Abteilungen das OTRS und es gibt viele Checklisten für die unterschiedlichsten Zwecke, ist es nicht so selten, dass viele Checklisten-Status eingerichtet werden müssen.
Damit die Auswahlbox beim Erstellen der Checkliste und im Checklisten-Widget in der Ticketansicht nicht zu lang wird, können die Checklisten-Status Queues zugeordnet werden. Wird keine Queue angegeben, ist der Status in allen Queues verfügbar.
Statistik über Checklisten-Status
Wie viele offenen Punkte haben wir denn in unseren Checklisten pro Queue? Diese Frage kann jetzt in einer Statistik beantwortet werden. Dafür wurde das Modul TicketAccumulationChecklistState geschrieben. Bei der Erstellung einer Statistik können Sie einfach eine Statistik vom Typ Dynamische Matrix
wählen und dann das genannte Modul bei Objekttyp auswählen.
Der Rest funktioniert dann genauso wie bei anderen Statistiken des gleichen Typs. Nur, dass Sie jetzt auch Checklisten-Status auswählen können, hier z.B. für die x-Achse:
Die daraus resultierende PDF-Datei sieht dann z.B. so aus:
Permalink: /2020-08-10-ticketchecklist
Neue Features in TicketChecklist
Es ist schon eine Zeitlang her seit unserem letzten Blogpost über Features in dem Addon. In der Zwischenzeitt haben wir wieder einiges an TicketChecklist geändert. Hier ein Überblick:
- Verwendung von Ticketnummer statt Ticket ID möglich
- Verknüpfung von Aufgaben mit Tickets
- Unterschiedliche Themes
- Anzeige versteckter Aufgaben
- Warnung bei Versuch einen Status zu löschen, der noch verwendet wird.
- Drag'n'Drop bei Aktionen (Vorlagen)
- Neues Aktionsmodul (Vorlagen)
- Dynamische Werte für Aktionen (Vorlagen)
Der erste Schwung an Änderungen betrifft die Bedingungen und Aktionen
.
Drag'n'Drop bei Aktionen (Vorlagen)
Die Reihenfolge von Aktionen lässt sich per Drag'n'Drop verschieben. Damit kann man die Reihenfolge der Abarbeitung beeinflussen.
Neues Aktionsmodul (Vorlagen)
Bisher konnte man nur eine Aufgabe verändern oder ein Dynamisches Feld am Ticket setzen. Jetzt gibt es ein neues Aktionsmodul, mit dem sich verschiedene Eigenschaften des Tickets verändern lassen (z.B. Queue, Besitzer, Status, Priorität, ...).
Dynamische Werte für Aktionen (Vorlagen)
Bisher war es nur möglich feste Werte bei dynamischen Feldern zu setzen. Neben dem neuen Aktionsmodul können die Inhalte auch dynamisch sein. Es gibt folgende Platzhaltergruppen:
- <OTRS_TICKET_...> - Informationen zum Ticket, zu dem die Aufgabe gehört
- <OTRS_CHECKLISTITEM_...> - Informationen zu der Aufgabe selbst
- <OTRS_CURRENT_...> - Infos zum Agenten der die Aktion anstößt
Verwendung von Ticketnummer statt Ticket ID
Bei einige OTRS-Installationen wird in Links die Ticketnummer statt der Ticket ID verwendet, so dass die Links z.B. http://test.example/otrs/index.pl?Action=AgentTicketZoom&TicketNumber=20181115123 sind. Das führte bisher dazu, dass die Checkliste nicht in der Ticketansicht angezeigt wurde. Das ist jetzt gefixt.
Anzeige versteckter Aufgaben
Gerade bei längeren Checklisten, kann es nützlich sein, dass man Aufgaben verstecken kann. Es gibt die SysConfig-Einstellung
TicketChecklist::HiddenStates, über die man das erreichen kann. Einfach die Checklisten-Status eintragen, die im Widget in
der Ticketansicht mehr auftauchen sollen.
Bisher konnten Agenten die Aufgaben aber nur sehen wenn sie den Checklistendialog geöffnet haben. Jetzt gibt es einen Link
über den man auch die versteckten Aufgaben anzeigen kann:
Warnung bei Versuch einen Status zu löschen, der noch verwendet wird.
Wird ein Status noch verwendet und ein Admin versucht den Status zu löschen passiert nichts. Für den Admin ist aber auch nicht ersichtlich, warum man keine Änderungen sieht. Aus diesem Grund wurde ein Hinweis eingefügt, der in so einem Fall erscheint:
Verknüpfung von Aufgaben mit Tickets
Man kann Tickets zwar über das normale Verknüpfen miteinander verbinden. Es gibt aber auch die Möglichkeit, Tickets über die Aufgaben miteinander zu verbinden. Damit kann man für größere Aufgaben ein Hauptticket erstellen mit einer Checkliste, bei der jede Aufgabe mit einem anderen Ticket verknüpft ist.
Dieses Verhalten muss man in der SysConfig über die Option TicketChecklist::AllowTicketsAsItems aktiviert werden.
Im Checklistendialog kann man dann einfach die Nummer des zu verknüpfenden Tickets eingeben:
Beim Speichern der Checkliste werden folgende Informationen aus dem Ticket an der Aufgabe gespeichert:
- Besitzer des Ticket → Verantwortlicher der Aufgabe
- Priorität des Tickets → Priorität der Aufgabe
- Titel des Tickets → Kommentar der Aufgabe
Ist die Option TicketChecklist::LinkTickets aktiv, werden die beiden Tickets auch verknüpft.
Wird jetzt der Status der Aufgabe geändert, überträgt sich das auf das Ticket - und umgekehrt.
Unterschiedliche Themes
Seit der ersten Version des Addons hat sich auch im Checklisten-Dialog einiges getan. Einige zusätzliche Infos die man an einer Aufgabe speichern kann, sind dazugekommen. Damit wurde ein untergeordnetes Panel eingerichtet, über das die Informationen gepflegt werden können.
Mittlerweile gibt es ein Theme Slim
, das in der Option TicketChecklist::Theme eingestellt werden kann. Damit
werden einige Informationen wieder - wie es früher einmal war - aus dem untergeordneten Panel in die Übersicht
gepackt:
Haben wir Ihr Interesse an TicketChecklist geweckt? Dann nehmen Sie doch einfach Kontakt zu uns auf oder fordern Sie gleich Ihr Demosystem an.
Permalink: /2018-11-18-checklist-neue-features
OTRS6: Checkliste positionieren
In OTRS 6 wurde die Ticketansicht komplett überarbeitet. Für das Checklisten-Modul muss nun kein schwerfälliger Ausgabefilter mehr verwendet werden, vielmehr werden die zusätzlichen Widgets (wie auch die Kundeninformationen) über Plugins realisiert. Diese haben den Vorteil, dass sie auch asynchron nachgeladen werden können - was einen nicht unerheblichen Geschwindigkeitsvorteil z.B. bei dem Attachment-Modul bringt.
Ein kleiner Nachteil ist, dass man nicht mehr ganz so flexibel bei der Positionierung ist. In OTRS5 gab es bei dem Checklisten-Modul noch die Config-Option TicketChecklist::Position mit der die komplexe Ansicht direkt unter dem Artikelbaum angezeigt werden konnte.
Unter OTRS6 muss man in der SysConfig eine kleine Anpassung machen:
In der Option Ticket::Frontend::AgentTicketZoom###Widgets###002-TicketChecklist muss der Wert von Location auf Main gestellt werden. Das sorgt dafür, dass die Checkliste in dem großen Hauptbereich angezeigt wird.
Weiterhin muss über das +
ein neuer Eintrag hinzugefügt werden. Als Schlüssel wird Top eingetragen und als Wert 1
. Das weist das Addon an, die Checkliste unter den Artikelbaum zu verschieben.
So sieht die Option dann aus:
Permalink: /2018-02-19-otrs6-checkliste-positionieren
TicketChecklisten per GenericAgent erstellen
Hat man seine Checklisten als Vorlagen vorbereitet, kann man diese mit dem GenericAgent an Tickets hängen. Das kann man in den unterschiedlichsten Situationen nutzen: Eine Checkliste für Rechenzentrumsrundgänge? Dann einfach die Checkliste an das Ticket hängen wenn es in der Queue RZ::Rundgang erstellt wird. Eine Checkliste die abgearbeitet werden muss wenn ein neuer Mitarbeiter anfängt? Dann die Checkliste an das Ticket hängen wenn es in der Queue HR::Inbound erstellt wird.
Aber nicht nur an Hand der Queue kann man eine Checkliste an ein Ticket hängen. Man kann alle Möglichkeiten des GenericAgent nutzen. So könnte man eine Checklisten-Vorlage erstellen, die bei bestimmten Services gelten soll:
Als nächstes muss der GenericAgent eingerichtet werden. Als auslösendes Ereignis nehmen wir TicketCreate und TicketServiceUpdate. Damit erfassen
wir alle Fälle in denen der Service eines Tickets gesetzt wird.
Natürlich wollen wir die Checkliste nicht bei allen Tickets, die irgendeinen Service haben, sondern nur bei einem bestimmten Service. Im Ticketfilter wählen wir genau diesen Service aus.
Zum Schluss noch das Wichtigste: Die Checkliste erstellen. Dazu muss ein benutzerdefiniertes Kommando ausgeführt werden und TicketChecklist liefert dieses Kommando mit: Kernel::System::GenericAgent::AddChecklistToTicket . Als Parameter erwartet das Kommando zum Einen die UserID des Benutzers - der Einfachheit halber wird hier immer die UserID 1 genommen. Und zum Anderen wird die ID der Checklisten-Vorlage benötigt. Diese bekommt man in der Übersicht der Checklisten-Vorlagen: Einfach mit der Maus über den Link fahren und die ID raussuchen.
Haben wir Ihr Interesse an TicketChecklist geweckt? Dann nehmen Sie doch einfach Kontakt zu uns auf oder fordern Sie gleich Ihr Demosystem an.
Haben Sie noch weitere Ideen und Wünsche? Dann schreiben Sie uns bitte
Permalink: /2017-07-08-ticketchecklist-genericagent
TicketChecklist: Schließen des Tickets verhindern
Eine häufiger gestellte Frage ist, wie man verhindern kann dass ein Agent ein Ticket schließt solange noch mindestens eine Aufgabe aus der Checkliste noch offen ist. Hier kann man sich die Ticket-ACLs zu Nutze machen. Immer wenn eine Aufgabe zur Checkliste hinzugefügt wird oder der Status einer bestehenden Aufgabe geändert wird, wird geprüft ob alle Punkte schon abgearbeitet sind oder nicht. Ist das nicht der Fall, wird das Dynamische Feld TicketHasOpenTodos auf den Wert 1 gesetzt.
Auf diesen Wert kann man in der ACL prüfen. Die Prüfung lautet: ist der Wert des Dynamischen TicketHasOpenTodos gleich 1, dann darf das Ticket nicht geschlossen werden. In der ACL sieht das dann wie folgt aus:
Bei den Wertänderungen muss man ausschließen, dass der Agent den Schließen
-Dialog aufruft und die geschlossen
-Status sollen in allen anderen Dialogen ausgeschlossen werden:
Wie erkennt TicketChecklist bei eigenen Aufgaben-Status, ob die Aufgaben geschlossen sind oder nicht? Dazu gibt es eine SysConfig-Option die gepflegt werden muss:
Wenn keine Aufgabe einen dieser Status hat, sind alle Aufgaben geschlossen.
Nach dem Speichern der ACL das Deployen
nicht vergessen. Sonst ist die ACL nicht aktiv. Und nicht mit dem Superuser (root@localhost) testen, denn da greifen keine ACLs.
Haben wir Ihr Interesse an TicketChecklist geweckt? Dann nehmen Sie doch einfach Kontakt zu uns auf oder fordern Sie gleich Ihr Demosystem an.
Haben Sie noch weitere Ideen und Wünsche? Dann schreiben Sie uns bitte.
Permalink: /2017-04-20-ticketchecklist-schliessen-verhindern
Conditions and Actions für TicketChecklist - und noch mehr
Auf Anregung eines Kunden haben wir TicketChecklist um Conditions and Actions
erweitert. Damit ist es möglich, auf Änderungen des Status von Aufgaben zu reagieren. Nehmen wir mal als Beispiel die Organisation der Firmen-Weihnachtsfeier, bei der sich folgende Checkliste mit diesen Aufgaben ergibt:
- Suche eines Veranstaltungsortes
- Unterschreiben des Vertrags
- Catering buchen
- Weihnachtsgeschenke besorgen
- Rechnungen bezahlen
Die Aufgabe Weihnachtsgeschenke besorgen
kann völlig unabhängig von den anderen Aufgaben erledigt werden. Aber der Vertrag kann erst unterschrieben werden, wenn ein Veranstaltungsort feststeht. Und das Catering wird erst bestellt, wenn der Vertrag unterschrieben ist da dort eventuell festgehalten ist, dass der Betreiber des Veranstaltungsortes selbst das Catering macht.
Wenn der Veranstaltungsort ausgewählt ist, wird die Aufgabe Unterschreiben des Vertrags
auf warten
gesetzt. Das gleiche gilt für Catering buchen
wenn der Vertrag unterschrieben ist. Aus Anschauungszwecken soll die Rechnungen erst bezahlt werden wenn das Catering gebucht ist. Da das von der Buchhaltung erledigt wird, soll das Ticket dann in die Queue Buchhaltung geschoben werden.
Daraus ergibt sich folgende Übersicht der Aufgaben:
Als erstes werden die Aufgaben mit ihren Verantwortlichen erstellt:
Danach werden die Conditions und Actions gepflegt. Zuerst definieren wir die Statusänderungen anderer Aufgaben:
Hier wird immer nur eine andere Aufgabe geändert. Es ist aber auch möglich mehrere Aufgaben zu ändern:
Neben dem Verändern anderer Aufgaben ist es bei den Actions auch möglich ein Dynamisches Feld am Ticket zu setzen. Dazu muss das Action-Modul TicketDynamicFieldSet verwendet werden:
Das nutzen wir in diesem Beispiel, um das Verschieben des Tickets in die Queue Buchhaltung
zu ermöglichen. Bei den Parametern muss der Name des Dynamischen Feldes (hier: MoveToQueue) als Schlüssel eingetragen werden und bei Wert der neue Wert des Feldes.
An dieser Stelle wäre es auch denkbar eigene Action-Module zu programmieren, so dass z.B. ein Status jetzt ausführen
erstellt wird und dass beim Erreichen des Status automatisch ein Programm aufgerufen wird, das ein Programm ausführt oder zusätzliche Informationen aus einem Drittsystem holt.
Auf Basis der Änderung eines Dynamischen Feldes kann man mit GenericAgents das Ticket dann in eine andere Queue verschieben:
Als Filter wird der neue Wert des Dynamischen Feldes genommen
und anschließend das Ticket verschoben
Mit diesen Conditions und Actions kann man mit TicketChecklist sehr viel erreichen weil man auch Einfluss auf das Ticket selbst nehmen kann.
Weitere Änderungen an TicketChecklist:
- Vorlagen können kopiert werden. Damit ist es jetzt möglich noch schneller ähnliche Vorlagen zu erstellen.
- Import/Export von Vorlagen, so dass es leicht ist Test- und Livesystem synchron zu halten
- Export von Aufgaben. In der Ticketansicht und im Dashboard können die Aufgaben als PDF, Excel-Datei und als ics-Datei exportiert werden.
Haben wir Ihr Interesse an TicketChecklist geweckt? Dann nehmen Sie doch einfach Kontakt zu uns auf oder fordern Sie gleich Ihr Demosystem an.
Ausblick:
Auch vor TicketChecklist machen ständige Veränderungen nicht Halt. Als nächstes soll die Anzeige der Aufgaben im Ticket-Kalender ermöglicht werden (im Zusammenspiel mit der Erweiterung AdvancedTicketCalendar. Weiterhin soll es ermöglicht werden, Kundenspezifische Checklistenvorlagen zu erstellen.
Haben Sie noch weitere Ideen und Wünsche? Dann schreiben Sie uns bitte.