Blog

02.06.2020 // Renée Bäcker

Ganz viele Aufgaben kann ein Agent über die Konsole erledigen - vom Bereinigen der Caches über neu laden der Konfiguration bis hin zum Anlegen von Benutzern, Agenten oder Queues. Im Laufe der Zeit gab es bei Kundenprojekten immer wieder die Situation, dass wir schnell mal was erledigen wollten. In manchen Fällen gab es aber kein passendes Kommando.

Eine Sammlung einiger Kommandos ist die Erweiterung ConsoleTools. Diese Tools werden wir nach und nach erweitern. Aber welche Tools gibt es denn in der Erweiterung?

Admin::ITSM::ConfigItem::Add

Entstanden ist diese Kommando, weil wir für unsere Addons den Interessenten Demosysteme bereitstellen. Bei einigen brauchen wir ConfigurationItems (z.B. bei CINotifications), die wir dann mit einem Skript in das System laden.

    $ perl bin/otrs.Console.pl Admin::ITSM::ConfigItem::Add --class Software --name OTRS --incistate ... --deplstate ...

Admin::User::Search

Wie bei vielen anderen Kommandos auch, hat man die gleiche Funktionalität auch in der Weboberfläche, aber häufig geht es in der Konsole einfach schneller.

Mit diesem Kommando kann man Agenten suchen:

    $ perl bin/otrs.Console.pl Admin::User::Search --term root*

Maint::NotificationEvent::Dump

Sie brauchen schnell die Informationen über eine Ticketbenachrichtigung? Dann hilft dieses Kommando weiter.

$ perl bin/otrs.Console.pl Maint::NotificationEvent::Dump --id 1
Print dump of all event based notifications...
$VAR1 = [
  {
    'ChangeBy' => '1',
    'ChangeTime' => '2017-11-26 08:09:58',
    'Comment' => '',
    'CreateBy' => '1',
    'CreateTime' => '2017-11-26 08:09:58',
    'Data' => {
      'AgentEnabledByDefault' => [
        'Email'
      ],
      'Events' => [
        'NotificationNewTicket'
      ],
      'Recipients' => [
        'AgentMyQueues',
        'AgentMyServices'
      ],
      'SendOnOutOfOffice' => [
        '1'
      ],
      'Transports' => [
        'Email'
      ],
      'VisibleForAgent' => [
        '1'
      ],
      'VisibleForAgentTooltip' => [
        'You will receive a notification each time a new ticket is created in one of your "My Queues" or "My Services".'
      ]
    },
    'ID' => '1',
    'Message' => {
      'de' => {
        'Body' => 'Hallo ....'
      }
    },
  }
]

Maint::Ticket::CheckFlag

Warum auch immer, gab es in einem Kundensystem das Problem, dass für einige User die Tickets als gelesen markiert waren, aber nicht alle Artikel des Tickets. Das führte zu dem Problem, dass - wenn der Agent/die Agentin den letzten ungelesenen Artikel liest - nochmal versucht wird das gesamte Ticket als gelesen zu markieren.

Das liefert dann Fehlermeldungen in den Logs.

Mit diesem Kommando kann man rausfinden, für welche Agenten dieses Problem besteht und man kann das auch gleich fixen lassen:

$ perl bin/otrs.Console.pl Maint::Ticket::CheckFlag --fix-flag
Check 'Seen' flag for all users and all tickets...
Checks for User root@localhost
Ok for user root@localhost.
Checks for User ao
Ok for user ao.
Checks for User at
Ticket 23 marked as seen, but not all articles are marked as seen
Checks for User ta
Ok for user ta.
Checks for User aa
Ok for user aa.
Checks for User hm
Ok for user hm.
Checks for User hu
Ok for user hu.
Checks for User kit
Ok for user kit.
Done.

Maint::Ticket::Info

Gerade bei der Entwicklung und dem Testen von GenericAgent-Jobs kann das sehr nützlich sein. Dann kann man den GenericAgent auslösen und man muss nicht im Browser das Ticket neu laden um Änderungen zu sehen.

