Blog

Start 1 2 3 4 5 6

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:

Perl-API-Doku ((OTRS)) Community Edition und ITSM-Module

17.08.2020 // Renée Bäcker

Schon geraume Zeit lief die Generierung der Perl-API-Dokumentationen nicht so ganz fehlerfrei und so haben wir vor ein paar Monaten die Dokumentation offline genommen. In der Zwischenzeit haben wir aber Rückmeldung aus der Community bekommen, dass die Online-Dokumentation hilfreich gewesen ist. Aus diesem Grund haben wir alles überarbeitet und mittlerweile steht die Dokumentation wieder zur Verfügung.

Die OTRS stellt selbst auch die Dokumentation der ((OTRS)) Community Edition zur Verfügung, aber nur in der Version 6 und auch nicht die ITSM-Module. Unter https://otrs.perl-services.de sind jetzt folgende Module zu finden:

  • ((OTRS)) Community Edition <= Version 6
  • ITSM Configuration Management
  • ITSM Change Management
  • ITSM Core
  • ImportExport
  • General Catalog
  • FAQ

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:

CSV-Plugin für GenericDashboardStats

21.07.2020 // Renée Bäcker

Im letzten Artikel habe ich bereits die Erweiterung GenericDashboardStats und die Möglichkeiten, deutlich flexiblere Dashboard-Statistiken zu erstellen, vorgestellt. Bisher konnten nur Daten angezeigt werden, die sich mit einer Ticketsuche bestimmen lassen. Das ist aber nicht immer ausreichend.

Seit der aktuellen Version der Erweiterung ist es möglich, Plugins zu nutzen. Wir haben z.B. ein Plugin entwickelt, um Daten aus CSV-Dateien auszulesen. So können Sie von anderen Systemen wie einer CMDB, einer Telefonanlage oder einem CRM eine CSV-Datei exportieren lassen, dessen Inhalte dann in der Statistik angezeigt werden.

Nehmen wir mal an, das CRM erstellt folgende CSV-Datei:

2020-07-01;new_lead;3
2020-07-01;offers;5
2020-07-02;new_lead;2
2020-07-02;offers;2
2020-07-03;new_lead;4
2020-07-03;offers;2
2020-07-04;new_lead;4
2020-07-04;offers;2
2020-07-05;new_lead;3
2020-07-05;offers;3
2020-07-06;new_lead;1
2020-07-06;offers;4
2020-07-07;new_lead;2
2020-07-07;offers;4

Aus dieser Datei sollen zwei Linien in der Statistik erzeugt werden: Eine für die neuen Leads und eine für die Angebote die verschickt wurden.

Hierfür legen wir eine neue Datei in Kernel/Config/Files/XML an (z.B. CRMStats.xml):

<?xml version="1.0" encoding="utf-8"?>
<otrs_config version="2.0" init="Application">
  <!-- Hier kommen dann die "Settings" hin -->
</otrs_config>

Wenn die Statistik in einem extra Widget angezeigt werden soll, dann benötigen wir eine Konfigurationseinstellung für das neue Dashboard-Widget:

    <Setting Name="DashboardBackend###257-CRMStats" 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">CRMStats</Item>
                <Item Key="Title">CRM Stats</Item>
                <Item Key="Created">1</Item>
                <Item Key="Closed">1</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>

Jetzt müssen die einzelnen Linien definiert werden. Für die beiden Informationen die wir anzeigen wollen sieht das so aus:

    <Setting Name="CRMStats::Stats###001-new-leads" Required="0" Valid="1">
        <Description Translatable="1">A CSV Dummy</Description>
        <Navigation>Stats</Navigation>
        <Value>
            <Hash>
                <Item Key="OptionKey">CSVNewLeads</Item>
                <Item Key="type">plugin</Item>
                <Item Key="module">Kernel::System::GenericDashboardStats::CSV</Item>
                <Item Key="label">New Leads</Item>
            </Hash>
        </Value>
    </Setting>
    <Setting Name="CRMStats::Stats###002-offers" Required="0" Valid="1">
        <Description Translatable="1">A CSV Dummy</Description>
        <Navigation>Stats</Navigation>
        <Value>
            <Hash>
                <Item Key="OptionKey">CSVOffers</Item>
                <Item Key="type">plugin</Item>
                <Item Key="module">Kernel::System::GenericDashboardStats::CSV</Item>
                <Item Key="label">Offers</Item>
            </Hash>
        </Value>
    </Setting>

Neu ist hier der type plugin , über den entsprechend definiert wird, dass ein Plugin genutzt werden soll. Welches Plugin genutzt werden soll, wird dann über das module eingestellt. Die Arbeit mit der CSV-Datei macht also das Modul Kernel::System::GenericDashboardStats::CSV .

