Blog

AlternateQueueSender: Erste Mail bestimmt den Absender

22.01.2021 // Renée Bäcker

In der Standardinstallation der Ticketsysteme ( ((OTRS)) Community Edition, Znuny, OTOBO, ...) wird bei der Einrichtung einer Queue auch die Absenderadresse festgelegt:

e18d0077-5dd0-4253-98ef-3d31e34e4128.png

Bei einem Kunden gibt es für jedes Projekt eine eigene Mailadresse, so dass die Kommunikation leicht in die richtigen Wege geleitet werden kann. Diese Projektspezifische Mailadresse soll durchgehend bei der Beantwortung von Fragen genutzt werden - auch wenn das Ticket verschoben wird.

Diese Anforderung lässt sich leicht mit AlternatQueueSender umsetzen. Die Mailadressen werden als Systemadressen definiert und im Adminbereich werden diese Mailadressen als alternative Absendeadressen für die Queue festgelegt:

639f3795-3f4e-4ca4-8372-f7fd943802dc.png

Jetzt ist die Anforderung, dass die Mailadresse an die der Endkunde schreibt auch in anderen Queues als Absendeadresse genutzt wird. Beispielsweise kommt eine Mail an dummy+forward@perl-services.de in das Ticketsystem. Aus der Mail erstellt das System ein Ticket in der Queue Junk. Für diese Queue ist diese Adresse aber weder bei den Queue-Einstellungen noch als alternative Absendeadresse eingetragen.

AlternateQueueSender ermöglicht die Umsetzung dieser Anforderung. Als erstes wird ein Dynamisches Feld vom Typ Text für Tickets benötigt. In diesem Beispiel heißt das Feld Project.

Darin wird die Empfängeradresse der Mail gespeichert. Für das Setzen des Dynamischen Feldes ist ein Postmaster-Filter zuständig:

4dcf7267-0cce-4811-9c8d-a59565259515.png

Der Reguläre Ausdruck bei der Filterbedingung speichert die Empängeradresse (in diesem Beispiel muss es eine Perl-Services.de-Adresse sein). Und das [***] setzt hier das Feld Project auf genau diese Mailadresse.

Im Adminbereich wird dieses Dynamische Feld bei den alternativen Absendeadressen in einem Template genutzt:

e6d72afd-b51f-487f-8376-3046754ad7fa.png

Um automatisch diese Mailadresse auszuwählen, muss der Haken bei Make Default Address gesetzt werden.

Zusammengefasst: Um die Empfängeradresse der eingehenden Mail über das ganze Ticketsystem hinweg als Absendeadresse nutzen zu können, braucht es drei Zutaten:

  1. Ein Dynamisches Feld in dem diese Adresse gespeichert wird
  2. Einen Postmaster-Filter der die Adresse im Dynamischen Feld speichert
  3. Eine alternative Absendeadresse für die jeweilige Queue, die dieses Dynamische Feld im Template nutzt

Permalink:

Vorstellung freies Modul "GenericDashboardStats"

09.07.2020 // Renée Bäcker

Ein Bild sagt mehr als tausend Worte. Das gleiche gilt für die Statistiken auf dem Dashboard in der ((OTRS)) Community Edition. Allerdings gibt es bei der 7-Tage-Statistik im Standard ein paar Probleme: Wie der Name schon sagt, zeigt es fest nur die Werte der letzten 7 Tage an. Und es gibt genau zwei fest eingestellte Kurven in der Statistik. Mit GenericDashboardStats lässt sich das ändern. Zum einen kann man die Anzahl der betrachteten Tage verändern als auch die angezeigten Kurven.

Nach der Installation des Moduls gibt es ein paar zusätzliche Konfigurationseinstellungen. Die wichtigste Einstellung des Moduls ist die Aktivierung des Dashboard-Widgets:

SysConfig-Einstellung zur Aktivierung des Dashboardwidgets

Hier wiederum ist der Wert zum Schlüssel SysConfigBase entscheidend. Standardmäßig ist hier GenericDashboardStats eingetragen. Die Erweiterung sucht sich für die Darstellung alle Konfigurationsparameter zusammen, die mit eben diesem Wert anfangen.

Das sind z.B. diese hier:

Aber es gibt noch mehr Einstellungen in dem Konfigurationsparameter. Hier nur die wichtigsten kurz erklärt.

UseDate

