Blog

Start 1 2 3 4 5 6

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:

QuickClose und Ticket-ACLs

22.01.2021 // Renée Bäcker

QuickClose startete als kleines Addon, mit dem man ohne viele Klicks ein Ticket schließen kann. Sowohl in der Ticketansicht als auch in den Ticketübersichten (z.B. Ansicht nach Status) wird ein Dropdown mit den QuickClose-Aktionen angezeigt.

Nach und nach wuchs die Erweiterung, so dass man die Tickets auch verschieben kann, nicht nur geschlossen-Status auswählen kann und vieles mehr.

Ab sofort ist es möglich, die Aktionen auch über Ticket-ACLs einzuschränken. Gegeben sind folgende QuickClose-Aktionen:

ebee3260-1feb-445a-8fb1-c3a3c182d5ac.png

Ziel ist es, die bei Tickets aus der Queue Raw die ersten beiden Aktionen zu verbieten.

Dazu nehmen erstellen wir eine neue ACL:

972ccf8e-6b18-4649-a2e7-a1049138bc84.png

Die Filterbedingungen sind ganz normaler Standard. In diesem Fall sind alle Tickets in der Queue Raw von dieser ACL betroffen.

Entscheidend ist, was bei der Wertänderung steht. Um QuickClose-Aktionen auszuschließen, müssen wir PossibleNot wählen. Damit wird bestimmt, was an einem Ticket nicht gemacht werden darf.

Wir nutzen hier dann Action. Normalerweise wird dieser Parameter genutzt um Frontendmodule auszuschließen. Sollen z.B. Tickets nicht geschlossen werden dürfen, würde man hier AgentTicketClose eintragen. Aber die TicketACLs auszuweiten ist nicht ohne größere Codeänderungen möglich. Aus diesem Grund nutzen wir Pseudo-Actions. Die setzen sich aus AgentTicketQuickClose_ und dem Namen der QuickClose-Aktion zusammen.

Für ein Ticket aus der Queue Raw sieht das QuickClose-Dropdown so aus:

0c64b57a-fc80-41be-a52d-b8cafa257dae.png

In den Ticketübersichten werden noch alle QuickClose-Aktionen angezeigt. Wird eine Aktion auf ein Ticket angewendet, was durch eine ACL verboten ist, dann wird eine entsprechende Fehlermeldung angezeigt.

Existieren viele QuickClose-Aktionen und es sollen alle Aktionen ausgeschlossen werden, kann ein Regulärer Ausdruck genutzt werden:

74164c06-ef72-4a12-9041-ae8ab5a92de2.png

Permalink:

FAQInvalidateArticles

15.12.2020 // Renée Bäcker

Bisher war es so, dass mit diesem Modul zwei Daten für einen FAQ-Artikel gesetzt werden konnte: Ein Datum, ab dem ein FAQ-Artikel gültig ist und eines, ab dem der Artikel ungültig ist.

Ein Daemon-Task hat dann alle FAQ-Artikel geprüft, und je nach gesetztem Datum den Artikel auf gültig bzw. ungültig gesetzt.

Den Agenten war es aber immer möglich, einen Artikel gleich auf gültig zu setzen. Und wenn ein Artikel erst zu einem späteren Zeitpunkt veröffentlicht werden soll – beispielsweise passend zu einem Launch eines neuen Produkts, mussten Agenten immer daran denken das Datum zu setzen und die Gültigkeit des Artikels auf ungültig zu setzen.

Sollen Artikel immer eine feste Zeit ungültig sein bevor sie gültig werden, kann das folgendermaßen erreicht werden:

In der Systemkonfiguration muss eingestellt werden, wieviele Minuten ein Artikel ungültig sein soll. Weiterhin kann gesetzt werden, dass ein Artikel zwingend ersteinmal auf ungültig gesetzt wird.

c91f447b-4494-49cd-9173-a95120d120e9.png