In der Statistiken werden so aber noch keine Werte angezeigt, da noch die Quelle für die Werte fehlt. Und das Plugin kann nicht automatisch wissen, welche Informationen aus der CSV-Datei wie zusammenhängen und was angezeigt werden soll. Wenn wir uns die Datei näher anschauen, sehen wir, dass die Spalten durch ein ; getrennt sind. In der ersten Spalte steht das Datum, die zweiten Zeile bestimmt in welcher Linie etwas angezeigt werden soll und die dritte Spalte ist dann der Wert, der in der Statistik auftauchen soll.

Genau das muss jetzt in der Konfigurationsdatei auch so definiert werden. Beispielhaft für die Neuen Kontakte sieht das folgendermaßen aus:

    <Setting Name="CSVNewLeads" Required="0" Valid="1">
        <Description Translatable="1">Config for the</Description>
        <Navigation>Stats</Navigation>
        <Value>
            <Hash>
                <Item Key="cache_ttl">1</Item>
                <Item Key="count_column">2</Item>
                <Item Key="date_column">0</Item>
                <Item Key="date_format">%Y-%m-%d</Item>
                <Item Key="filter">new_lead</Item>
                <Item Key="filter_by_column">1</Item>
                <Item Key="path">/opt/otrs/var/crm.csv</Item>
                <Item Key="quote">"</Item>
                <Item Key="separator">;</Item>
                <Item Key="skip_first_line">0</Item>
            </Hash>
        </Value>
    </Setting>

Der Name dieser Einstellung bezieht sich auf den Wert, den wir weiter oben bei OptionKey angegeben haben.

Eines muss man bei den Werten beachten: Die Zählung der Spalten beginnt bei 0.

Diese Parameter stehen zur Verfügung:

  • cache_ttl

    Damit nicht bei jedem einzelnen Wert der Statistik immer wieder die CSV-Datei ausgelesen wird, werden die Daten gecached. Wie lange diese Daten gültig sind, wird über cache_ttl eingestellt. Der Wert wird in Sekunden angegeben

  • count_column

    Die Spalte, in der die anzuzeigenden Werte stehen. Achtung: Die Zählung der Spalten beginnt bei 0. Diese Spalte wird benötigt.

  • date_column

    Die Datumsspalte. Diese Spalte wird benötigt.

  • date_format

    Das Format des Datums. Nutzt die Formatierungswerte von strftime .

  • filter

    In der CSV-Datei können viele Daten stehen, die aber nicht in dem Graphen angezeigt werden soll. Dann kann mit dem Filter bestimmt werden, welche Werte herangezogen werden sollen. Hier interessieren wir uns erstmal nur für die neuen Kontakte, daher filtern wir nach new_lead .

  • filter_by_column

    Die Spalte, nach der gefiltert werden soll.

  • path

    Der Pfad zur CSV-Datei

  • quote

    Werden Quoting-Zeichen genutzt (meistens " ), dann muss das hier angegeben werden

  • separator

    Das Trennzeichen zwischen den Spalten

  • skip_first_line

    Sind in der ersten Zeile der CSV-Datei die Spaltenüberschriften zu finden, muss skip_first_line auf 1 gesetzt werden.

Das damit erstellte Dashboard-Widget sieht dann so aus:

Widget mit Graph aus CSV-Datei

Über den Plugin-Mechanismus von GenericDashboardStats sind noch weitere Anbindungen denkbar, z.B. Anbindung von REST-APIs wie Gitlab zur Darstellung von offenen Bugmeldungen.

Sie haben Interesse an dem Modul oder ein anderes Anliegen? Dann kontaktieren Sie uns doch.

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:

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:

Sichtbarkeit von Menüpunkten über Rollen steuern

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.

Die Gruppe 'can_phone'

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.

Sysconfig-Option Ticket::Frontend::MenuModule###425-Phone Call Outbound

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.

Die Rolle 'CanPhone'

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.

Zuordnung Gruppe can_phone <-> Rolle CanPhone<q>title=</q>Die Rolle braucht rw-Rechte auf die Gruppe" /></p>

<p>Ab jetzt darf jede Person mit der Rolle <q>CanPhone</q> auch die Telefonanrufe tätigen.</p>

<h2 id=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.

Agenten mit der Rolle 'TestRolle'

Agenten mit der Rolle 'CanPhone'

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

Ticketmenü für 'Frontoffice Agent'

... als Backoffice Agent nicht.

Ticketmenü für 'Backoffice Agent'

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:

"Need GroupName": Wenn das Systemprotokoll bei OTRS6 damit geflutet wird...

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:

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:

JiraPackage - Felder dynamisch füllen

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:

Der erzeugte Vorgang

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

Permalink:

Archiv

    Start 1 2 3 4 5 6