Im Standard werden nur die Wochentage abgekürzt dargestellt, also z.B. Mo, Di und so weiter. Werden größere Zeiträume in der Statistik dargestellt, ist das mit dem Wochentag vielleicht nicht mehr ganz so praktisch. In diesem Fall kann man UseDate auf 1 setzen. Dann wird das Datum angezeigt.

DateFormat

Das komplette Datum ist aber vielleicht unnötig. Vielmehr könnte man nur am Tag und Monat interessiert sein. Dann kann man einfach %d.%m. eintragen. Die Platzhalter, die hier genutzt werden können, sind in der Dokumentation von strftime nachzulesen.

ReduceXTicks

Hat man viele Tage in der Statistik, kann es schnell unübersichtlich bei der Beschriftung der x-Achse werden. Sollen nur weniger Punkte angezeigt werden, kann man ReduceXTicks auf 1 setzen.

Block

Um eine bessere Übersichtlichkeit zu bekommen - gerade wenn man einen längeren Zeitraum in der Statistik betrachtet - kann man die Widgets auch von der rechten Seitenleiste in den Hauptteil verschieben. Dazu muss bei Block einfach ContentLarge eingetragen werden.

Eigene Kurven definieren

Das Addon kommt mit der Definition von zwei Beispiel-Kurven. Eine Kurve zeigt die Anzahl der erstellten Tickets an und die zweite die Anzahl der erstellten Tickets in der Queue Junk:

Das Standard-Widget und die generische Statistik

Um diese Widget zu erweitern - sprich zusätzliche Kurven hinzufügen - muss die Systemkonfiguration angepasst werden. Klingt schwieriger als es ist...

Einfach eine eigene Konfigurationsdatei in Kernel/Config/Files/XML/ anlegen. z.B. MyDashboardStats.xml.

Dort das Grundgerüst ablegen:

<?xml version="1.0" encoding="utf-8"?>
<otrs_config version="2.0" init="Application">
    <!-- Hier folgen die Settings-Blöcke -->
</otrs_config>

Steht dieses Grundgerüst, kann für jede Kurve mindestens ein Settingsblock angelegt werden. Als Beispiel dient eine Kurve, mit der ich erkennen kann, wie viele Demosysteme in den letzten 14 Tagen angefordert wurden.

<Setting Name="GenericDashboardStats###001-demos-created" Required="0" Valid="1">
    <Description Translatable="1">Demos</Description>
    <Navigation>Stats</Navigation>
    <Value>
        <Hash>
            <Item Key="OptionKey">DemosCreated</Item>
            <Item Key="type">TicketCreate</Item>
            <Item Key="label">Demosysteme</Item>
        </Hash>
    </Value>
</Setting>

Dieser definiert die Basisinformationen der Kurve:

type

Definiert, welches Zeitkriterium bei der Ticketsuche genutzt wird. In der Standard 7-Tage-Statistik wird z.B. die Ticketerstell- bzw. Ticketschließzeit genutzt. Folgende Zeitkriterien werden unterstützt:

  • TicketCreate - Zeitpunkt der Ticketerstellung
  • TicketClose - Zeitpunkt des Schließens eines Tickets
  • TicketChange - Zeitpunkt einer Änderung des Tickets
  • TicketEscalation - Zeitpunkt der Ticketeskalation

Weitere Kriterien sind auf OPAR aufgeführt.

label

Ist die Beschriftung der Kurve im Widget. Dieser Text wird übersetzt, sollte eine Übersetzung in der jeweiligen Sprache existieren. Wenn der nicht existiert, können Sie die Übersetzung erstellen.

color

Die Farbe, die die Kurve haben soll. Wenn nichts angegeben wird, wird eine Standardfarbe genommen.

Die Stärke dieses Addons liegt aber darin, dass nicht nur die Zeitpunkte für die Ticketsuche herangezogen werden kann, sondern beliebige Parameter aus der Ticket-Suche.

Um diese nutzen zu können muss in dem Settings-Block der Kurve ein OptionKey gesetzt werden. Zur Erinnerung: Wir wollen eine Kurve haben, bei der wir die Anzahl der angeforderten Demosysteme ablesen können. Uns interessieren also erstellte Tickets (deswegen TicketCreate bei der Option type) der letzten 14 Tage.

