Blog

02.02.2018 // Renée Bäcker

Im Otterhub-Forum, auf der Mailingliste und auch bei meinen Kunden tauchen immer wieder Fragen auf wie Wie kann ich denn den Abteilungsleiter informieren wenn x Tage nichts mehr am Ticket gemacht wurde oder Wie kann ich dem Kunden eine Nachricht schicken zwei Tage nachdem das Ticket geschlossen wurde. Mit einfacher Konfiguration ist das nicht lösbar, da das OTRS nicht hellsehen kann und es auch nicht für alles ein Event geben kann.

An dieser Stelle kommt dann aber das nützliche Trio ins Spiel. Mit dynamischen Feldern kann man alle möglichen Informationen am Ticket oder am einzelnen Artikel speichern. Standardmäßig gibt es ein paar Basistypen wie Textfeld, Dropdown, Checkbox und Datum. Aber auf OPAR gibt es noch weitere Typen (z.B. Agenten, JsonAPI, Integer, MultiCheckbox, ConfigItem, RemoteDB) und wir haben auch noch andere Erweiterungen im Angebot zur Erweiterung der Dynamischen Felder (z.B. Multipart, Icons, ChildTickets, Tags, ...).

Es macht auch nichts wenn man einige Dutzend Dynamische Felder erstellt hat. Wenn für ein Ticket/Artikel kein Wert existiert, gibt es da auch keinen Eintrag in der Datenbank. Und man muss ja auch nicht alle Dynamischen Felder in der Oberfläche anzeigen lassen.

Mit dem GenericAgent kann man wunderbar nach Tickets suchen und dann Informationen am Ticket speichern und/oder ändern. Man kann auch eigene Kommandos schreiben. Typische Aufgaben beim GenericAgent ist z.B. das Löschen von Spam-Mails, das Verschieben von Tickets, das Setzen einer neuen Priorität und so weiter.

Das dritte Puzzleteil in diesem Blogbeitrag sind die Ticketbenachrichtigungen. Seit OTRS5 ist das ziemlich mächtig, denn man kann auf Events reagieren, kann die Tickets noch genauer filtern und auch den Empfängerkreis kann man sehr genau bestimmen. Man kann E-Mails verschicken und in der Business Solution oder mit unserem Paket TicketSMSNotification können Sie auch SMS' verschicken.

Schauen wir uns die Fragestellungen nochmal genauer an: Der Abteilungsleiter soll eine Nachricht bekommen wenn das Ticket x Tage nicht mehr geändert wurde.

Der Abteilungsleiter soll jetzt eine bestimmte Person mit einer festen Mailadresse sein. Jetzt müssen wir überlegen wie wir die Benachrichtigung auslösen können. Benachrichtigungen werden durch Ereignisse/Events ausgelöst. Es gibt aber kein Event das ausgelöst wird wenn ein Ticket x Tage nicht geändert wurde. Also müssen wir dafür sorgen, dass es genau ein solches Event gibt. Dazu müssen wir die Tickets suchen, auf die das Suchkriterium zuletzt vor mehr als x Tagen geändert zutrifft. Wir wollen aber nicht selbst suchen, sondern das soll regelmäßig und automatisch gemacht werden.

Und was eignet sich für eine solche Aufgabe? Genau, der GenericAgent. Ein GenericAgent-Job kann auf zwei Arten ausgeführt werden: Eventbasiert, also wenn sich am Ticket etwas ändert, oder auf Basis eines Kalenders. Die Eventbasierte Ausführung hat den Vorteil, dass etwas unmittelbar nach einer Änderung am Ticket gemacht werden kann. Das ist in unserem Fall aber nicht die Lösung. Wir brauchen die automatische Ausführung. Damit die Ticketbenachrichtigung ausgelöst wird, brauchen wir ein Event. Ein Event wird bei einer Änderung am Ticket ausgelöst. Also müssen wir irgendwas am Ticket verändern.

Da es aber die Information Das Ticket wurde jetzt seit x Tagen nicht mehr geändert standardmäßig nicht gibt, müssen wir am Ticket Platz für diese Information schaffen. Also brauchen wir ein Dynamisches Feld.

Fangen wir also damit an.

Ich nehme für solche Informationen ganz gerne ein Textfeld, da ich da sehr frei bin was ich da reinschreibe. Da es eine Information ist, die nur einmal am Ticket vorkommen kann, nehe ich als Objekt Ticket

Dann müssen die Stammdaten ausgefüllt werden. Der Name ist wichtig, die Beschriftung nicht - da wir das Feld nirgends anzeigen möchten.

Als nächstes müssen wir das Feld füllen wenn ein Ticket die x (hier: 25) Tage nicht geändert wurde. Dazu im Adminbereich einen neuen GenericAgent anlegen:

Da das regelmäßig ausgeführt werden soll, wählen wir alle Zeitpunkte - außer Samstag und Sonntag.

Da das nicht bei allen Tickets gefüllt werden soll, müssen wir die Tickets filtern. Die Information ist ja nur bei solchen Tickets interessant, die noch offen sind und eben die 25 Tage nicht geändert wurden. Genau das müssen wir beim Ticketfilter eintragen:

Anschließend speichern wir die Information am Ticket. Wir ändern den Inhalt des eben erstellten Dynamischen Feldes auf 1.

Damit haben wir jetzt dafür gesorgt, dass ein Event gefeuert wird wenn ein Ticket 25 Tage nicht bearbeitet wurde. Jetzt müssen wir noch was mit dem Event anfangen. Nun kommen also die Ticketbenachrichtigungen ins Spiel. Diese werden durch Events ausgelöst. Unser Event wird durch die Änderung des einen Dynamischen Feldes ausgelöst. Also müssen wir genau darauf reagieren:

Auch hier interessieren uns nicht alle Tickets, sondern nur die, bei denen der neue Wert des Dynamischen Feldes 1 ist.

Anschließend bestimmen wir noch den Empfänger der Nachricht. Das kann auf Gruppen oder Rollen basieren, auf bestimmten Eigenschaften wie Schreibrechte auf die Queue oder Besitzer des Tickets. Man kann aber auch einfach eine Mailadresse eingeben:

Abschließend müssen wir noch einen Text für die Benachrichtigung festlegen.

Und das war's. Über das Zusammenspiel dieser drei Komponenten kann man ganz viele nützliche Sachen umsetzen. Wenn Sie noch weitere Fragen haben, schreiben Sie uns doch bitte eine Nachricht.

Dadurch dass wir ein Textfeld genommen haben, können wir auch noch mehrere Eskalationen einbauen. Ein weiterer GenericAgent könnte z.B. prüfen, ob das Ticket mehr als 50 Tage nicht angefasst wurde und dann das Dynamische Feld auf 2 setzen. Eine weitere Ticketbenachrichtigung für das gleiche Event aber nur die Tickets nimmt, bei denen der neue Wert 2 ist, könnte eine Nachricht an andere Personen schicken.

Permalink: /2018-02-02-dynamicfields-genericagent-ticketnotifications