Oder wenn sich ein Agent beschwert, dass er/sie das Ticket nicht sehen kann.

Das Kommando gibt nur ein paar Basisinformationen aus, was aber in vielen Fällen schon ausreicht.

Beispielausgabe:

$ perl bin/otrs.Console.pl Maint::Ticket::Info --id 1
Infos about a ticket...
TicketID: 1
Ticket#: 2015071510123456
Title: Welcome to OTRS!
State: open
Owner: root@localhost
Priority: 3 normal
Queue: Raw
Done.

Admin::DynamicField::CheckBackends

... ist das neueste Kommando in der Sammlung. Nach einem Upgrade wenn noch nicht alle Erweiterungen aktualisiert wurden kann es sein, dass die Backends nicht bereitstehen. Das führt dann zu Fehlern. Mit diesem Befehl wird einfach geprüft, ob die notwendigen Backends - die auch genutzt werden - existieren.

Sie haben noch Fragen? Dann nehmen Sie doch einfach Kontakt zu uns auf.

Permalink: /2020-06-02-opar-console-tools

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:

• Verwendung von Ticketnummer statt Ticket ID möglich
• Verknüpfung von Aufgaben mit Tickets
• Unterschiedliche Themes
• Anzeige versteckter Aufgaben
• Warnung bei Versuch einen Status zu löschen, der noch verwendet wird.
• Drag'n'Drop bei Aktionen (Vorlagen)
• Neues Aktionsmodul (Vorlagen)
• Dynamische Werte für Aktionen (Vorlagen)

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.

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, ...).

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

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

über den man auch die versteckten Aufgaben anzeigen kann:

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:

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:

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

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.

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:

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

Permalink: /2018-11-18-checklist-neue-features

17.11.2018 // Renée Bäcker

Wie kann ich eigentlich steuern, welcher Agent welche Menüpunkte im Ticket sieht? Einen Weg habe ich habe ich schon in einem Blogpost Mitte 2016 gezeigt.

Mit dem Recht phone muss ich dann aber aufpassen, welchen Agenten ich rw-Rechte etc. gebe, weil dann das phone-Recht mit eingeschlossen ist.

Jetzt möchte ich einen weiteren Weg zeigen, so dass erstmal für alle Agenten das Verfassen von Artikeln über ausgehender Telefonanruf verboten ist. Als Admin soll man ganz einfach über die Zuweisung einer Rolle bestimmen können, wer solche Artikel verfassen kann.

Einrichten der Zugriffsberechtigung

Als erstes muss eine Gruppe angelegt werden, über die die Zugriffsberechtigung gesteuert werden soll. Für das Beispiel wird die Gruppe can_phone angelegt.

Im zweiten Schritt wird in der SysConfig festgelegt, welche Gruppe Ausgehende Telefonarufe tätigen kann. Dazu wird bei der Option Ticket::Frontend::MenuModule###425-Phone Call Outbound der Schlüssel Group hinzugefügt mit dem Wert rw:, wobei durch den Gruppennamen ersetzt werden muss. In diesem Beispiel can_phone. Das rw bedeutet, dass nur Agenten, die read/write-Rechte auf dieser Gruppe haben, diesen Menüpunkt sehen.

Anschließend wird die Rolle definiert, die später den enzelnen Agenten zugewiesen wird. Ja, man kann den Agenten auch einzeln die Gruppe zuweisen, aber die Verwendung von Rollen bringt viele Vorteile im Berechtigungskonzept.

Wir definieren die Rolle CanPhone und jeder Agent, der diese Rolle hat, darf dann Ausgehende Telefonanrufe tätigen.

In der SysConfig wurde festgelegt, dass Agenten bei der Gruppe can_phone rw-Rechte brauchen. Deshalb muss genau das für die Rolle festgelegt werden.

Ein Beispiel