Es sind aber nicht alle erstellten Tickets in unserem OTRS. Sondern nur die in der Queue FeatureAddons::Demosystem. Aus diesem Grund müssen wir die Suche etwas verfeinern. Das geschieht in einem weiteren Settings-Block.

<Setting Name="DemosCreated###Queues" Required="0" Valid="1">
    <Description Translatable="1">Tickets for demo instances are in these queues</Description>
    <Navigation>DemosCreated</Navigation>
    <Value>
        <Array>
            <Item>FeatureAddons::Demosystem</Item>
        </Array>
    </Value>
</Setting>

Im Namen diese Einstellungen finden sich zwei Sachen wieder: Der oben definierte OptionKey (hier: DemosCreated), dann die drei # und anschließend der Suchparameter (hier: Queues). Da man laut Dokumentation mehrere Queues bei der Suche angeben kann, kommt hier ein Systemkonfigurationsparameter mit einem Array zum Einsatz.

Wäre das Suchkriterium eine ganz bestimmte Kundennummer, dann würde die Option so aussehen:

<Setting Name="DemosCreated###CustomerID" Required="0" Valid="1">
    <Description Translatable="1">Tickets for demo instances are in these queues</Description>
    <Navigation>DemosCreated</Navigation>
    <Value>
        <String Regex="">die_kundennummer</String>
    </Value>
</Setting>

Ist die Datei gespeichert, darf man nicht vergessen, die Konfiguration neu zu bauen:

perl bin/otrs.Console.pl Maint::Config::Rebuild

Eigene Statistik-Widgets erstellen

Irgendwann wird aber auch jede Statistik unübersichtlich. Wenn zu viele Kurven dargestellt werden, kann man nicht mehr erkennen, was was bedeutet. Dann wird es Zeit, die Kurven in verschiedene Widgets aufzuteilen.

Eigene Statistik-Widgets zu erstellen ist ziemlich einfach. Legen Sie einfach eine eigene Konfigurationsdatei in Kernel/Config/Files/XML/ an. z.B. MyDashboardStats.xml.

<?xml version="1.0" encoding="utf-8"?>
<otrs_config version="2.0" init="Application">
    <Setting Name="DashboardBackend###257-MyDashboardStats" Required="0" Valid="1">
        <Description Translatable="1">...</Description>
        <Navigation>Frontend::Agent::View::Dashboard</Navigation>
        <Value>
            <Hash>
                <Item Key="Module">Kernel::Output::HTML::Dashboard::TicketStatsGeneric</Item>
                <Item Key="SysConfigBase">MyStats</Item>
                <Item Key="Title">KPI Stats</Item>
                <Item Key="Created">0</Item>
                <Item Key="Closed">0</Item>
                <Item Key="Permission">rw</Item>
                <Item Key="Block">ContentSmall</Item>
                <Item Key="Group"></Item>
                <Item Key="Default">1</Item>
                <Item Key="CacheTTL">30</Item>
                <Item Key="Mandatory">0</Item>
            </Hash>
        </Value>
    </Setting>
    <!--
        Hier die Settingsblöcke für die Kurven
        wie oben beschrieben
    --> 
</otrs_config>

Ist die Datei gespeichert, darf man nicht vergessen, die Konfiguration neu zu bauen:

perl bin/otrs.Console.pl Maint::Config::Rebuild

Im nächsten Artikel werden wir ein Plugin für dieses Addon vorstellen, mit dem CSV-Daten in den Graphen dargestellt werden können.

Haben Sie noch Fragen, Wünsche oder Anregungen? Die können Sie gerne an uns schicken.

Permalink:

Vorstellung freie Erweiterung "ConsoleTools"

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:

Upgrade auf OTRS6 bei Einsatz von QuickClose

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:

Tickets in Ticketübersichten nach Besitzer einfärben - Update für OTRS6

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:

Neues OPAR-Modul: ToolbarTicketOwner

21.01.2017 // Renée Bäcker

Welche Tickets gehören mir? Wer diese Frage mit einem kurzen Klick in die Toolbar beantwortet haben möchte, der kann sich die Erweiterung ToolbarTicketOwner von OPAR herunterladen.

Nach der Installation erscheint ein kleines Icon in der Toolbar, über das man auf eine entsprechende Übersicht kommt:

Der Quellcode ist auf Github zu finden. Wer einen Bug hat, kann ihn dort auch melden.

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:

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:

Folien "40 OPAR-Module in 20 Minuten"

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:

Archiv