Anschließend muss das Feld Artikel gültig ab für die Ansicht FAQAdd deaktiviert werden.

Werden jetzt neue FAQ-Artikel erstellt, sind diese für 30 Minuten ungültig. Der Daemon-Task stellt die Artikel dann auf gültig.

Permalink:

TicketAttachments – eine kleine Verbesserung

11.12.2020 // Renée Bäcker

Auch kleine Verbesserungen können extrem hilfreich sein. Dazu zählt auch, dass es mit der aktuellen Version von TicketAttachments möglich ist, die Liste der Ticket-Anhänge in verschiedenen Dialogen zuzuklappen.

Ein kleiner Schritt zurück: In der Erweiterung gibt es ein Feature, mit dem z.B. im Antworten-Dialog alle Anhänge des Tickets anzeigt werden und es so sehr einfach ist, bereits existierende Anhänge in die Antwort zu übernehmen. Im Standard muss man die Datei erst herunterladen und dann in dem Dialog wieder hochladen.

Aktiviert wird dieses Feature in der Systemkonfiguration über die Attachmentlist::*-Optionen (z.B. Attachmentlist::Compose).

Existieren viele Anhänge in einem Ticket, wird diese Liste sehr lang und der Dialog sehr unübersichtlicht. Aus diesem Grund taucht jetzt bei der Liste der Anhänge ein v auf...

37ac4a9e-a7b0-4d0a-b430-aeb1e462dffb.png

und bei einem Klick auf dieses Zeichen wird die ganze Liste eingeklappt:

97f1d8f5-6f32-485a-b17b-e182bdfe8dce.png

Natürlich lässt sich diese Liste auch wieder ausklappen.

Permalink:

Verwaltung von Anhängen bei Artikeln

17.08.2020 // Renée Bäcker

Über das Artikelmenü in der Ticketansicht gibt es die Möglichkeit, die Anhänge eines Artikels zu verwalten:

d6647c01-b3ac-43f9-a497-018a72a199b6.png

Klickt man auf den Link Anhänge verwalten, öffnet sich ein neuer Dialog. In diesem Dialog sind existierende Anhänge – soweit sie existieren und Agenten sie löschen und/oder umbenennen dürfen – aufgelistet.

4fec9cbb-4149-419d-b5ac-3f409aca8949.png

Beim Umbenennen geht eine kleine Abfrage auf, in der man den neuen Namen eintragen kann:

f76570ae-806e-4905-a383-862fad91e07e.png

Außerdem haben Agenten hier die Möglichkeit, neue Anhänge an den Artikel zu hängen.

48c3ee01-2c4e-4864-ba33-3970f251130b.png

Natürlich werden die einzelnen Änderungen auch in der Ticket-Historie abgelegt:

63ff178e-4623-4630-ac0c-19d41c1c12c2.png

Permalink:

Sicherheitslücke in TicketTemplates

26.11.2020 // Renée Bäcker

In TicketTemplates gab es eine Lücke, dass Kunden auf alle Templates zugreifen konnten die für das Kundenportal aktiviert waren – unabhängig davon ob die Templates nur für bestimmte Gruppen erlaubt waren und die Kunden gar nicht zu der Gruppe gehörten. Es war nur notwendig, die ID des Templates zu kennen bzw. zu erraten.

In der Version 6.0.17 wurde dieses Problem behoben.

Permalink:

Neuerungen in TicketChecklist

24.11.2020 // Renée Bäcker

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Das ist ein Test

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

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

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

Wenn das durchgelaufen ist, sollte die Aufgabe geschlossen sein:

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

Permalink:

Checklisten und Templates nutzen

17.08.2020 // Renée Bäcker

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

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

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

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

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

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

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

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

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

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

Und die Checklistenvorlage die ID 1.

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

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

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

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

Das ist also unser Ticket-Filter:

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

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

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

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

Permalink:

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:

Archiv

    Start 1 2 3 4 5 6