Blog

29.12.2021 // Renée Bäcker

In der ((OTRS)) Community Edition und in Znuny können im Prozesse im Kundeninterface über Aktivitätsdialoge gestartet werden, die im Prozessmanagement auch für den Kundenbereich freigegeben sind. Sobald das der Fall ist, bekommt der Kundenbenutzer einen neuen Menüeintrag zu sehen, über den ein Dialog erreichbar ist. In diesem Dialog wird dann der Prozess ausgewählt, der gestartet werden soll.

In OTOBO ist das anders. Die Kundenbenutzer sollen im Kundenbereich nur einen einzigen Einstiegspunkt haben, über den Tickets erstellt werden können (Tickets per Mail oder über eine Schnittstelle bleiben unberührt).

Für Administratoren ist das eine Umstellung, da die Aktivitätsdialoge für den Prozesseinstieg über andere Mechanismen dargestellt werden müssen. In OTOBO können Access Control Lists (ACLs) nicht nur Werte in Dropdowns einschränken (siehe https://doc.otobo.de/manual/admin/10.1/en/content/processes-automation/access-control-lists.html, sondern auch Formularfelder ausblenden.

Nehmen wir an, dass Kundenbenutzer über das Portal verschiedene Zugänge (z.B. Mailaccount, Gitlab-Account, ...) beantragen können. Weiterhin können in einem Prozess Demosysteme angefordert und anschließend Erweiterungen bestellt werden können:

Nachdem ein Demosystem beantragt wurde, muss es erstellt werden, der Kundenbenutzer muss die URL zugeschickt bekommen und nach einer gewissen Zeit muss der Kundenbenutzer an das Demosystem erinnert werden.

Der Kundenbenutzer soll im Kundenbereich den Zeitraum der Demo verlängern können und/oder die Erweiterung(en) bestellen können. Die entsprechenden Aktivitätsdialoge sind dann bei der Aktivität Entscheidung angesiedelt:

Je nachdem welcher Prozess gestartet wird, sollen unterschiedliche Felder zu sehen sein. Für den Demosystem-Prozess muss der Kundenbenutzer erstmal auswählen, dass ein Demosystem gewünscht ist (das wird über Tickettypen gesteuert):

Wird Demosystem anfordern ausgewählt, sollen folgende (Dynamischen) Felder eingeblendet werden:

• System (Znuny oder OTOBO)
• Znuny-Erweiterung oder OTOBO-Erweiterung (je nachdem, was als System ausgewählt wurde)

Die Dynamischen Felder für die Prozesse müssen für die Ansicht CustomerTicketMessage eingeblendet werden:

Damit sieht der Dialog für neue Tickets im Kundenbereich so aus:

Da die Felder aber nur für die Prozesse benötigt werden, müssen sie erstmal wieder ausgeblendet werden. Das stellen wir über ACLs dar:

Auf den Dialognamen kommt man, wenn man in die URL schaut, unter der Kundenbenutzer Tickets erstellen können:

Je nach ausgewähltem Tickettypen wird das System-Feld und das Dropdown mit den Erweiterungen eingeblendet:

Sollte FormStd bei den ACLs nicht zur Verfügung stehen, kann das über die Systemkonfiguration hinzugefügt werden

Eine Hilfe, was in den ACLs bei Form etc. eingetragen werden kann, ist unter https://doc.otobo.org/manual/admin/10.1/en/content/processes-automation/access-control-lists.html?#acl-reference zu finden.

Hat der Kundenbenutzer alles ausgewählt und das Ticket wird erstellt, muss es dem Prozess zugeordnet werden. Das wird über einen GenericAgent erledigt. Immer dann wenn ein Ticket erstellt wird und der Tickettyp Demosystem-Anforderung ist, muss das Dynamische Feld ProcessManagementProcessID auf die Prozess-ID und das Feld ProcessManagementActivityID auf die Aktivitäts-ID gesetzt werden.

(Für den Screenshot wurden für die Übersichtlichkeit einige Felder entfernt).

Die konkreten Prozess- und Aktivitäten-IDs müssen Sie im Prozessmanagement auslesen.

Der Agent soll jetzt einen Dialog bekommen, um die URL etc. eintragen zu können. Und der Kundenbenutzer soll die Demo verlängern und/oder die Erweiterung(en) bestellen können. Das sind dann wieder Aktivitätsdialoge wie man sie aus dem Standard-Prozessmanagement kennt.

Diese Dialoge sind dann im Kundenbereich über die Ticketansicht erreichbar:

Wenn Sie diesen Prozess einmal selbst nachstellen wollen, können Sie die notwendigen Dateien unter https://os.perl-services.de/perl-academy/otobo-kundenbenutzer-prozess herunterladen. Nur den GenericAgent und den Tickettypen müssen Sie händisch übernehmen.

Sollten Sie Bedarf an einer Admin-Schulung haben, nehmen Sie einfach Kontakt mit uns auf.

Permalink: /2021-12-29-otobo-prozesse-im-kundeninterface-starten

02.02.2018 // Renée Bäcker

Im Otterhub-Forum, auf der Mailingliste und auch bei meinen Kunden tauchen immer wieder Fragen auf wie Wie kann ich denn den Abteilungsleiter informieren wenn x Tage nichts mehr am Ticket gemacht wurde oder Wie kann ich dem Kunden eine Nachricht schicken zwei Tage nachdem das Ticket geschlossen wurde. Mit einfacher Konfiguration ist das nicht lösbar, da das OTRS nicht hellsehen kann und es auch nicht für alles ein Event geben kann.

An dieser Stelle kommt dann aber das nützliche Trio ins Spiel. Mit dynamischen Feldern kann man alle möglichen Informationen am Ticket oder am einzelnen Artikel speichern. Standardmäßig gibt es ein paar Basistypen wie Textfeld, Dropdown, Checkbox und Datum. Aber auf OPAR gibt es noch weitere Typen (z.B. Agenten, JsonAPI, Integer, MultiCheckbox, ConfigItem, RemoteDB) und wir haben auch noch andere Erweiterungen im Angebot zur Erweiterung der Dynamischen Felder (z.B. Multipart, Icons, ChildTickets, Tags, ...).

Es macht auch nichts wenn man einige Dutzend Dynamische Felder erstellt hat. Wenn für ein Ticket/Artikel kein Wert existiert, gibt es da auch keinen Eintrag in der Datenbank. Und man muss ja auch nicht alle Dynamischen Felder in der Oberfläche anzeigen lassen.

Mit dem GenericAgent kann man wunderbar nach Tickets suchen und dann Informationen am Ticket speichern und/oder ändern. Man kann auch eigene Kommandos schreiben. Typische Aufgaben beim GenericAgent ist z.B. das Löschen von Spam-Mails, das Verschieben von Tickets, das Setzen einer neuen Priorität und so weiter.

Das dritte Puzzleteil in diesem Blogbeitrag sind die Ticketbenachrichtigungen. Seit OTRS5 ist das ziemlich mächtig, denn man kann auf Events reagieren, kann die Tickets noch genauer filtern und auch den Empfängerkreis kann man sehr genau bestimmen. Man kann E-Mails verschicken und in der Business Solution oder mit unserem Paket TicketSMSNotification können Sie auch SMS' verschicken.

Schauen wir uns die Fragestellungen nochmal genauer an: Der Abteilungsleiter soll eine Nachricht bekommen wenn das Ticket x Tage nicht mehr geändert wurde.

Der Abteilungsleiter soll jetzt eine bestimmte Person mit einer festen Mailadresse sein. Jetzt müssen wir überlegen wie wir die Benachrichtigung auslösen können. Benachrichtigungen werden durch Ereignisse/Events ausgelöst. Es gibt aber kein Event das ausgelöst wird wenn ein Ticket x Tage nicht geändert wurde. Also müssen wir dafür sorgen, dass es genau ein solches Event gibt. Dazu müssen wir die Tickets suchen, auf die das Suchkriterium zuletzt vor mehr als x Tagen geändert zutrifft. Wir wollen aber nicht selbst suchen, sondern das soll regelmäßig und automatisch gemacht werden.

Und was eignet sich für eine solche Aufgabe? Genau, der GenericAgent. Ein GenericAgent-Job kann auf zwei Arten ausgeführt werden: Eventbasiert, also wenn sich am Ticket etwas ändert, oder auf Basis eines Kalenders. Die Eventbasierte Ausführung hat den Vorteil, dass etwas unmittelbar nach einer Änderung am Ticket gemacht werden kann. Das ist in unserem Fall aber nicht die Lösung. Wir brauchen die automatische Ausführung. Damit die Ticketbenachrichtigung ausgelöst wird, brauchen wir ein Event. Ein Event wird bei einer Änderung am Ticket ausgelöst. Also müssen wir irgendwas am Ticket verändern.

Da es aber die Information Das Ticket wurde jetzt seit x Tagen nicht mehr geändert standardmäßig nicht gibt, müssen wir am Ticket Platz für diese Information schaffen. Also brauchen wir ein Dynamisches Feld.

Fangen wir also damit an.

Ich nehme für solche Informationen ganz gerne ein Textfeld, da ich da sehr frei bin was ich da reinschreibe. Da es eine Information ist, die nur einmal am Ticket vorkommen kann, nehe ich als Objekt Ticket

Dann müssen die Stammdaten ausgefüllt werden. Der Name ist wichtig, die Beschriftung nicht - da wir das Feld nirgends anzeigen möchten.

Als nächstes müssen wir das Feld füllen wenn ein Ticket die x (hier: 25) Tage nicht geändert wurde. Dazu im Adminbereich einen neuen GenericAgent anlegen:

Da das regelmäßig ausgeführt werden soll, wählen wir alle Zeitpunkte - außer Samstag und Sonntag.

Da das nicht bei allen Tickets gefüllt werden soll, müssen wir die Tickets filtern. Die Information ist ja nur bei solchen Tickets interessant, die noch offen sind und eben die 25 Tage nicht geändert wurden. Genau das müssen wir beim Ticketfilter eintragen:

Anschließend speichern wir die Information am Ticket. Wir ändern den Inhalt des eben erstellten Dynamischen Feldes auf 1.

Damit haben wir jetzt dafür gesorgt, dass ein Event gefeuert wird wenn ein Ticket 25 Tage nicht bearbeitet wurde. Jetzt müssen wir noch was mit dem Event anfangen. Nun kommen also die Ticketbenachrichtigungen ins Spiel. Diese werden durch Events ausgelöst. Unser Event wird durch die Änderung des einen Dynamischen Feldes ausgelöst. Also müssen wir genau darauf reagieren:

Auch hier interessieren uns nicht alle Tickets, sondern nur die, bei denen der neue Wert des Dynamischen Feldes 1 ist.

Anschließend bestimmen wir noch den Empfänger der Nachricht. Das kann auf Gruppen oder Rollen basieren, auf bestimmten Eigenschaften wie Schreibrechte auf die Queue oder Besitzer des Tickets. Man kann aber auch einfach eine Mailadresse eingeben:

Abschließend müssen wir noch einen Text für die Benachrichtigung festlegen.

Und das war's. Über das Zusammenspiel dieser drei Komponenten kann man ganz viele nützliche Sachen umsetzen. Wenn Sie noch weitere Fragen haben, schreiben Sie uns doch bitte eine Nachricht.

Dadurch dass wir ein Textfeld genommen haben, können wir auch noch mehrere Eskalationen einbauen. Ein weiterer GenericAgent könnte z.B. prüfen, ob das Ticket mehr als 50 Tage nicht angefasst wurde und dann das Dynamische Feld auf 2 setzen. Eine weitere Ticketbenachrichtigung für das gleiche Event aber nur die Tickets nimmt, bei denen der neue Wert 2 ist, könnte eine Nachricht an andere Personen schicken.

Permalink: /2018-02-02-dynamicfields-genericagent-ticketnotifications

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:

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.

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.

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.

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: /2017-07-08-ticketchecklist-genericagent

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

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