Blog

Start 1 2 3 4 5 6

Aktuellen Tag im Datumswidget besser hervorheben

26.04.2021 // Renée Bäcker

Noch ein Artikel zum Widget, das bei der Datumsauswahl zum Einsatz kommt. Im Standard ist der Aktuelle Tag durch einen schmalen gelben Rahmen kenntlich gemacht:

32146946-880f-4e7b-a0f7-9bc00b0fa1cd.png

Schwierig zu erkennen? Richtig. Das wollen wir jetzt verbessern. Aus diesem Grund schauen wir uns an, wo der gelbe Rahmen herkommt. Dazu aktivieren wir die Entwicklertools des Browsers (mit F12 aktivierbar) und schauen mit dem Inspektor auf das Element. Zum Vorschein kommt

2926c0fd-292a-48ea-bbc7-5ebde9d29b64.png

Offensichtlich gibt es hier eine Klasse ui-state-highlight, die diesen Rahmen definiert. Das ändern wir mal testweise direkt in den Entwicklertools ab (einfach auf die 1px solid ... doppelklicken):

5a00700b-056a-4b0c-83e9-2081da7d9f8d.png

Und man sieht direkt den Effekt: ein gut erkennbarer roter Rahmen um den heutigen Tag. Da die Änderung aber nur in den Entwicklertools gemacht wurde, wird beim Neuladen der Seite wieder alles beim alten sein. Also müssen wir die Änderung dauerhaft machen.

Dazu brauchen wir zwei Ding: Eine CSS-Datei und eine Änderung in einer der Ticketsystem-Dateien.

Die CSS-Datei wird unter /var/httpd/htdocs/skins/Agent/default/css/UnserCSS.css abgelegt und enhält einfach nur:

.ui-state-highlight,.ui-widget-content .ui-state-highlight,.ui-widget-header .ui-state-highlight {
    border: 2px solid #ff0000;
}

In der Ticketsystem-Datei sagen wir, dass das Ticketsystem die eigene CSS-Datei immer mit einbinden soll. Geändert werden muss /Kernel/Output/HTML/Templates/Standard/HTMLHead.tt. Nachdem die CSS-Datei jquery-ui.css eingebunden wird, muss folgende Zeile eingefügt werden:

<link rel="stylesheet" type="text/css" href="[% Config("Frontend::WebPath") %]skins/Agent/default/css/UnserCSS.css" />

Anschließend mal den Cache löschen.

Aber vorsicht: Beim Upgrade des Ticketsystems muss darauf geachtet werden, dass die beiden Änderungen mit umziehen.

Permalink:

Neues Modul auf OPAR – DatepickerWeekNumber

23.04.2021 // Renée Bäcker

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.

983c5ed2-e1dd-4969-8acb-f6ca42eb16c9.png

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

228726a3-320a-414d-b598-e8bf31fb212e.png

Permalink:

Das Ende der ((OTRS)) Community Edition – lang lebe OpenSource!

22.04.2021 // Renée Bäcker

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:

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:

Archiv

    Start 1 2 3 4 5 6