Frohe Weihnachten
Ein ereignisreiches und erfolgreiches Jahr geht zu Ende. Im Fernsehen gibt es auf jedem Sender einen Rückblick auf das Jahr 2016 - und auch wir wollen kurz zurückschauen auf das was bei uns so los war.
Ich war zweimal in Dormagen auf dem OTRS-Stammtisch und habe dort jeweils einen Vortrag gehalten. Vielen Dank an dieser Stelle an die Fahrer, die mich jeweils zum Treffen und auch wieder zurück nach Köln gebracht haben. Die Treffen sind immer sehr interessant und es macht Spaß sich mit den Teilnehmern/Teilnehmerinnen zu unterhalten - auch über OTRS-fremde Themen. Ich freue mich aber auch sehr über die vielen Anregungen sowohl für die freien Module als auch die kommerziellen Module.
Vielen Dank an das Team von maxence für das Organisieren der 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.
Unsere Module werden sehr gut angenommen und von den Kunden gibt es immer wieder nützliches Feedback zu den Erweiterungen. Viele gewünschte Features konnten wir in die Erweiterungen einbauen, so dass alle Kunden davon profitieren können. Wir würden uns freuen, wenn es auch im nächsten Jahr so erfolgreich weitergeht.
Viele Erweiterungen konnten wir noch nicht auf der Webseite oder hier im Blog zeigen, weil wir es zeitlich nicht geschafft haben. Und auch im nächsten Jahr wird es einige neue Erweiterungen geben.
Dann habe ich noch OTRSWeekly gestartet - ein wöchentlicher Newsletter zum Thema OTRS.
Jetzt bleibt mir nur noch, Ihnen allen Frohe Weihnachten und ein gutes neues Jahr zu wünschen. Genießen Sie die Feiertage und kommen Sie zur Ruhe.
Permalink: /2016-12-24-frohe-weihnachten
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.
JIRA-Connector der OTRS-AG vs. JIRAPackage von catWorkX
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:
- Wenn der Vorgang in JIRA schon ab dem ersten Artikel gelten soll, kann der Agent im Ticketmenü auf OTRS -> JIRA klicken. Dann wird der erste Artikel als Basis genommen und der Vorgang dafür erstellt. Es ist auch konfigurierbar dass neben dem ersten Artikel auch alle anderen Artikel an das JIRA übertragen werden. Das ist dann hilfreich wenn sich erst im Laufe der Kommunikation mit dem Kunden rausstellt, dass das Ticket ein Thema für die Entwickler ist.
- Wenn ein Ticket schon viele Artikel hat und bspw. der sechste Artikel die Infos für einen JIRA-Vorgang enthält. Dann kann der Agent im Artikelmenü auf OTRS -> JIRA klicken. Dann werden die Artikel 1-5 nicht an das JIRA übertragen.
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
Folien "Postmasterfilter in OTRS"
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
Ticket-Workflows mit der Erweiterung TicketTemplates
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:
- Die Personalabteilung muss den Vertrag aufsetzen
- Die IT-Abteilung muss E-Mail-Konten einrichten und Berechtigungen setzen
- Das Büro muss eingerichtet werden
- und noch vieles mehr
Aber die IT-Abteilung darf erst mit der Arbeit anfangen wenn der Vertrag da ist.
Einrichten des Workflows
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.
Workflow starten
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
Vortrag auf der OpenRheinRuhr 2016:
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
Kundensuche anpassen - was wird durchsucht
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
Neue Version: AdvancedTicketCalendar
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
OpenRheinRuhr 2016: Lernen Sie unsere Addons live kennen
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
Queue-Baum automatisch aufklappen
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
Neues Feature-Addon: LinkDataTableEnhanced
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
Updates für OPAR-Module
Ich habe einige Module auf OPAR aktualisiert:
TicketSearchReminderTime
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.
TicketBarcode und CIBarcode
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.
MoveTicketLinkedObjects
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
Neue Features in TicketChecklist 5.0.5
Heute wurde die Version 5.0.5 Pro-Version von TicketChecklist veröffentlich. In diesem Blogpost möchte ich die neuen Features vorstellen.
Als erstes gibt es ein zusätzliches Ticketdruck-Modul. Damit ist in dem PDF auch die Checkliste enthalten. Nach der Installation müssen Sie dieses Modul noch aktivieren und das bisherige Ticketdruck-Modul in der SysConfig deaktivieren.
So sieht das PDF dann aus:
Desweiteren kann man beim Ändern von Aufgaben auch eine Notiz eingeben:
Wird das Notizfeld gefüllt, wird dieser Text als Artikel am Ticket gespeichert und der Verantwortliche der Aufgabe bekommt eine Benachrichtigung.
Beides ist aber auch einzeln abschaltbar.
Zusätzlich zu dem Änderungsfeld im Dialog kann auch beim Ändern des Status über das Widget in der Ticketansicht eine Änderungsnotiz eingegeben werden. Auch hierüber wird die Notiz als Artikel angehängt und der Verantwortliche benachrichtigt.
Checklisten automatisch per GenericAgent zuweisen (Pro-Version)
In der Pro-Version von TicketChecklist gibt es die Möglichkeit Templates für Checklisten zu erstellen. Mit Hilfe der Templates und einem GenericAgent ist es sehr einfach möglich Ticket nach bestimmten Kriterien automatisch mit einer Checkliste zu versehen.
Nehmen wir an, für jeden neuen Mitarbeiter müssen die gleichen Aufgaben erledigt werden: Arbeitsvertrag, bei Sozialversicherungen melden, PC bestellen, E-Mail-Account einrichten und vieles mehr. Dafür kann man eine Vorlage für Checklisten erstellen.
Hat man die Vorlage angelegt, geht es zum GenericAgent. Im Adminbereich einen neuen Job hinzufügen und einen Namen eingeben. Da der GenericAgent sofort greifen soll wenn ein Ticket erstellt wird, läuft der GenericAgent nicht regelmäßig (zeitgesteuert) sondern durch einen Event ausgelöst.
In diesem Fall ist es das Event TicketCreate. Das muss ausgewählt und über das +
zu der Liste der Events hinzugefügt werden.
Die Tickets für neue Mitarbeiter landen immer in der Queue HR::NewEmployee, deswegen wird beim Ticketfilter nur diese Queue ausgewählt. Neue Tickets in anderen Queues bekommen also nicht die Checkliste zugewiesen.
Abschließend muss noch angegeben werden, dass ein Benutzerdefiniertes Modul aufgerufen werden soll. Dieses Modul wird schon von TicketChecklist bereitgestellt und heißt Kernel::System::GenericAgent::AddChecklistToTicket.
Als Parameter erwartet dieses GenericAgent-Modul die ID der Checkliste die dem Ticket hinzugefügt werden soll und die UserID
desjenigen der die Checkliste hinzufügt. Der Einfachheit halber geben wir bei der UserID einfach 1 an, was für den Admin OTRS
steht.
Die ID der Checkliste lässt sich über die Übersicht der Vorlagen herausfinden. Gleich die erste Spalte der Übersicht zeigt die ID der jeweiligen Vorlage. Diese ID dann als Parameter im GenericAgent eintragen.
Fordern Sie noch heute Ihr Demosystem an.
Permalink: /2016-06-10-checklist-pro-generic-agent
Mitarbeitern nur das Notieren von Telefonanrufen erlauben
Auch wenn sich ein Ticket schon in der Bearbeitung befindet, sollen die MitarbeiterInnen in der Lage sein, eingehende Telefonanrufe am Ticket zu notieren. Das Ticket befindet sich aber in einer Queue, in der die Mitarbeiter der Hotline keine Schreibrechte haben - und die sollen sie auch nicht bekommen.
Jetzt gibt es zwei Möglichkeiten, wie diesen Mitarbeitern das Hinzufügen von solchen Notizen über eingehende Telefonanrufe erlaubt werden kann. Für beide Lösungen gilt, dass die MitarbeiterInnen mindestens Leserechte (ro) auf die Queue benötigen.
Alle Mitarbeiter mit Leserechten auf die Queue Notiz-Rechte geben
Die erste Möglichkeit ist, allen Mitarbeitern mit Leserechten auf die Queue das Hinzufügen von Notizen zu ermöglichen. Dazu benötigen sie noch die note-Rechte.
Damit ist dann aber schon wieder zu viel
möglich. Dann können auch andere Notizen angehängt werden. Und vielleicht
können Agenten über die Notizen noch viel mehr Ticket-Einstellungen vornehmen
Das Telefon-Recht einführen.
Wer jetzt schon in die SysConfig geschaut hat, hat bei dem Eintrag Ticket::Frontend::AgentTicketPhoneInbound###Permission den Wert phone gesehen. Was ist das für ein Recht? In der Verwaltung der Agenten- bzw. Rollenberechtigung taucht das gar nicht auf?!
Man kann in OTRS auch eigene Rechte einführen, man muss sie dann nur auch aktivieren. Wenn man die SysConfig durchschaut, sieht man bei einigen Ansichten Rechte die in den Berechtigungen nicht auftauchen. Das zeigt schon, dass man auch im Standard-OTRS viel feiner Berechtigungen vergeben kann als man vielleicht angenommen hat.
Aber hier gilt wie an vielen Stellen: Vorsicht vor zu vielen Rechten. Sonst kann man schnell den Überblick darüber verlieren wer was darf - und auf Grund welcher Berechtigung.
Aber zurück zum Thema. Notizen über Telefonate mit Telefon-Rechten erstellen. Als erstes muss das Recht phone in der SysConfig aktiviert werden. Das wird in der Option System::Permission gemacht. Hier muss man darauf achten, dass das rw-Recht als letzter Eintrag erhalten bleibt.
Das ganze sieht dann so aus:
Nach dem Speichern der SysConfig-Änderungen steht das Telefon-Recht in der Rechteverwaltung zur Verfügung. Abschließend noch den Mitarbeitern an den Telefonen dieses Recht einräumen und schon können sie die Telefonanrufe der Kunden direkt am Ticket notieren.
Permalink: /2016-06-06-telefonnotiz-ohne-rw-rechte
TicketTyp mit Dynamischen Feld und GenericAgent setzen
Bei einem Kunden ist die Anforderung aufgetaucht, dass man den Tickettyp auch direkt in den Antworten ändern können soll. Ein Standard-OTRS gibt das nicht her. Hier kann man nur bei Notizen und in einigen anderen Dialogen den Tickettyp ändern.
Eine Möglichkeit wäre natürlich den Code anzupassen und so das gewünschte Feature einzubauen. Ich möchte aber kurz zeigen, wie man das mit (fast) reinen Bordmitteln erledigen kann.
Die einzige Komponente, die es nicht standardmäßig im OTRS gibt ist die Erweiterung DynamicFieldRemoteDB von c.a.p.e IT. Die kann normal über den Paketmanager von OTRS installiert werden.
Ist die Erweiterung installiert, geht es zum nächsten Schritt. Im Adminbereich muss für das Ticket ein Dynamisches Feld vom Type RemoteDB angelegt werden:
Als Namen vergeben wir einfach mal TicketType. Bei den RemoteDB-Einstellungen muss man die Informationen für die Datenbankverbindung hinterlegen. Für DSN, User und Passwort muss man einfach mal in die Kernel/Config.pm schauen.
Als Tabelle muss ticket_type gewählt werden, der Schlüssel ist die Spalte id und als Spalte für den Wert - wir können ja nichts mit den numerischen IDs in der Oberfläche anfange - wählen wir name.
Anschließend muss das Feld noch für die Antworten
-Ansicht freigeschaltet werden. Dazu in der SysConfig die Gruppe
Ticket und die Untergruppe Frontend::Agent::Ticket::ViewCompose auswählen. Dort gibt es die Option
Ticket::Frontend::AgentTicketCompose###DynamicField, in der wir das neue Feld eintragen:
Wenn wir jetzt den Antworten
-Dialog öffnen, sehen wir ziemlich weit unten das Dropdown mit den Tickettypen:
Jetzt müssen wir nur dafür sorgen, dass sich auch der Tickettyp-Wert ändert wenn wir in dem Dropdown etwas auswählen und die Mail abschicken. Dazu benutzen wir den GenericAgent. Dieser ist auch über den Adminbereich zu finden. Da wir nicht regelmäßig die Tickets nach irgendwelchen Werten durchsuchen, sondern auf Änderungen des Dynamischen Feldes reagieren wollen, müssen wir einen Eventgesteuerten GenericAgent erstellen.
Als Event wählen wir
Der letzte Teil hängt von dem Namen ab, den Sie beim Erstellen des Dynamischen Feldes gewählt haben.
Etwas aufwändig ist das Ganze, weil für jeden Tickettyp muss ein GenericAgent erstellt werden. Hat mal drei Tickettypen in der Datenbank, müssen drei GenericAgents erstellt werden. Das bedeutet auch, dass GenericAgents erstellt werden müssen, wenn Tickettypen in der Datenbank hinzukommen (z.B. durch Installation des ITSMChangeManagement-Moduls).
Im Ticketfilter müssen wir den neuen Wert des Dynamischen Feldes wählen - hier z.B. Incident. Damit sagen wir: Der
GenericAgent soll ausgeführt werden wenn sich das Dynamische Feld TicketType
ändern und zwar auf Incident
.
Im Bereich der zu ändernden Attribut müssen wir dann bei Neuer Typ
ebenfalls Incident wählen. Damit wird der tatsächliche
Tickettyp geändert.
Jetzt noch abspeichern und ab dann steht das neue Feature zur Verfügung.
Permalink: /2016-05-27-dynamicfield-tickettype
OTRS in der "IT Administrator" (2/16)
Es ist zwar nicht die ganz aktuelle Ausgabe vom IT-Administrator, aber in der Ausgabe 2/16 (Februar 2016) gibt es einen längeren Artikel von Dr. Holger Reibold.
Im Artikel Modulbauweise OTRS mit Add-ons aufgebohrt
beschreibt Dr. Reibold einige OTRS-Erweiterungen, die die Funktionalität
von OTRS verbessert. Neben den Erweiterungen der OTRS AG werden auch einige Erweiterungen genannt, die
es auf OPAR gibt.
Auch Module von uns werden genannt, u.a. TicketChecklist in der Pro- und Community-Version und MultiSMTP. Die Nennung unserer Module freut uns natürlich sehr...
Permalink: /2016-05-25-it-administrator-article
TicketChecklist 5.0.3
Heute haben wir die Version 5.0.3 von TicketChecklist veröffentlicht. In der neuen Version gibt es einige Änderungen:
- Beim Ticketerstellen können mehrere Checklisten angewandt werden
- Die TODO-Punkte können mit einem Artikel verknüpft werden
- Alle Einträge können auf einmal gelöscht werden
Sie können ab sofort ein Demosystem mit der neuen Version anfordern.
Permalink: /2016-05-20-ticketchecklist-5-0-3
OTRS 5.0.10
In dieser Woche hat die OTRS AG neue Versionen von OTRS und von ein paar weiteren Addons veröffentlicht: OTRS 5.0.10 und OTRS 4.0.17 beheben einige Bugs und teilweise wurde Konsolekommandos eingeführt.
Bei den freien Addons gibt es neue Versionen von OTRS::ITSM, FAQ und TimeAccounting.
Die ganze Liste der Änderungen ist in den Release-Ankündigungen zu finden:
OTRS 5.0.10 OTRS 4.0.17 OTRS::ITSM 4.0.17 FAQ 5.0.3 TimeAccounting 5.0.2
Permalink: /2016-05-19-otrs-5-10
OTRS mit Apache und mod_perl unter Perl 5.22
Manchmal ist es echt zum Verzweifeln: Man will mal schnell eine VM aufsetzen um etwas auszuprobieren, nimmt die neuesten Pakete, installiert alles notwendige für OTRS und nichts funktioniert.
Das hat man doch schon tausendmal gemacht, immer hat das mit der OTRS-Installation funktioniert nur diesesmal nicht. Im Browser taucht nur ein Internal Server Error auf und in den Fehlerlogs ist nichts zu finden.
Aber da war doch was... Richtig, mod_perl funktioniert unter Perl >= 5.22 nicht (siehe den entsprechenden Bugreport) und Ubuntu 16.04 liefert ein Perl 5.22.1 aus. Bisher wurde XUbuntu 15.04 eingesetzt, da war es noch Perl 5.20. Also muss eine andere Lösung her. Es gibt hier im Großen und Ganzen drei Möglichkeiten:
- mod_perl mit einem anderen Perl kompilieren
- Eine ältere oder andere Distribution einsetzen
- Nginx einsetzen und statt mod_perl einfach FastCGI benutzen
mod_perl mit einem anderen Perl zu kompilieren ist einiges an Aufwand, so dass diese Option ausfällt. Denn man muss erst ein anderes Perl installieren, die Quellen von mod_perl holen, sicherstellen dass alle Abhängigkeiten richtig installiert sind und dann kompilieren. Mehr Infos dazu gibt es in der ModPerl-Dokumentation.
Die einfachste Lösung ist es, eine ältere oder andere Linux-Distribution einzusetzen. Hier ein Überblick, welches Perl man mit welcher (jeweils) aktuellen Version bekommt (Stand: 15.05.2016):
- Debian
Jessie
kommt mit Perl 5.20.3 - letzte LTS-Release von Ubuntu: 14.04 (
Trusty Tahr
) bietet Perl 5.18.2 - CentOS 7 bietet Perl 5.16.3
- Gentoo hat ein Perl 5.22 Paket
Ich rolle die Liste mal von hinten auf... Gentoo hat ein Perl 5.22 Paket, läuft also in das gleiche Problem wie (X)Ubuntu.
CentOS 7 hat mit Perl 5.16 ein relativ altes Perl (Perl 5.16.3 ist von 2013), ist aber eine stabile Plattform. Ich selbst habe einige OTRS-Installationen unter CentOS laufen und auch einige Kunden von mir haben ihr OTRS auf CentOS laufen (wir stellen hier unsere Erweiterungen auch gerne als RPM-Pakete zur Verfügung). Als Falle
kann man SELinux ansehen. In der Regel wird das Abschalten von SELinux als Lösung genannt. Ich werde aber in einem anderen Blogpost mal zeigen, wie man OTRS betreiben und den Sicherheitsgewinn von SELinux nutzen kann.
Alle zwei Jahre bringt Canonical eine Ubuntu-Version als LTS (Long-Term Support) heraus. Sie versprechen 5 Jahre Support mit Sicherheits- und Bugfix-Releases. Wie Heise allerdings Ende April gemeldet hat, gilt dies nicht für alle Pakete, so dass man Gefahr läuft relativ schnell ein System zu haben, bei dem Sicherheitslücken offen sind. Ich selbst nutze sehr gerne Ubuntu, weil es schön einfach ist. Das werde ich aber in Zukunft überdenken.
Debian ist ebenfalls eine stabile Plattform, mit der ich allerdings noch nicht so viel Erfahrung habe. Da aber Ubuntu auf Debian basiert, ist in der Administration vieles gleich.
Es gibt noch viele weitere Linux-Distribution, die ich aber nicht alle hier auflisten kann.
Auf zur dritten Lösungsmöglichkeit: nginx mit FastCGI. nginx ist ein kleiner schlanker Webserver, der schon bei einigen unserer Webanwendungen (z.B. auch dieses Blog und die Seite von Feature-Addons.de) den Apache abgelöst hat. Statt mod_perl kommt hier FastCGI zum Einsatz.
Alle hier gezeigten Befehle sind auf einem Ubuntu 16.04 getestet. Bei Befehlen in der Kommandozeile ist immer ein $ vorangestellt, dass nicht mitgetippt werden soll.
Zuerst muss der nginx und fcgiwrap installiert werden.
$ apt-get install nginx fcgiwrap
Anschließend muss sichergestellt werden, dass in der /etc/init.d/fcgiwrap Sockets verwendet werden und sowohl der FCGI_USER als auch die FCGI_GROUP auf www-data steht. In meinen Tests war das aber schon alles richtig eingestellt.
In der /etc/nginx/fastcgi_params muss die Zeile
fastcgi_param SCRIPT_FILENAME $request_filename;
eingefügt werden.
Als nächstes muss die Konfiguration für das OTRS im nginx erstellt werden:
/etc/nginx/conf.d/otrs.conf:
server {
server_name localhost;
# Wenn OTRS nicht in /opt/otrs liegt, dann muss
# dieser Pfad angepasst werden!
set $otrs_home "/opt/otrs";
set $otrs_htdocs "$otrs_home/var/httpd/htdocs/";
access_log $otrs_home/var/log/otrs_access.log;
# These 2 lines were necessary to prevent buffer problems in OTRS
fastcgi_buffers 8 16k;
fastcgi_buffer_size 32k;
root $otrs_htdocs;
# Do not log favicon access
location = /favicon.ico {
access_log off;
log_not_found off;
}
location /otrs-web/ {
alias $otrs_htdocs;
}
location ~ ^/otrs/(.*\.pl)(/.*)?$ {
gzip off;
# Enter your fcgiwrap socket here
fastcgi_pass unix:/var/run/fcgiwrap.socket;
fastcgi_index index.pl;
fastcgi_param SCRIPT_FILENAME $otrs_home/bin/cgi-bin/$1;
include fastcgi_params;
}
}
Wir nutzen hier die Möglichkeit Variablen in der Konfiguration zu setzen, damit nicht immer wieder das selbe getippt werden muss.
Abschließend noch den nginx neustarten:
$ service nginx restart
Das war's. Jetzt kann man auch auf einem neuen Ubuntu OTRS installieren. Die nginx-FastCGI-Variante funktioniert aber auch auf anderen Linux-Distributionen.
Permalink: /2016-05-15-otrs-apache-mod-perl-perl-5-22
Folien "40 OPAR-Module in 20 Minuten"
Ich habe Mitte April auf dem OTRS-Stammtisch Rheinland einen Vortrag gehalten. Der Titel: 40 OPAR Module in 20 Minuten.
Genauer vorgestellt habe ich 27 Module und 13 Module im Schnelldurchlauf. Die Folien zu dem Vortrag sind auf Speakerdeck zu finden.
Vielen Dank an das Team von maxence für das Organisieren des Treffens! Und natürlich für die Verpflegung und den Geburtstagskuchen (es war der 5. Geburtstag des OTRS-Stammtischs Rheinland).
Ich habe auch einiges an interessantem Feedback zu ein paar der Modulen bekommen. Ein paar Sachen werden in das nächste Community-Release von TicketChecklist fließen.
Permalink: /2016-05-13-40-opar-modules
Tickets in Ticketübersichten nach Besitzer einfärben
Als erstes wird die Erweiterung TicketOverviewHooked benötigt.
Danach folgende Dateien anlegen:
Kernel/Config/Files/OwnerHook.xml
Kernel/System/TicketOverview/Hooks/Owner.pm
In der SysConfig müssen dann die Besitzer eingepflegt werden. Bei der Option Hook::Owners
muss als
Schlüssel der Login des Agenten angegeben werden und als Wert der Hex-Code für die Farbe.
Auf Wikipedia ist eine Farbtabelle zu finden.
Außerdem muss die Option TicketOverview::Hooks angepasst und das neue Plugin eingetragen werden:
Schlüssel: 1002
Wert: Kernel::System::TicketOverview::Hooks::Owner
Soll die Farbe nicht über die SysConfig sondern direkt aus den Agentendaten ausgelesen werden, so muss die
Run()-Methode entsprechend angepasst werden.
Permalink: /2016-05-06-overview-hook