Eine eigene Testqueue wird erstellt und eine Gruppe um den Personenkreis für diese Queue zu beschränken. Die Rolle CanPhone haben wir oben schon erläutert. Außerdem gibt es eine Rolle TestRolle, über die der Zugriff auf die Queue gesteuert wird.

Um den Effekt zu demonstrieren, werden zwei Agenten angelegt Frontoffice Agent und Backoffice Agent. Die Person im Frontoffice darf auch telefonieren, die Person im Backoffice nicht.

Abschließend noch getestet, ob es funktioniert. Als Frontoffice Agent sieht man den Menüpunkt Ausgehender Telefonanruf...

... als Backoffice Agent nicht.

Welcher der gezeigten Wege (der frühere Blogpost und der Heutige) der richtige/bessere ist, muss man sich überlegen. Es gibt für beide Wege Einsatzszenarien.

Haben Sie noch Fragen? Dann nehmen Sie doch einfach Kontakt zu uns auf.

Permalink: /2018-11-17-menuepunkte-ueber-rollen-steuern

01.06.2018 // Renée Bäcker

Ich habe es jetzt schon mehrfach gesehen, dass nach einem Update auf OTRS 6 das Systemprotokoll mit der Meldung Need GroupName geflutet wird. Wenn man sich den Stacktrace dazu anschaut, dann sieht man folgendes:

Message: Need GroupName!
 
RemoteAddress: 10.70.0.5
RequestURI: /otrs/index.pl?Action=Admin
 
Traceback (6278):
   Module: Kernel::System::Group::PermissionCheck Line: 945
   Module: Kernel::Output::HTML::NavBar::ModuleAdmin::Run Line: 76
   Module: Kernel::Output::HTML::Layout::NavigationBar Line: 3225
   Module: Kernel::Modules::Admin::Run Line: 35
   Module: Kernel::System::Web::InterfaceAgent::Run Line: 1116
   Module: ModPerl::ROOT::ModPerl::Registry::opt_otrs_bin_cgi_2dbin_index_2epl::handler Line: 40
   Module: (eval) (v1.99) Line: 207
   Module: ModPerl::RegistryCooker::run (v1.99) Line: 207
   Module: ModPerl::RegistryCooker::default_handler (v1.99) Line: 173
   Module: ModPerl::Registry::handler (v1.99) Line: 32

Es hat ein wenig gedauert, bis ich das mit manuellen Änderungen in der SysConfig nachstellen konnte. Jetzt habe ich ein kleines Skript geschrieben, mit dem sich die Schuldigen ausfindig machen lassen:

Auf der Kommandozeile sollte dann nach der Ausführung des Skripts so etwas stehen:

Permalink: /2018-06-01-Need-GroupName-nach-otrs6-update

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: /2018-02-19-otrs6-checkliste-positionieren

14.02.2018 // Renée Bäcker

Mit der JiraPackage-Erweiterung von catworkx ist es möglich, OTRS-Tickets nach Jira zu übertragen und umgekehrt. Über die grundsätzlichen Funktionen haben ich schon vor einiger Zeit gebloggt.

Heute zeige ich, wie man das Feldmapping so erweitern kann, dass Werte dynamisch berechnet werden. Als Beispiel soll es ein Feld Genehmigt am in Jira geben, in dem gespeichert wird, wann ein Feature freigegeben wurde. Aus OTRS heraus soll dieses Feld mit dem aktuellen Datum gefüllt werden.

Schritt 1: Erstellen des Benutzerdefinierten Feldes

Es wird ein Datumsfeld verwendet, die Uhrzeit soll hier keine Rolle spielen.

Noch beschreiben was in dem Feld gespeichert wird ...

... und für die entprechenden Seiten aktivieren.

Schritt 2: Erstellen des Perl-Moduls

Für dieses Beispiel reicht ein kleines Perl-Modul, das nur die Subroutine Today zur Verfügung stellt.

Hier benötigt die Subroutine keine Übergabeparameter. Vom Hauptmodul werden aber folgende Parameter übergeben:

• Objekt von Kernel::System::TicketJira
• Das Mapping
• Artikelinformationen

