Blog

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: /2016-07-08-OPAR-Updates-27-2016

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:

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.

Permalink: /2016-06-13-checklist-pro-neue-features-5-0-5

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.

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

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: /2016-06-06-telefonnotiz-ohne-rw-rechte

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: /2016-05-27-dynamicfield-tickettype

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: /2016-05-25-it-administrator-article

20.05.2016 // Renée Bäcker

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

19.05.2016 // Renée Bäcker

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

15.05.2016 // Renée Bäcker

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:

1. mod_perl mit einem anderen Perl kompilieren
2. Eine ältere oder andere Distribution einsetzen
3. 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):

1. Debian Jessie kommt mit Perl 5.20.3
2. letzte LTS-Release von Ubuntu: 14.04 (Trusty Tahr) bietet Perl 5.18.2
3. CentOS 7 bietet Perl 5.16.3
4. 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

13.05.2016 // Renée Bäcker

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

06.05.2016 // Renée Bäcker

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