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:
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:
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.
Mit OTRS5s hat die OTRS AG auch einen JIRA-Connector veröffentlicht. Schon seit einigen Jahren bietet die catWorkX GmbH ein JIRAPackage an. Das Gesamtpaket von catWorkX besteht aus einem JIRA-Addon und einen OTRS-Addon. Ich kenne den JIRA-Connector der OTRS AG nur aus den Ankündigungen und dem Blogpost, möchte hier an dieser Stelle aber trotzdem auf beide Pakete eingehen.
Der JIRA-Connector setzt auf das GenericInterface von OTRS auf. Man benötigt zwei Erweiterungen, die es nur für Kunden der Business-Lösung gibt. Sind die Abhängigkeiten installiert, muss der Webservice eingerichtet werden. Anschließend müssen noch Mappings konfiguriert werden. Der oben verlinkte Blogpost beschreibt die notwendigen Schritte ausführlicher.
Durch Trigger - wie Änderung des Ticketstatus, Neues Ticket oder neuer Artikel - wird die Kommunikation mit JIRA ausgelöst und die Informationen werden von OTRS an JIRA übertragen.
Das JIRAPackage implementiert die Kommunikation mit JIRA in eigenen Modulen. Das Gesamtpaket bietet im Gegensatz zur Lösung der OTRS AG die Kommunikation in beide Richtungen: Von OTRS nach JIRA und von JIRA nach OTRS. So bleiben beide Systeme auf dem aktuellen Stand. Aber wo liegen die Unterschiede in der Bedienung? Auch beim JIRAPackage kann der Informationsaustausch durch Trigger wie neue Tickets, neue Artikel, Statusänderung etc. angestoßen werden.
Möchte man aber vermeiden dass automatisch JIRA-Issues erzeugt werden, kann man das abschalten und der Agent muss aktiv das Erstellen des JIRA-Issues anstoßen. Dazu gibt es zwei Wege:
Sollen nur für ein einziges Projekt Vorgänge - mit einem bestimmten Typ - und für einen JIRA-Benutzer erstellt werden, kann der Dialog auch ausgeschaltet werden.
Kommen wir zur Konfiguration: Nach der Installation kann man im Adminbereich einfach über einen Wizard die JIRA-Integration einrichten. Es werden Dinge wie URL zu JIRA, Authentifizierungsdaten abgefragt und auch die Zuordnung von JIRA-Feldern zu OTRS-Feldern wird dort vorgenommen.
Für erfahrenere Admins kann das alles auch in der SysConfig direkt eingetragen werden. Dann kann man beim Mapping sogar dafür sorgen, dass Benutzerdefinierte Funktionen ausgeführt werden (z.B. damit Inhalte verschlüsselt übertragen werden).
Disclaimer: An der Entwicklung von JIRAPackage bin ich direkt beteiligt.
Wenn Sie Interesse am JIRAPackage haben, kontaktieren Sie doch bitte catWorkX.
Sie können auch über den JIRA Marketplace das Paket zur OTRS-Integration in JIRA in Ihrem JIRA installieren und das OTRS-Paket können Sie bei catWorkX herunterladen und dann erstmal testen.
Permalink: /2016-12-15-otrs-jira-vs-catworkx-jira
Ich habe am Mittwoch auf dem OTRS-Stammtisch Rheinland einen Vortrag gehalten. Der Titel: PostmasterFilter in OTRS
In dem Vortrag ging es darum, wie man mit Postmasterfiltern in OTRS die Mailverarbeitung bzw. die Ticketerstellung beeinflussen kann. Die Postmasterfilter, die über die Oberfläche konfiguriert werden können, haben aber Einschränkungen bzw. Nachteile. Auch den Aufbau einer Mail - der sehr kompliziert werden kann - habe ich in Grundzügen erläutert. Abschließend ging es um die Entwicklung eigener Postmasterfilter-Module. Mit diesem mächtigen Werkzeug hat man alle Möglichkeiten...
Vielen Dank an das Team von maxence für das Organisieren des Treffens! Ich möchte auch im nächsten Jahr wieder zwei- bis dreimal zu dem Stammtisch fahren. Wenn es Vortragswünsche gibt, bin ich dafür offen.
Permalink: /2016-12-09-postmasterfilter-community
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
Auf der diesjährigen OpenRheinRuhr werde ich einen Vortrag halten: 20 freie Addons für OTRS. Der Vortrag steht am Sonntag, 06. November 2016 um 10 Uhr auf dem Plan.
Ich würde mich freuen, wenn möglichst viele Zuhörer erscheinen und wir dann noch in eine Diskussion übergehen können.
Wer noch eine Karte für die OpenRheinRuhr benötigt, kann sich gerne bei mir melden.
Permalink: /2016-10-22-openrheinruhr-2016-vortragsankuendigung
Die Kundensuche wird sehr häufig benötigt: Beim Erstellen eines Tickets, beim Antworten, bei der Suche nach Kunden usw. Was aber wenn die Suche des Standards nicht ausreicht? Wenn nicht nur nach Vor- oder Nachname gesucht werden soll, sondern auch nach der Kombination Vor- und Zuname
oder nach der Telefonnummer?
Die Anpassung ist sehr einfach in der Kernel/Config.pm machbar. Es muss kein Kernmodul angepasst werden. Im Standard-OTRS ist in der Kernel/Config/Defaults.pm folgendes zu finden:
CustomerUserSearchFields => [ 'login', 'first_name', 'last_name', 'customer_id' ];
Damit wird festgelegt, dass die Kundensuche in den Spalten login, first_name und customer_id suchen soll. Das reicht dann aber nicht aus. Diese Liste muss um alle Felder erweitert werden, die durchsucht werden sollen.
Gehen wir davon aus, dass wir diese Kunden haben:
Jetzt wollen wir nach Fax Kunde
suchen. Bis wir fax eingegeben haben, wird der Kunde auch gefunden:
Aber sobald wir noch das k
vom Nachnamen eingeben ist es vorbei:
Einfach folgende Zeile in die Config.pm eintragen:
$Self->{CustomerUser}->{CustomerUserSearchFields} =
[ 'login', 'first_name', 'last_name', 'customer_id', 'CONCAT( first_name, " ", last_name )' ];
Da OTRS die Felder einfach 1:1 übernimmt kann man hier beliebigen SQL-Code eintragen oder auch einfach nur neue Spalten hinzufügen. Ab sofort kann man auch nach Vor- und Nachname suchen:
Permalink: /2016-10-20-kundensuche-anpassen
Ein Kalender hilft in der Regel einen Überblick über die Termine zu behalten. Im Standard-OTRS gibt es für die Übersichtsseite einen Ticket Event Kalender, der aber nicht sehr flexibel und nicht sehr aussagekräftig ist. Für die Tickets müssen dynamische Felder angelegt werden, diese müssen gefüllt sein und dann - wenn sie in der richtigen Queue sind - werden die Tickets in dem Kalender angezeigt.
Wir haben die Kalender etwas aufgebohrt, so dass Sie vielfältige Möglichkeiten haben festzulegen welche Tickets angezeigt werden. Zum Beispiel Erinnerungstickets mit dem Erinnerungsdatum. Eskalierende Tickets oder - ähnlich wie im Standard - in Abhängigkeit von Dynamischen Feldern.
Es sehen aber nicht alle Tickets gleich aus: Es werden noch Icons angezeigt, so dass man schnell erkennen kann ob es ein Erinnerungsticket oder ein anderes Ticket ist. Wie die Einträge eingefärbt sind, kann auch konfiguriert werden. So kann man sich bequem einen Kalender aufbauen bei dem jeder Agent schnell sieht welche Ereignisse für ihn oder sie ansteht.
So kann das ganze dann aussehen:
Über wenige Zeilen XML kann eine neue Kategorie von Tickets im Kalender angezeigt werden. Natürlich werden auch bei AdvancedTicketCalender die Berechtigungen auf Tickets berücksichtigt.
Interesse an dieser Erweiterung? Wenn Sie sich die Erweiterung in einem Demosystem anschauen möchten, nehmen Sie bitte Kontakt mit uns auf.
Permalink: /2016-09-29-advancedticketcalendar
Am 05. und 06. November werden wir auf der diesjährigen OpenRheinRuhr unsere OTRS Feature-Addons live zeigen. Sie haben dort die Möglichkeit, alle Feature-Addons mal auszuprobieren und mit uns über Wünsche, Anregungen und viele andere Dinge zu sprechen. Tickets können Sie auch bei uns bekommen - einfach melden.
Permalink: /2016-09-20-openrheinruhr-ausstellung
Wer viele Queues hat, wird vielleicht manchmal davon genervt sein, zigmal einen Unterbaum mit der Maus aufklappen zu müssen. Hier kann der Admin Abhilfe schaffen und den Queue-Baum automatisch aufklappen lassen.
Hinter dem Queue-Baum (und hinter allen anderen Dropdowns mit Baumstruktur) steckt die JavaScript-Bibliothek jsTree. Das ist der erste Ansatzpunkt für die Umsetzung. Also mal schauen, womit man einen Baum aufklappen kann. In der API-Dokumentation stößt man auf die Funktion open_all
. Diese Funktion muss man von JavaScript aus aufrufen. Aber wo und wann? Schauen wir uns an, ob man das bei der Initialisierung schon machen kann.
Das hilft also nicht weiter. Eine Suche mit DuckDuckGo bringt uns schon in die richtige Richtung. Man kann es bei der ersten Visualisierung einsetzen. Denn dann wird das Event ready.jstree
gefeuert. Das bringt uns zu dem Code
on('ready.jstree', function() {
$tree.jstree('open_all');
})
Als nächster Schritt muss dieser Code im OTRS eingeflegt werden. Eine Suche nach jstree
im JavaScript-Code von OTRS (unter $OTRS_HOME/var/httpd/htdocs/js/
) liefert uns die Datei Core.UI.InputFields.js
. Das Initialisieren des jsTree-Objekts passiert in der Funktion InitSelect
. Da packen wir den Code rein (unter OTRS5 ist das ca. Zeile 1383). Das $tree
muss noch durch $TreeObj
ersetzt werden und schon werden alle Baumstrukturen automatisch aufgeklappt.
Über die otrs-Mailingliste kam die Anforderung, dass nur die Queue-Bäume automatisch aufgeklappt werden soll. In diesem Fall muss der obige Code etwas angepasst werden. Die Funktion open_all
darf nur dann ausgeführt werden wenn es ein Queue-Dropdown ist:
on('ready.jstree', function() {
if ( isQueue ) {
$TreeObj.jstree('open_all');
}
})
Aber wie wird bestimmt, was an Stelle isQueue
stehen muss. Hier helfen die Developer-Tools der Browser. Einfach mit F12
bzw. Strg+Shift+i
öffnen, dann die Elementauswahl öffnen und dann z.B. in der Erfassungsmaske von Telefontickets auf ein Element der Queueauswahl klicken.
Dann im HTML-Code das Eltern-div raussuchen. Dort ist dann eine id
zu finden.
Diese ID muss in den JavaScript-Code eingetragen werden. Das muss für alle möglichen Dialoge wiederholt werden:
on('ready.jstree', function() {
if ( TreeID == 'Dest_Select' || TreeID == 'DestQueueID_Select' ) {
$TreeObj.jstree('open_all');
}
})
Jetzt werden nur noch die Bäume der Queue-Auswahl automatisch ausgeklappt.
Permalink: /2016-09-19-expand-js-tree
In OTRS kann man Tickets mit anderen Tickets verknüpfen oder mit FAQ-Einträgen, ConfigItems, etc. Es gibt Kunden die sehr intensiv Tickets miteinander verknüpfen was schnell zu einer unübersichtlichen und sehr langen Liste von Verknüpften Objekten in der Ticketansicht führen kann. Mit LinkDataTableEnhanced erweitern wir diese Übersicht um einige Features. Wir haben auch eine Weiterentwicklung von OTRS - konfigurierbare Spalten - zurückportiert.
Fangen wir klein an: Die Spalten sind jetzt sortierbar. Das funktioniert auch mit der Community-Version des Moduls. Damit lässt sich schon relativ schnell Ordnung in die Übersicht bringen. Als nächstes haben wir die Möglichkeit geschaffen, Aktionen für verknüpfte Tickets zu ermöglichen. Zum Einen kann man eine Liste der verknüpften Tickets drucken, wobei auch hier die konfigurierten Spalten angezeigt werden.
Weiterhin können Sammeländerungen an verknüpften Tickets vorgenommen werden. Einfach die zu ändernden Tickets über die Checkboxen auswählen, auf Sammeländerung
klicken und dann z.B. eine Notiz hinzufügen oder den Status ändern.
Wenn wir schon beim Thema neue Notizen an mehrere verknüpfte Tickets sind, dann darf der Hinweis auf QuickClose nicht fehlen. Mit dem Modul können Sie aus der Ticketansicht und den verschiedenen Übersichtsseiten (Ansicht nach Queue, Ansicht nach Status, ...) heraus neue Notizen an Tickets hängen, mit einer Standardbegründung schließen, in eine andere Queue verschieben und vieles mehr.
Und auch bei den verknüpften Tickets ist mit LinkDataTableEnhanced die Integration von QuickClose möglich. Wenn QuickClose installiert ist, kann die Integration einfach über die SysConfig aktiviert werden. Kurzer Hinweis: Damit es richtig funktioniert, muss QuickClose in der neuesten Version installiert sein.
Für die QuickCloses gibt es dann ein oder mehrere Dropdowns:
Und die vierte Aktion, die aktuell in LinkDataTableEnhanced eingebaut ist ist die Schnellverknüpfung. Damit kann man die ausgewählten Tickets ganz schnell mit vorgefilterten Tickets verknüpfen. In der SysConfig kann mit dem Suchfilter bestimmt werden, welche Tickets in dem Dialog zur Schnellverknüpfung angezeigt werden sollen. In der Übersicht der verknüpften Tickets einfach die ein paar Tickets auswählen, auf Schnellverknüpfung klicken, die Tickets auswählen mit denen verknüpft werden soll und abschicken.
Damit sieht die Übersicht der verknüpften Objekte folgendermaßen aus:
Wenn Sie sich die Erweiterung in einem Demosystem anschauen möchten, nehmen Sie bitte Kontakt mit uns auf.
Permalink: /2016-09-16-linkdatatableenhanced
Ich habe einige Module auf OPAR aktualisiert:
Ein komplett neues Modul ist TicketSearchReminderTime. Bisher gab es keine Möglichkeit über die Ticketsuche herauszufinden welche Tickets in den nächsten 7 Tagen, zwischen dem 01.07.2016 und 08.07.2016 oder vor mehr als 1 Jahr erinnert wurden. Dieses neue Modul ermöglicht die Suche nach Tickets an Hand der Erinnerungszeit.
Mit diesen beiden Modulen wird im Ticket- bzw. ConfigItem-Druck ein Barcode eingefügt. Ziel der beiden Erweiterungen ist es Tickets und ConfigItems schneller zu finden. Mit einem Barcodescanner fällt dann nämlich das Eintippen der - durchaus langen - Ticket- bzw. ConfigItem-Nummer weg.
In der neuen Version wurde die Generierung von Code39-Barcodes gefixt.
Mit MoveTicketLinkedObjects wird die Tabelle der verlinkten Objekte in der Ticketansicht unter den Artikelbaum geschoben. So sind verknüpfte Incidents etc. schneller auffindbar.
Jetzt gibt es das Modul auch für OTRS5.
Permalink: /2016-07-08-OPAR-Updates-27-2016