Blog

Start 1 2 3 4 5 6

Kundensuche anpassen - was wird durchsucht

21.10.2016 // Renée Bäcker

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:

Kundenübersicht

Jetzt wollen wir nach Fax Kunde suchen. Bis wir fax eingegeben haben, wird der Kunde auch gefunden:

Suche nur nach Vorname

Aber sobald wir noch das k vom Nachnamen eingeben ist es vorbei:

Suche nach Vor- und Nachname im Standard

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:

Suche nach Vor- und Nachname nach der Änderung

Permalink:

Neue Version: AdvancedTicketCalendar

29.09.2016 // Renée Bäcker

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:

Ticketkalender im Dashboard

Ü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:

OpenRheinRuhr 2016: Lernen Sie unsere Addons live kennen

20.09.2016 // Renée Bäcker

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:

Queue-Baum automatisch aufklappen

19.09.2016 // Renée Bäcker

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.

Eine Queue selektieren

Dann im HTML-Code das Eltern-div raussuchen. Dort ist dann eine id zu finden.

Eltern-div der Queue-Auswahl

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:

Neues Feature-Addon: LinkDataTableEnhanced

13.09.2016 // Renée Bäcker

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.

Ausdruck Liste der verknüpften Tickets

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.

Auswahl der zu ändernden Tickets über Checkboxen

Dialog zur Sammeländerung

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:

Verknüpfte Tickets mit QuickClose verändern

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.

Dialog zum Schnellverknüpfen

Damit sieht die Übersicht der verknüpften Objekte folgendermaßen aus:

Komplette Übersicht der verknüpften Objekte mit allen aktivierten Aktionen

Wenn Sie sich die Erweiterung in einem Demosystem anschauen möchten, nehmen Sie bitte Kontakt mit uns auf.

Permalink:

Updates für OPAR-Module

08.07.2016 // Renée Bäcker

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:

Neue Features in TicketChecklist 5.0.5

13.05.2016 // Renée Bäcker

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:

Checkliste im Ticketdruck

Desweiteren kann man beim Ändern von Aufgaben auch eine Notiz eingeben:

Änderungsnotiz über den Checklisten-Dialog

Wird das Notizfeld gefüllt, wird dieser Text als Artikel am Ticket gespeichert und der Verantwortliche der Aufgabe bekommt eine Benachrichtigung.

Änderungsnotizen in der Artikelübersicht

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.

Änderungsnotiz bei Statusänderung über das Widget in der Ticketansicht

Permalink:

Checklisten automatisch per GenericAgent zuweisen (Pro-Version)

10.06.2016 // Renée Bäcker

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.

Das Template für die Checkliste enhält die wichtigsten Aufgaben wenn neue Mitarbeiter kommen

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.

Als Auslöser für den GenericAgent wurde das Ereignis 'TicketCreate' ausgewählt

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.

Die Queue HR::NewEmployee wurd im Ticketfilter ausgewählt

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:

Mitarbeitern nur das Notieren von Telefonanrufen erlauben

06.06.2016 // Renée Bäcker

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:

TicketTyp mit Dynamischen Feld und GenericAgent setzen

27.05.2016 // Renée Bäcker

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:

OTRS in der "IT Administrator" (2/16)

25.05.2016 // Renée Bäcker

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:

Archiv

    Start 1 2 3 4 5 6