Damit kann alles gemacht werden was man möchte.

Es ist natürlich von Vorteil, wenn man die API der OTRS-Klassen kennt. Denn dann kann man Informationen zu verknüpften Objekten (z.B. Tickets, FAQ, Config Items, ...) zu dem Ticket herausfinden oder einfach die Hilfsfunktionen aus verschiedenen Klassen nutzen. Man kann aber auch andere Perl-Module nutzen oder andere Programme aufrufen. Was in der Subroutine gemacht wird ist im Prinzip egal - man muss nur darauf achten, welches Format Jira haben möchte.

Im Fall von Datumsfeldern muss das Datum in dem Format YYYY-MM-ddThh::mm::ss.0+Offset angegeben werden. Bei anderen Feldern müsste man eine Hashreferenz zurückgeben. Da hilft dann aber auch die Fehlermeldung weiter, die Jira zurückliefert wenn man testweise ein Ticket von OTRS nach Jira überträgt.

Schritt 3: Anpassen des Feldmappings

Im Schlüssel ist das zu finden, was auf OTRS-Seite passieren soll: call:Kernel::System::JiraMapping,Today

Der Aufbau ist call:<Modul>,<Funktion>.

call ist das Schlüsselwort, dass eine Funktion aus einem Modul aufgerufen werden soll. Das Kernel::System::JiraMappingist der Paketname des Moduls und Today ist der Funktionsname.

Das war's.

Wenn jetzt das Ticket aus OTRS heraus an Jira übertragen wird, wird der Inhalt für das Benutzerdefinierte Feld berechnet:

Sollten Sie noch Fragen zu dem Modul haben, nehmen Sie am besten Kontakt zu catworkx auf.

Permalink: /2018-02-14-jirapackage-function-call

13.02.2018 // Renée Bäcker

Wenn Sie vor einem Upgrade auf OTRS6 stehen und die kostenlose Erweiterung QuickClose einsetzen, dann sollten Sie vor dem Update folgenden Befehl ausführen:

Ansonsten kommt eine Fehlermeldung bei der Nachbearbeitung der Artikel-Tabellen:

Cannot delete or update a parent row: a foreign key constraint fails

Permalink: /2018-02-13-upgrade-otrs6-quick-close

09.02.2018 // Renée Bäcker

Vor knapp zwei Jahren habe ich das Vorgehen schonmal beschrieben, mittlerweile ist aber OTRS 6 erschienen und es haben sich ein paar Änderungen ergeben.

Als erstes wird die Erweiterung TicketOverviewHooked benötigt.

Danach folgende Dateien anlegen:

Kernel/Config/Files/XML/OwnerHook.xml
(unter OTRS5 sah die Datei etwas anders aus und wurde an einem anderen Ort gespeichert)

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: /2018-02-09-overview-hook-in-otrs6

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

28.12.2017 // Renée Bäcker

Wenn Code während der Installation von Addons ausgeführt werden soll, dann schreibt man in der Regel ein Perl-Modul. Ein Beispiel ist ArticleNotes mit seinem var/packagesetup/ArticleNotes.pm. In diesen Perl-Modulen kann man alles mögliche machen, von der Erstellung Dynamischer Felder bis hin zu Änderungen an der Datenbank.

Es gibt auch Tools, die bei der Entwicklung helfen. Leider kann es vorkommen, dass bei einem Fehler in dem Perl-Modul keine ordentliche Fehlermeldung kommt. In so einem Fall kann man einfach folgenden Perl-Code auf der Kommandozeile ausführen und man bekommt deutlich mehr Infos:

    #!/usr/bin/perl
    
    use Kernel::System::ObjectManager;
    
    $Kernel::OM = Kernel::System::ObjectManager->new;
    $Kernel::OM->Get('var::packagesetup::ArticleNotes')->CodeInstall();

Und dann einfach $ cd /opt/otrs && perl -IKernel/cpan-lib script.pl.

Permalink: /2017-12-28-entwickler-hinweis-packagesetup

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