Neues Modul auf OPAR – DatepickerWeekNumber
Wer im Ticketsystem ein Datum auswählt, z.B. im Warten
-Dialog, bei Dynamischen Feldern oder beim Fälligkeitsdatum in einer TicketChecklist, sieht nur den Monat und die Tage.
Häufig kommt es aber vor, dass man sich über Kalenderwochen unterhält (In KW17 brauchen wir das neue Addon
). Aber welches Datum verbirgt sich dahinter? Das lässt sich jetzt mit DatepickerWeekNumber sagen. Das blendet die Kalenderwoche ein (ist aber über die Systemkonfiguration auch wieder ausschaltbar).
Permalink: /2021-04-23-neues-modul-auf-opar-a-datepickerweeknumber
Das Ende der ((OTRS)) Community Edition – lang lebe OpenSource!
Ende letzten Jahres hat die OTRS AG die Weiterentwicklung der ((OTRS)) Community Edition (CE) eingestellt. Schon zwischen den Jahren haben wir uns mit Znuny unterhalten wie es weitergeht. Znuny hat sich dann dazu entschlossen, das OTRS-Repository zu forken und für mindestens zwei Jahre (mittlerweile geht die Zusicherung viel weiter, aber dazu später mehr) Sicherheits- und Bugfixes bereitzustellen. Dieser Fork heißt Znuny LTS.
Schon vor der Ankündigung der OTRS AG hat Rother OSS einen Fork auf der Basis der CE erstellt – OTOBO.
Diese Forks zeigen, dass Nutzer bei OpenSource nicht von den Plänen des Herstellers abhängig sind sondern auch kurzfristig bei Planänderungen nicht im Regen stehen müssen.
Anfang diesen Jahres haben wir uns mit maxence unterhalten wie wir zu dem ganzen Thema stehen. Schnell hat sich eine Gruppe von Dienstleistern rund um die Ticketsysteme zusammengefunden – die OTTER-Allianz.
Diese Allianz erkennt Znuny als designierten Nachfolger der CE an und trägt Bugfixes und in Zukunft auch Features bei. Nutzer der CE sind also auch in Zukunft auf der sicheren Seite.
In der Zwischenzeit gab es schon vier Releases von Znuny LTS und in den nächsten Wochen wird Znuny auch eine Roadmap veröffentlichen, in der die Zukunft von Znuny dargestellt wird.
Warum bekennen wir uns zu Znuny (LTS) als designiertem Nachfolger der CE?
Mit Znuny LTS ist ein Übergang von der CE ohne Probleme möglich. Die LTS ist kompatibel mit der CE und hält alle Wege offen. Wir empfehlen uneingeschränkt den Einsatz von Znuny.
Hinter Znuny steht nicht nur ein Unternehmen, das viele Jahre Erfahrung mit OTRS/((OTRS)) Community Edition hat. Mit Martin Edenhofer ist auch der Erfinder
von OTRS dabei. Wir wissen, dass Znuny und Martin den OpenSource-Gedanken leben und wir damit auf einer Wellenlänge liegen. Wir kennen und schätzen Martin, Johannes und einige mehr von Znuny.com schon seit vielen Jahren.
Als Teil der OTTER-Allianz wollen wir auch dazu beitragen, dass Znuny in Zukunft sehr erfolgreich wird. Einige PullRequests von uns sind schon in den letzten Releases eingeflossen.
Wir freuen uns auch, dass es wieder möglich ist Features zum Ticketsystem beizutragen, was in der CE faktisch nicht mehr möglich war. Wir wollen – in Absprache mit Znuny – auch die Community mit einbeziehen, welche Erweiterungen von uns in den Kern fließen.
Warum unterstützen wir OTOBO?
Auch OTOBO werden wir unterstützen. Mit Stefan Rother – einem der ersten Mitarbeiter bei OTRS – steht auch hier jemand hinter dem Projekt, den wir seit vielen Jahren kennen und schätzen.
Schon vor dem Ende der CE haben wir die ersten freien Pakete für OTOBO portiert und haben mittlerweile auch schon die ersten unserer kostenpflichtigen Addons portiert.
Wir sind auch dabei, einen OPAR-Nachfolger zu bauen, der den Entwicklern mehr Möglichkeiten bringt und für den wir eine bessere Integration in OTOBO bauen werden. Wir hoffen, dass wir dieses Wissen dann auch in Znuny mit einfließen lassen können.
In unseren Augen gibt es keinen Grund, sein Wissen nur mit einem Projekt zu teilen.
Permalink: /2021-04-22-das-ende-der-otrs-community-edition-a-lang-lebe-opensource
AlternateQueueSender: Erste Mail bestimmt den Absender
In der Standardinstallation der Ticketsysteme ( ((OTRS)) Community Edition, Znuny, OTOBO, ...) wird bei der Einrichtung einer Queue auch die Absenderadresse festgelegt:
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:
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:
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:
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:
- Ein Dynamisches Feld in dem diese Adresse gespeichert wird
- Einen Postmaster-Filter der die Adresse im Dynamischen Feld speichert
- Eine alternative Absendeadresse für die jeweilige Queue, die dieses Dynamische Feld im Template nutzt
Vorstellung freies Modul "GenericDashboardStats"
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:
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:
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: /2020-07-09-genericdashboardstats
Vorstellung freie Erweiterung "ConsoleTools"
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
Upgrade auf OTRS6 bei Einsatz von QuickClose
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
Tickets in Ticketübersichten nach Besitzer einfärben - Update für OTRS6
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
Neues OPAR-Modul: ToolbarTicketOwner
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: /2017-01-21-toolbar-ticketowner
Updates für OPAR-Module
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: /2016-07-08-OPAR-Updates-27-2016
OTRS in der "IT Administrator" (2/16)
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: /2016-05-25-it-administrator-article
Folien "40 OPAR-Module in 20 Minuten"
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: /2016-05-13-40-opar-modules