Blog

Neuerungen in TicketChecklist

24.11.2020 // Renée Bäcker

Gibt es Aufgaben an einem Ticket, können diese in der neuesten 6.0.x-Version per Mail geändert werden. Ein Beispiel: Am Ticket gibt es die Aufgabe Büro einrichten

b745724d-b0a6-409f-bddf-8f6437bb98ca.png

Sollen Aufgaben per Mail geändert werden, wird ein Postmaster-Filter benötigt. Mit Postmaster-Filtern können eingehende Mails mit Regulären Ausdrücken überprüft werden und über erweiterte Mailheader können Tickets geändert werden.

TicketChecklist trägt in der SysConfig-Option PostmasterX-Header einige zusätzliche Mailheader ein, die für diesen Zweck genutzt werden können.

Postmaster-Filter sind mächtig und man kann viele Dinge relativ einfach automatisieren. Ein Problem mit Postmaster-Filtern ist aber, dass man sich mit den Personen die die Mails schreiben, auf ein Format des Inhalts einigen muss.

In diesem Fall legen wir fest, dass in der Mail der feste Wert *Todo schließen: *stehen muss und der Name der zu ändernden Aufgabe folgt, also:

c2950c0f-c18b-4122-b9fb-0fb59cf38be6.png

Damit sieht der Beispiel-Postmaster-Filter im Suchteil wie folgt aus:

04d38b6c-e22c-480e-9753-aab3261ba1cd.png

Hier wird also der Mailheader Subject mit dem Regulären Ausdruck Todo schließen: (.\*) geprüft. Je nach Vereinbarung kann der Reguläre Ausdruck auch anders aussehen und/oder es können wietere Mailheader geprüft werden.

Durch die runden Klammern im Regulären Ausdruck wird alles nach dem Schlüsselterm gespeichert und steht zur weiteren Verwendung im Postmaster-Filter zur Verfügung. In dem Beispiel-Betreff wäre das dann Büro einrichten.

Diesen gespeicherten Wert werden wir auch noch Nutzen. Der beschreibt nämlich den Titel der Aufgabe, die geändert werden soll. Was geändert werden soll, legen wir im Bereich Email-Header setzen fest:

860dcbdc-be1e-471d-b25e-a81e7f509111.png

Mit \[\*\*\*\] greifen wir auf den gespeicherten Wert zu. Das heißt, dass in dem Beispiel der Mailheader X-OTRS-TicketChecklistItem-1 auf Büro einrichten gesetzt wird, und X-OTRS-TicketChecklistItem-1-Status auf done.

Ein Modul der Erweiterung sorgt dann dafür, dass die Aufgabe angepasst wird. Zum Testen erstellen wir eine Datei (z.B. MailChecklist.eml), in die der Mailinhalt geschrieben wird:

To: ticketchecklist@feature-addons.de
From: checklist@feature-addons.de
Subject: =?UTF-8?Q?[Ticket#2020112440000018] Todo_schlie=c3=9fen=3a_B=c3=bcro_einrichten?=
Date: 2020-11-24 16:02:30+0200

Das ist ein Test

Das ist also eine Mail für das oben gezeigte Ticket. Der Betreff sieht hier zwar komisch aus, ist so aber richtig. Wenn man nicht weiß, wie die eigenen gewünschten Mails aussehen, kann an das OTRS eine Mail schicken. Wenn die SysConfig-Option Ticket::Frontend::PlainView aktiviert ist, steht in der Ticketansicht ein Link Unformatierte Ansicht zur Verfügung. Dort sieht man dann alle Mailheader.

Über das Skript otrs.Console.pl kann diese Mail jetzt eingespielt werden:

perl bin/otrs.Console.pl Maint::PostMaster::Read < MailChecklist.eml

Wenn das durchgelaufen ist, sollte die Aufgabe geschlossen sein:

46b4e126-6163-406a-9078-1199f88d5c08.png

Permalink:

Checklisten und Templates nutzen

17.08.2020 // Renée Bäcker

Unsere beiden Addons TicketChecklist und TicketTemplates helfen dabei, das Leben der Agent:innen zu vereinfachen. Letzteres um weniger Text bei der Erfassung von Tickets zu schreiben und einige Voreinstellungen wie Priorität, Queue etc. zu treffen und ersteres, damit man die ganzen Aufgaben im Zusammenhang mit einem Ticket im Überblick zu behalten.

In diesem Beitrag zeige ich, wie man beide Erweiterungen miteinander verknüpfen kann. Nehmen wir an, dass beim Onboarding von neuen Mitarbeitern in einem Tickettext ein Teil der Stammdaten erfasst werden, die für die Abarbeitung der Aufgaben notwendig sind.

Das Template könnte also wie folgt – oder so ähnlich – aussehen:

cfabb104-56d4-4b8a-a3f9-3a65e3f8b9b6.png

Und immer wenn das Ticket mit diesem Template erstellt wird, soll folgende Checkliste an das Ticket gehängt werden:

b964f039-e84a-4fcb-aebe-0f0d008f7a7d.png

Eine direkte Verknüpfung zwischen den Modulen gibt es nicht. Aber eine indirekte Verknüpfung ist möglich: über den GenericAgent!

TicketTemplates setzt in der aktuellen Version das Dynamische Feld PSTicketTemplateID auf die ID des Templates das genutzt wurde und ein GenericAgent kann auf Änderungen eines Dynamischen Feldes reagieren. In diesem GenericAgent-Job kann dann wiederum das GenericAgent-Modul genutzt werden, das TicketChecklist mitliefert.

Auf unserem Beispielsystem hat das Template die ID 18 (kann man herausbekommen, indem man mit der Maus in der Templateübersicht über den Namen des Templates fährt, oder in der URL wenn man die Vorlage bearbeitet):

cc237948-0c1d-4ee8-8450-c03b73fc6c38.png

Und die Checklistenvorlage die ID 1.

Mit diesem Wissen ist es kein Problem mehr, den GenericAgent-Job einzurichten. Wir reagieren auf die Änderung des Dynamischen Feldes:

c07e4a77-69e0-4fd7-af4f-4f4019107e91.png

Und wir wollen nur die Checkliste anhängen, wenn das Ticket auf dem Template mit der ID 18 basiert. Dazu muss das passende Dynamische Feld als Filter ausgewählt werden:

588c6fa4-4e4d-442c-b986-37a0518c9007.png

Das ist also unser Ticket-Filter:

1aac6902-954a-4eb8-964a-b96318b25633.png

Das Anhängen der Checkliste funktioniert über das Custom-Modul Kernel::System::GenericAgent::AddChecklistToTicket für den GenericAgent. Das bekommt noch die ID der Checklistenvorlage und die UserID 1 übergeben:

16a021ff-07f4-4498-9047-71750fc5211e.png

Das war's. Wenn wir jetzt ein Ticket erstellen, das Template auswählen und speichern, hängt die Checkliste an diesem Ticket.

Permalink:

Neues zu TicketChecklist (August 2020)

10.08.2020 // Renée Bäcker

In letzter Zeit hat sich bei unserem Addon TicketChecklist einiges getan. Neben kleineren Bugfixes gibt es auch wieder neue Features, die ich gerne an dieser Stelle vorstellen möchte. Die neuen Features sind:

  • Sichtbarkeit von Checklisten im Kundenportal
  • Checklisten-Status in Abhängigkeit der Queue
  • Statistik über Checklisten-Status

Sichtbarkeit von Checklisten im Kundenportal

Bei diesem Feature geht es darum, dass man Kunden/Kundinnen den aktuellen Stand der Bearbeitung mitteilen möchte. Ein Kunde schickt vielleicht ein Gerät zur Reparatur und über die Checkliste werden die einzelnen Schritte bestimmt.

Der Agent/die Agentin kann z.B. über eine Vorlage eine Checkliste erstellen und dann für jede Checkliste individuell bestimmen, ob diese Checkliste für den Kunden sichtbar sein soll:

Checkliste für Kundenportal aktivieren

Meldet sich der Kunde/die Kundin am Kundenportal an und öffnet das Ticket, sieht er/sie sofort den aktuellen Stand der Checkliste:

Checkliste im Kundenportal

Dieses Feature muss über die Systemkonfiguration im Parameter TicketChecklist::Feature::CustomerVisibility aktiviert werden.

Checklisten-Status in Abhängigkeit der Queue

Benutzen viele Abteilungen das OTRS und es gibt viele Checklisten für die unterschiedlichsten Zwecke, ist es nicht so selten, dass viele Checklisten-Status eingerichtet werden müssen.

Damit die Auswahlbox beim Erstellen der Checkliste und im Checklisten-Widget in der Ticketansicht nicht zu lang wird, können die Checklisten-Status Queues zugeordnet werden. Wird keine Queue angegeben, ist der Status in allen Queues verfügbar.

Checklisten-Status für bestimmte Queues aktivieren

... dann steht der Status in manchen Queues zur Verfügung

... in anderen nicht

Statistik über Checklisten-Status

Wie viele offenen Punkte haben wir denn in unseren Checklisten pro Queue? Diese Frage kann jetzt in einer Statistik beantwortet werden. Dafür wurde das Modul TicketAccumulationChecklistState geschrieben. Bei der Erstellung einer Statistik können Sie einfach eine Statistik vom Typ Dynamische Matrix wählen und dann das genannte Modul bei Objekttyp auswählen.

*TicketAccumulationChecklistState* als Objekttyp einer Statistik

Der Rest funktioniert dann genauso wie bei anderen Statistiken des gleichen Typs. Nur, dass Sie jetzt auch Checklisten-Status auswählen können, hier z.B. für die x-Achse:

... dann kann man Checklisten-Status als "Filter" wählen

Die daraus resultierende PDF-Datei sieht dann z.B. so aus:

... und bekommt dann das passende Resultat

Permalink:

Neue Features in TicketChecklist

18.11.2018 // Renée Bäcker

Es ist schon eine Zeitlang her seit unserem letzten Blogpost über Features in dem Addon. In der Zwischenzeitt haben wir wieder einiges an TicketChecklist geändert. Hier ein Überblick:

Der erste Schwung an Änderungen betrifft die Bedingungen und Aktionen.

Drag'n'Drop bei Aktionen (Vorlagen)

Die Reihenfolge von Aktionen lässt sich per Drag'n'Drop verschieben. Damit kann man die Reihenfolge der Abarbeitung beeinflussen.

Drag'n'Drop bei Aktionen

Neues Aktionsmodul (Vorlagen)

Bisher konnte man nur eine Aufgabe verändern oder ein Dynamisches Feld am Ticket setzen. Jetzt gibt es ein neues Aktionsmodul, mit dem sich verschiedene Eigenschaften des Tickets verändern lassen (z.B. Queue, Besitzer, Status, Priorität, ...).

Neues Aktionsmodul

Dynamische Werte für Aktionen (Vorlagen)

Bisher war es nur möglich feste Werte bei dynamischen Feldern zu setzen. Neben dem neuen Aktionsmodul können die Inhalte auch dynamisch sein. Es gibt folgende Platzhaltergruppen:

  • <OTRS_TICKET_...> - Informationen zum Ticket, zu dem die Aufgabe gehört
  • <OTRS_CHECKLISTITEM_...> - Informationen zu der Aufgabe selbst
  • <OTRS_CURRENT_...> - Infos zum Agenten der die Aktion anstößt

Dynamische Werte

Verwendung von Ticketnummer statt Ticket ID

Bei einige OTRS-Installationen wird in Links die Ticketnummer statt der Ticket ID verwendet, so dass die Links z.B. http://test.example/otrs/index.pl?Action=AgentTicketZoom&TicketNumber=20181115123 sind. Das führte bisher dazu, dass die Checkliste nicht in der Ticketansicht angezeigt wurde. Das ist jetzt gefixt.

Anzeige versteckter Aufgaben

Gerade bei längeren Checklisten, kann es nützlich sein, dass man Aufgaben verstecken kann. Es gibt die SysConfig-Einstellung TicketChecklist::HiddenStates, über die man das erreichen kann. Einfach die Checklisten-Status eintragen, die im Widget in der Ticketansicht mehr auftauchen sollen.

Bisher konnten Agenten die Aufgaben aber nur sehen wenn sie den Checklistendialog geöffnet haben. Jetzt gibt es einen Link

Checkliste hat versteckte Aufgaben

über den man auch die versteckten Aufgaben anzeigen kann:

Widget mit allen Aufgaben

Warnung bei Versuch einen Status zu löschen, der noch verwendet wird.

Wird ein Status noch verwendet und ein Admin versucht den Status zu löschen passiert nichts. Für den Admin ist aber auch nicht ersichtlich, warum man keine Änderungen sieht. Aus diesem Grund wurde ein Hinweis eingefügt, der in so einem Fall erscheint:

Warnung

Verknüpfung von Aufgaben mit Tickets

Man kann Tickets zwar über das normale Verknüpfen miteinander verbinden. Es gibt aber auch die Möglichkeit, Tickets über die Aufgaben miteinander zu verbinden. Damit kann man für größere Aufgaben ein Hauptticket erstellen mit einer Checkliste, bei der jede Aufgabe mit einem anderen Ticket verknüpft ist.

Dieses Verhalten muss man in der SysConfig über die Option TicketChecklist::AllowTicketsAsItems aktiviert werden.

Im Checklistendialog kann man dann einfach die Nummer des zu verknüpfenden Tickets eingeben:

Checklistendialog

Beim Speichern der Checkliste werden folgende Informationen aus dem Ticket an der Aufgabe gespeichert:

  • Besitzer des Ticket → Verantwortlicher der Aufgabe
  • Priorität des Tickets → Priorität der Aufgabe
  • Titel des Tickets → Kommentar der Aufgabe

Checkliste mit Ticket als Aufgabe

Ist die Option TicketChecklist::LinkTickets aktiv, werden die beiden Tickets auch verknüpft.

Wird jetzt der Status der Aufgabe geändert, überträgt sich das auf das Ticket - und umgekehrt.

Unterschiedliche Themes

Seit der ersten Version des Addons hat sich auch im Checklisten-Dialog einiges getan. Einige zusätzliche Infos die man an einer Aufgabe speichern kann, sind dazugekommen. Damit wurde ein untergeordnetes Panel eingerichtet, über das die Informationen gepflegt werden können.

Checklisten-Dialog im Standard-Theme

Mittlerweile gibt es ein Theme Slim, das in der Option TicketChecklist::Theme eingestellt werden kann. Damit werden einige Informationen wieder - wie es früher einmal war - aus dem untergeordneten Panel in die Übersicht gepackt:

Checklisten-Dialog im Slim-Theme

Haben wir Ihr Interesse an TicketChecklist geweckt? Dann nehmen Sie doch einfach Kontakt zu uns auf oder fordern Sie gleich Ihr Demosystem an.

Permalink:

OTRS6: Checkliste positionieren

19.02.2018 // Renée Bäcker

In OTRS 6 wurde die Ticketansicht komplett überarbeitet. Für das Checklisten-Modul muss nun kein schwerfälliger Ausgabefilter mehr verwendet werden, vielmehr werden die zusätzlichen Widgets (wie auch die Kundeninformationen) über Plugins realisiert. Diese haben den Vorteil, dass sie auch asynchron nachgeladen werden können - was einen nicht unerheblichen Geschwindigkeitsvorteil z.B. bei dem Attachment-Modul bringt.

Ein kleiner Nachteil ist, dass man nicht mehr ganz so flexibel bei der Positionierung ist. In OTRS5 gab es bei dem Checklisten-Modul noch die Config-Option TicketChecklist::Position mit der die komplexe Ansicht direkt unter dem Artikelbaum angezeigt werden konnte.

Unter OTRS6 muss man in der SysConfig eine kleine Anpassung machen:

In der Option Ticket::Frontend::AgentTicketZoom###Widgets###002-TicketChecklist muss der Wert von Location auf Main gestellt werden. Das sorgt dafür, dass die Checkliste in dem großen Hauptbereich angezeigt wird.

Weiterhin muss über das + ein neuer Eintrag hinzugefügt werden. Als Schlüssel wird Top eingetragen und als Wert 1. Das weist das Addon an, die Checkliste unter den Artikelbaum zu verschieben.

So sieht die Option dann aus:

Permalink:

TicketChecklisten per GenericAgent erstellen

08.07.2017 // Renée Bäcker

Hat man seine Checklisten als Vorlagen vorbereitet, kann man diese mit dem GenericAgent an Tickets hängen. Das kann man in den unterschiedlichsten Situationen nutzen: Eine Checkliste für Rechenzentrumsrundgänge? Dann einfach die Checkliste an das Ticket hängen wenn es in der Queue RZ::Rundgang erstellt wird. Eine Checkliste die abgearbeitet werden muss wenn ein neuer Mitarbeiter anfängt? Dann die Checkliste an das Ticket hängen wenn es in der Queue HR::Inbound erstellt wird.

Aber nicht nur an Hand der Queue kann man eine Checkliste an ein Ticket hängen. Man kann alle Möglichkeiten des GenericAgent nutzen. So könnte man eine Checklisten-Vorlage erstellen, die bei bestimmten Services gelten soll:

Beispielcheckliste

Als nächstes muss der GenericAgent eingerichtet werden. Als auslösendes Ereignis nehmen wir TicketCreate und TicketServiceUpdate. Damit erfassen wir alle Fälle in denen der Service eines Tickets gesetzt wird.

Events, die den GenericAgent triggern

Natürlich wollen wir die Checkliste nicht bei allen Tickets, die irgendeinen Service haben, sondern nur bei einem bestimmten Service. Im Ticketfilter wählen wir genau diesen Service aus.

Ticketfilter: Service

Zum Schluss noch das Wichtigste: Die Checkliste erstellen. Dazu muss ein benutzerdefiniertes Kommando ausgeführt werden und TicketChecklist liefert dieses Kommando mit: Kernel::System::GenericAgent::AddChecklistToTicket . Als Parameter erwartet das Kommando zum Einen die UserID des Benutzers - der Einfachheit halber wird hier immer die UserID 1 genommen. Und zum Anderen wird die ID der Checklisten-Vorlage benötigt. Diese bekommt man in der Übersicht der Checklisten-Vorlagen: Einfach mit der Maus über den Link fahren und die ID raussuchen.

Kommando erstellt Liste

Haben wir Ihr Interesse an TicketChecklist geweckt? Dann nehmen Sie doch einfach Kontakt zu uns auf oder fordern Sie gleich Ihr Demosystem an.

Haben Sie noch weitere Ideen und Wünsche? Dann schreiben Sie uns bitte

Permalink:

TicketChecklist: Schließen des Tickets verhindern

20.04.2017 // Renée Bäcker

Eine häufiger gestellte Frage ist, wie man verhindern kann dass ein Agent ein Ticket schließt solange noch mindestens eine Aufgabe aus der Checkliste noch offen ist. Hier kann man sich die Ticket-ACLs zu Nutze machen. Immer wenn eine Aufgabe zur Checkliste hinzugefügt wird oder der Status einer bestehenden Aufgabe geändert wird, wird geprüft ob alle Punkte schon abgearbeitet sind oder nicht. Ist das nicht der Fall, wird das Dynamische Feld TicketHasOpenTodos auf den Wert 1 gesetzt.

Auf diesen Wert kann man in der ACL prüfen. Die Prüfung lautet: ist der Wert des Dynamischen TicketHasOpenTodos gleich 1, dann darf das Ticket nicht geschlossen werden. In der ACL sieht das dann wie folgt aus:

Bei den Wertänderungen muss man ausschließen, dass der Agent den Schließen-Dialog aufruft und die geschlossen-Status sollen in allen anderen Dialogen ausgeschlossen werden:

Wie erkennt TicketChecklist bei eigenen Aufgaben-Status, ob die Aufgaben geschlossen sind oder nicht? Dazu gibt es eine SysConfig-Option die gepflegt werden muss:

Wenn keine Aufgabe einen dieser Status hat, sind alle Aufgaben geschlossen.

Nach dem Speichern der ACL das Deployen nicht vergessen. Sonst ist die ACL nicht aktiv. Und nicht mit dem Superuser (root@localhost) testen, denn da greifen keine ACLs.

Haben wir Ihr Interesse an TicketChecklist geweckt? Dann nehmen Sie doch einfach Kontakt zu uns auf oder fordern Sie gleich Ihr Demosystem an.

Haben Sie noch weitere Ideen und Wünsche? Dann schreiben Sie uns bitte.

Permalink:

Conditions and Actions für TicketChecklist - und noch mehr

16.12.2016 // Renée Bäcker

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:

Aufgaben des Tickets

Als erstes werden die Aufgaben mit ihren Verantwortlichen erstellt:

Aufgaben

Danach werden die Conditions und Actions gepflegt. Zuerst definieren wir die Statusänderungen anderer Aufgaben:

Bedingungen und Aktionen

Hier wird immer nur eine andere Aufgabe geändert. Es ist aber auch möglich mehrere Aufgaben zu ändern:

Aktionen auf mehrere Aufgaben

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:

Dynamisches Feld setzen

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:

Stammdaten GenericAgent

Als Filter wird der neue Wert des Dynamischen Feldes genommen

Ticketfilter

und anschließend das Ticket verschoben

Aktion auf das Ticket

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.

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:

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