Blog

Start 1 2 3 4 5 6

callto/tel-Links in Kundendaten

23.03.2017 // Renée Bäcker

Viele Telefonanlagen können mit callto- oder tel-Links umgehen. So kann der Agent bequem den Kunden anrufen ohne die Nummer selbst zu wählen. Aus diesem Grund kann man in den Kundeninformationen einen Link anzeigen lassen:

Kundeninformation am Ticket

Soweit so gut. Wenn man bei Kundeninformationen einen Link hinterlegt ist vielen wahrscheinlich bekannt. Man kann im Mapping der Kundeninformationen in der Kernel/Config.pm die URL zusammenbauen. Das einfachste wäre einen Link zur URL anzuzeigen:

$Self->{CustomerUser}->{Map} = [

  # note: Login, Email and CustomerID needed!
  # var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly, http-link-target, link class(es)
  [ 'UserTitle',      'Title',      'title',      1, 0, 'var', '', 0 ],
  [ 'UserFirstname',  'Firstname',  'first_name', 1, 1, 'var', '', 0 ],
  # ... noch mehr Eigenschaften ...
  [ 'UserURL',          'URL',         'url',          1, 0, 'var', '[% Data.UserURL | html %]', 0 ],
];

In der Spalte nach dem 'var' wird die URL zusammen gebaut. In diesem Fall ist das einfach die URL, die bei dem Kunden gespeichert ist. Als Daten stehen hier die Kundeninformationen zur Verfügung und in Ticketansichten auch Ticketinformationen. So ist es möglich, z.B. bei der E-Mailadresse einen Link zu hinterlegen, bei dem eine Antwort auf das aktuelle Ticket erstellt wird. Das Beispiel dazu ist in der Kernel/Config/Defaults.pm zu finden.

Zurück zum Telefonlink. Der einfachste callto Link würde so aussehen:

'callto:[% Data.UserPhone %]'

Aber da Telefonanlagen meist die Telefonnummer im internationalen Format brauchen und keine Sonderzeichen vertragen, muss die Telefonnummer aufbereitet werden. Die Telefonnummer kann ja in unterschiedlichster Weise eingetragen sein:

  • 0123 3913 - 12
  • 0049 123 3913 - 12
  • 0123/3913 12
  • +49-123 391312
  • ...

Jetzt kommt uns zugute, dass die Template-Engine mit OTRS4 ausgetauscht wurde. Seitdem ist man sehr flexibel was man so alles machen kann. Template::Toolkit - die neue Template-Engine - bietet viele Filter schon von Haus aus. Dazu gehört auch der replace-Filter. Den nutzen wir hier, um zuerst alles was nicht Zahl oder + ist rauszulöschen. Das nächste replace ersetzt zwei führende 0en durch + und wenn dann noch eine führende Null vorhanden ist, wird diese mit +49 ersetzt. Daraus ergibt sich folgendes Konstrukt für die Config.pm:

[ 'UserPhone', 'Phone', 'phone', 1, 0, 'var',
    q~callto:[% Data.UserPhone | replace('[^0-9+]','') | replace('\A00','+') | replace('\A0','+49') %]~,
    0 ],

Damit wird aus allen Beispielen oben genau eine Darstellung der Telefonnummer: +49123391312

Kundeninformation am Ticket

Noch mehr Filter sind hier dokumentiert: Template-Dokumentation für OTRS und Template::Toolkit Seite

Permalink:

OTRS-Schulungen 2017

25.01.2017 // Renée Bäcker

OTRS hat viele Ecken - und in vielen kennt Sie sich vielleicht schon aus. Einige sind vielleicht aber noch nicht erforscht. Wenn Sie diese Ecken kennenlernen möchten, dann helfen Schulungen. Auch in diesem Jahr bieten wir wieder bei der Perl-Academy zahlreiche OTRS-Schulungen an.

Das fängt bei KeyUser-Schulungen an, geht weiter mit Administratoren- und ITSM::ChangeBuilder-Schulungen weiter und muss bei Entwickler-Schulungen nicht aufhören. Gerne bereiten wir auch eine - speziell auf Sie zugeschnittene - Firmenschulung an.

Schon ab dem zweiten Teilnehmer ist die Durchführung garantiert.

Die nächsten Schulungen:

20.-24.02.2017 - OTRS für Entwickler (Englisch)
06.-08.03.2017 - OTRS Administratoren
09.-10.03.2017 - OTRS::ITSM ChangeBuilder

28.04.207 - OTRS KeyUser

19.06.-23.06.2017 - OTRS für Entwickler
26.06.-28.06.2017 - OTRS Administratoren
29.06.-30.06.2017 - OTRS::ITSM ChangeBuilder

16.10.-20.10.2017 - OTRS für Entwickler (Englisch)

13.11.-15.11.2017 - OTRS Administratoren
17.11.2017 - OTRS KeyUser

11.12.-15.12.2017 - OTRS für Entwickler

Wir würden uns freuen, Sie als Teilnehmer in unseren Schulungen begrüßen zu dürfen.

Permalink:

Neues Addon: GlobalSearchProfile

22.01.2017 // Renée Bäcker

Es kommt doch häufiger vor, dass man die gleichen Abfragen macht um Tickets zu suchen: Welche Tickets wurden in den letzten beiden Wochen in der Queue VIP erstellt? Welche Tickets wurden zuletzt bearbeitet?

Wer immer die gleichen Abfragen tätigt legt sich meistens ein Suchprofil dafür an. Aber was wenn viele Agenten die gleiche Abfrage benötigen? Das kommt z.B. auch dann vor wenn es eine Abteilungsinterne Absprache gibt wie mit Tickets umgegangen wird. Dann muss im Standard-OTRS jeder Agent diese Anfrage selbst erstellen. Dabei kann es natürlich zu Fehlern kommen, weil man sich vertippt oder ein Suchparameter vergessen wurde.

GlobalSearchProfile bietet hier die Lösung. Hier kann man beim Erstellen eines Suchprofils angeben, dass es global verfügbar sein soll und damit jedem Agenten zur Verfügung steht:

Erstellen des Suchprofils

Bei jedem Agenten taucht das Suchprofil dann auf:

Um zu vermeiden dass auf einmal nur noch globale Suchprofile erstellt werden, kann man über die SysConfig bestimmen Mitglieder welcher Gruppen solche Profile anlegen können.

Haben wir Ihr Interesse an GlobalSearchProfile geweckt? Dann nehmen Sie doch einfach Kontakt zu uns auf oder fordern Sie gleich Ihr Demosystem an.

Haben Sie noch weitere Ideen und Wünsche? Dann schreiben Sie uns bitte.

Permalink:

Neues OPAR-Modul: ToolbarTicketOwner

21.01.2017 // Renée Bäcker

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

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

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

Permalink:

Frohe Weihnachten

24.12.2016 // Renée Bäcker

Ein ereignisreiches und erfolgreiches Jahr geht zu Ende. Im Fernsehen gibt es auf jedem Sender einen Rückblick auf das Jahr 2016 - und auch wir wollen kurz zurückschauen auf das was bei uns so los war.

Ich war zweimal in Dormagen auf dem OTRS-Stammtisch und habe dort jeweils einen Vortrag gehalten. Vielen Dank an dieser Stelle an die Fahrer, die mich jeweils zum Treffen und auch wieder zurück nach Köln gebracht haben. Die Treffen sind immer sehr interessant und es macht Spaß sich mit den Teilnehmern/Teilnehmerinnen zu unterhalten - auch über OTRS-fremde Themen. Ich freue mich aber auch sehr über die vielen Anregungen sowohl für die freien Module als auch die kommerziellen Module.

Vielen Dank an das Team von maxence für das Organisieren der Treffens! Ich möchte auch im nächsten Jahr wieder zwei- bis dreimal zu dem Stammtisch fahren. Wenn es Vortragswünsche gibt, bin ich dafür offen.

Unsere Module werden sehr gut angenommen und von den Kunden gibt es immer wieder nützliches Feedback zu den Erweiterungen. Viele gewünschte Features konnten wir in die Erweiterungen einbauen, so dass alle Kunden davon profitieren können. Wir würden uns freuen, wenn es auch im nächsten Jahr so erfolgreich weitergeht.

Viele Erweiterungen konnten wir noch nicht auf der Webseite oder hier im Blog zeigen, weil wir es zeitlich nicht geschafft haben. Und auch im nächsten Jahr wird es einige neue Erweiterungen geben.

Dann habe ich noch OTRSWeekly gestartet - ein wöchentlicher Newsletter zum Thema OTRS.

Jetzt bleibt mir nur noch, Ihnen allen Frohe Weihnachten und ein gutes neues Jahr zu wünschen. Genießen Sie die Feiertage und kommen Sie zur Ruhe.

Permalink:

Conditions and Actions für TicketChecklist - und noch mehr

16.12.2016 // Renée Bäcker

Auf Anregung eines Kunden haben wir TicketChecklist um Conditions and Actions erweitert. Damit ist es möglich, auf Änderungen des Status von Aufgaben zu reagieren. Nehmen wir mal als Beispiel die Organisation der Firmen-Weihnachtsfeier, bei der sich folgende Checkliste mit diesen Aufgaben ergibt:

  • Suche eines Veranstaltungsortes
  • Unterschreiben des Vertrags
  • Catering buchen
  • Weihnachtsgeschenke besorgen
  • Rechnungen bezahlen

Die Aufgabe Weihnachtsgeschenke besorgen kann völlig unabhängig von den anderen Aufgaben erledigt werden. Aber der Vertrag kann erst unterschrieben werden, wenn ein Veranstaltungsort feststeht. Und das Catering wird erst bestellt, wenn der Vertrag unterschrieben ist da dort eventuell festgehalten ist, dass der Betreiber des Veranstaltungsortes selbst das Catering macht.

Wenn der Veranstaltungsort ausgewählt ist, wird die Aufgabe Unterschreiben des Vertrags auf warten gesetzt. Das gleiche gilt für Catering buchen wenn der Vertrag unterschrieben ist. Aus Anschauungszwecken soll die Rechnungen erst bezahlt werden wenn das Catering gebucht ist. Da das von der Buchhaltung erledigt wird, soll das Ticket dann in die Queue Buchhaltung geschoben werden.

Daraus ergibt sich folgende Übersicht der Aufgaben:

Aufgaben des Tickets

Als erstes werden die Aufgaben mit ihren Verantwortlichen erstellt:

Aufgaben

Danach werden die Conditions und Actions gepflegt. Zuerst definieren wir die Statusänderungen anderer Aufgaben:

Bedingungen und Aktionen

Hier wird immer nur eine andere Aufgabe geändert. Es ist aber auch möglich mehrere Aufgaben zu ändern:

Aktionen auf mehrere Aufgaben

Neben dem Verändern anderer Aufgaben ist es bei den Actions auch möglich ein Dynamisches Feld am Ticket zu setzen. Dazu muss das Action-Modul TicketDynamicFieldSet verwendet werden:

Dynamisches Feld setzen

Das nutzen wir in diesem Beispiel, um das Verschieben des Tickets in die Queue Buchhaltung zu ermöglichen. Bei den Parametern muss der Name des Dynamischen Feldes (hier: MoveToQueue) als Schlüssel eingetragen werden und bei Wert der neue Wert des Feldes.

An dieser Stelle wäre es auch denkbar eigene Action-Module zu programmieren, so dass z.B. ein Status jetzt ausführen erstellt wird und dass beim Erreichen des Status automatisch ein Programm aufgerufen wird, das ein Programm ausführt oder zusätzliche Informationen aus einem Drittsystem holt.

Auf Basis der Änderung eines Dynamischen Feldes kann man mit GenericAgents das Ticket dann in eine andere Queue verschieben:

Stammdaten GenericAgent

Als Filter wird der neue Wert des Dynamischen Feldes genommen

Ticketfilter

und anschließend das Ticket verschoben

Aktion auf das Ticket

Mit diesen Conditions und Actions kann man mit TicketChecklist sehr viel erreichen weil man auch Einfluss auf das Ticket selbst nehmen kann.

Weitere Änderungen an TicketChecklist:

  • Vorlagen können kopiert werden. Damit ist es jetzt möglich noch schneller ähnliche Vorlagen zu erstellen.
  • Import/Export von Vorlagen, so dass es leicht ist Test- und Livesystem synchron zu halten
  • Export von Aufgaben. In der Ticketansicht und im Dashboard können die Aufgaben als PDF, Excel-Datei und als ics-Datei exportiert werden.

Haben wir Ihr Interesse an TicketChecklist geweckt? Dann nehmen Sie doch einfach Kontakt zu uns auf oder fordern Sie gleich Ihr Demosystem an.

Ausblick:

Auch vor TicketChecklist machen ständige Veränderungen nicht Halt. Als nächstes soll die Anzeige der Aufgaben im Ticket-Kalender ermöglicht werden (im Zusammenspiel mit der Erweiterung AdvancedTicketCalendar. Weiterhin soll es ermöglicht werden, Kundenspezifische Checklistenvorlagen zu erstellen.

Haben Sie noch weitere Ideen und Wünsche? Dann schreiben Sie uns bitte.

Permalink:

JIRA-Connector der OTRS-AG vs. JIRAPackage von catWorkX

15.12.2016 // Renée Bäcker

Mit OTRS5s hat die OTRS AG auch einen JIRA-Connector veröffentlicht. Schon seit einigen Jahren bietet die catWorkX GmbH ein JIRAPackage an. Das Gesamtpaket von catWorkX besteht aus einem JIRA-Addon und einen OTRS-Addon. Ich kenne den JIRA-Connector der OTRS AG nur aus den Ankündigungen und dem Blogpost, möchte hier an dieser Stelle aber trotzdem auf beide Pakete eingehen.

Der JIRA-Connector setzt auf das GenericInterface von OTRS auf. Man benötigt zwei Erweiterungen, die es nur für Kunden der Business-Lösung gibt. Sind die Abhängigkeiten installiert, muss der Webservice eingerichtet werden. Anschließend müssen noch Mappings konfiguriert werden. Der oben verlinkte Blogpost beschreibt die notwendigen Schritte ausführlicher.

Durch Trigger - wie Änderung des Ticketstatus, Neues Ticket oder neuer Artikel - wird die Kommunikation mit JIRA ausgelöst und die Informationen werden von OTRS an JIRA übertragen.

Das JIRAPackage implementiert die Kommunikation mit JIRA in eigenen Modulen. Das Gesamtpaket bietet im Gegensatz zur Lösung der OTRS AG die Kommunikation in beide Richtungen: Von OTRS nach JIRA und von JIRA nach OTRS. So bleiben beide Systeme auf dem aktuellen Stand. Aber wo liegen die Unterschiede in der Bedienung? Auch beim JIRAPackage kann der Informationsaustausch durch Trigger wie neue Tickets, neue Artikel, Statusänderung etc. angestoßen werden.

Möchte man aber vermeiden dass automatisch JIRA-Issues erzeugt werden, kann man das abschalten und der Agent muss aktiv das Erstellen des JIRA-Issues anstoßen. Dazu gibt es zwei Wege:

  1. Wenn der Vorgang in JIRA schon ab dem ersten Artikel gelten soll, kann der Agent im Ticketmenü auf OTRS -> JIRA klicken. Dann wird der erste Artikel als Basis genommen und der Vorgang dafür erstellt. Es ist auch konfigurierbar dass neben dem ersten Artikel auch alle anderen Artikel an das JIRA übertragen werden. Das ist dann hilfreich wenn sich erst im Laufe der Kommunikation mit dem Kunden rausstellt, dass das Ticket ein Thema für die Entwickler ist.
  2. Wenn ein Ticket schon viele Artikel hat und bspw. der sechste Artikel die Infos für einen JIRA-Vorgang enthält. Dann kann der Agent im Artikelmenü auf OTRS -> JIRA klicken. Dann werden die Artikel 1-5 nicht an das JIRA übertragen.

OTRS -> JIRA im Ticketmenü<q>title=</q>Erstellen des JIRA-Vorgangs aus dem Ticketmenü heraus<q>/>
<img src=</q>/images/blog/jira/article_menu.png<q>alt=</q>OTRS -> JIRA im Artikelmenü<q>title=</q>Erstellen des JIRA-Vorgangs aus dem Artikelmenü heraus"/></p>

<p>In einem Dialog kann der Agent noch auswählen zu welchem Projekt der Vorgang gehört, welche Art von Vorgang das ist und wem der Vorgang zugeordnet werden soll.</p>

<p><img src=

Sollen nur für ein einziges Projekt Vorgänge - mit einem bestimmten Typ - und für einen JIRA-Benutzer erstellt werden, kann der Dialog auch ausgeschaltet werden.

Kommen wir zur Konfiguration: Nach der Installation kann man im Adminbereich einfach über einen Wizard die JIRA-Integration einrichten. Es werden Dinge wie URL zu JIRA, Authentifizierungsdaten abgefragt und auch die Zuordnung von JIRA-Feldern zu OTRS-Feldern wird dort vorgenommen.

Schritt 1 im Wizard Schritt 2 im Wizard Schritt 3 im Wizard

Für erfahrenere Admins kann das alles auch in der SysConfig direkt eingetragen werden. Dann kann man beim Mapping sogar dafür sorgen, dass Benutzerdefinierte Funktionen ausgeführt werden (z.B. damit Inhalte verschlüsselt übertragen werden).

Disclaimer: An der Entwicklung von JIRAPackage bin ich direkt beteiligt.

Wenn Sie Interesse am JIRAPackage haben, kontaktieren Sie doch bitte catWorkX.

Sie können auch über den JIRA Marketplace das Paket zur OTRS-Integration in JIRA in Ihrem JIRA installieren und das OTRS-Paket können Sie bei catWorkX herunterladen und dann erstmal testen.

Permalink:

Folien "Postmasterfilter in OTRS"

09.12.2016 // Renée Bäcker

Ich habe am Mittwoch auf dem OTRS-Stammtisch Rheinland einen Vortrag gehalten. Der Titel: PostmasterFilter in OTRS

In dem Vortrag ging es darum, wie man mit Postmasterfiltern in OTRS die Mailverarbeitung bzw. die Ticketerstellung beeinflussen kann. Die Postmasterfilter, die über die Oberfläche konfiguriert werden können, haben aber Einschränkungen bzw. Nachteile. Auch den Aufbau einer Mail - der sehr kompliziert werden kann - habe ich in Grundzügen erläutert. Abschließend ging es um die Entwicklung eigener Postmasterfilter-Module. Mit diesem mächtigen Werkzeug hat man alle Möglichkeiten...


Vielen Dank an das Team von maxence für das Organisieren des Treffens! Ich möchte auch im nächsten Jahr wieder zwei- bis dreimal zu dem Stammtisch fahren. Wenn es Vortragswünsche gibt, bin ich dafür offen.

Permalink:

Ticket-Workflows mit der Erweiterung TicketTemplates

19.11.2016 // Renée Bäcker

Seit der Version 5.0.4 von TicketTemplates gibt es die Möglichkeit, Ticket-Workflows zu erstellen. Ticket-Workflows bedeutet, dass es von einem Ticket ausgehend verschiedene Tasks geben kann, die auch von einander abhängen können. Stellen Sie sich vor, ein neuer Mitarbeiter möchte bei Ihnen im Unternehmen anfangen. Da fallen für ganz viele Abteilungen Arbeit an:

  • Die Personalabteilung muss den Vertrag aufsetzen
  • Die IT-Abteilung muss E-Mail-Konten einrichten und Berechtigungen setzen
  • Das Büro muss eingerichtet werden
  • und noch vieles mehr

Aber die IT-Abteilung darf erst mit der Arbeit anfangen wenn der Vertrag da ist.

Einrichten des Workflows

Diesen Ablauf können Sie mit TicketTemplates jetzt ganz einfach abbilden:

Legen Sie für alle Aufgaben jeweils eine Vorlage an. Darin können Sie bestimmen welcher Text das Ticket haben soll, welche Priorität, zu welcher Queue das Ticket gehören soll und noch vieles mehr.

Beispieltemplate für IT-Ticket

In diesem Beispiel haben wir mal drei Vorlagen erstellt:

Ticket Templates

Als nächstes wird mit diesen Vorlagen der Workflow abgebildet. Im Adminbereich gibt es hierzu den Punkt Ticket-Templates-Workflows

Ausschnitt Adminmenü

Zu jedem Workflow wird der Name, ein Kommentar und die Gültigkeit eingetragen. Damit es für die Agenten bei vielen Workflows nicht zu unübersichtlich wird, kann die Sichtbarkeit eingeschränkt werden indem man dem Workflow Gruppen zuweist.

Als nächstes müssen Aufgaben/Tasks hinzugefügt werden. Jede Aufgabe bekommt einen Namen und muss ein Template zugewiesen bekommen. Die Angaben aus dem Template werden dazu genutzt das Ticket für die Aufgabe zu erstellen.

Weiterhin können die Abhängigkeiten festgelegt werden. In unserem Beispiel muss die Personalabteilung erst den Vertrag bekommen haben, bevor die IT tätig wird und das E-Mail-Konto sowie die Berechtigungen einrichtet. Genau das bilden die Abhängigkeiten ab. Das Aufgabe für die IT hängt von der Aufgabe für die Personalabteilung ab. Genau das ist hier eingetragen:

Beispielworkflow

Für alle Aufgaben die von anderen Aufgaben abhängig sind, werden Tickets in einem speziellen Status angelegt. Wird dann das Ticket (z.B. das der Personalabteilung) geschlossen, werden alle abhängigen Aufgaben (Tickets für IT und Sonstiges) auf offen gesetzt. Damit tauchen diese Tickets dann auch in den Übersichten der Agenten auf.

Als nächstes kann noch bestimmt werden, welche Inhalte von dynamischen Feldern aus dem Originalticket übernommen werden. So kann man im Originalticket ein Dynamisches Feld für die benötigten Berechtigungen ausfüllen und das wird dann automatisch in das Ticket für die IT übernommen.

Workflow starten

Ein Workflow kann von einem beliebigen Ticket aus gestartet werden. Im Ticketmenü befindet sich ein Dropdown, in dem alle verfügbaren Workflows aufgelistet sind. Bei Auswahl des passenden Workflows werden die Tickets gemäß den Aufgaben erstellt.

Ticketmenü

Zur besseren Auffindbarkeit wird jedes Ticket mit dem Ausgangsticket normal verknüpft.

Verknüpfungen - Tickets

Weiterhin werden die Aufgaben ohne Abhängigkeiten direkt mit dem Ticket als WorkflowTask verknüpft.

Die Aufgaben mit Abhängigkeiten werden jeweils mit dem Ticket der Abhängigkeit als WorkflowTask verknüpft. So kann man immer im Workflow durchnavigieren und bekommt einen Überblick welche Aufgaben noch ausstehen.

Verknüpfungen - WorkflowTasks

Was ist der Nachteil gegenüber dem Prozessmanagement? Im Prozessmanagement ist man wesentlich flexibler. Es ist nicht vorgegeben welcher Status die Sub-Tickets haben. Außerdem kann man beim Prozessmanagement mit einigen Platzhaltern wie z.B. <OTRS_TICKET_Title> arbeiten.

Was ist der Vorteil gegenüber dem Prozessmanagement? Templates können wiederverwendet werden - sie können sowohl als Vorlagen für Telefon- oder Emailtickets als auch für Tickets im Workflow benutzt werden. Die Konfiguration ist wesentlich einfacher: Für die Vorlagen gibt es eine eigene Administrationsoberfläche bei der man sich nicht nicht - wie im Prozessmanagement - merken muss wie die Parameter für z.B. den Betreff oder den Ticket-Text.

Über die Abhängigkeiten kann man bei den Workflows sehr einfach festlegen. Durch den eigenen Ticketstatus und das automatische öffnen der Tickets wenn Abhängigkeiten geschlossen werden, mussman sich keine Gedanken darüber machen wann welches Ticket sichtbar werden soll.

Haben wir Ihr Interesse an TicketTemplates geweckt? Dann nehmen Sie doch einfach Kontakt zu uns auf oder fordern Sie gleich Ihr Demosystem an.

Ausblick:

Unsere Erweiterungen werden ständig weiterentwickelt, so auch TicketTemplates. Als nächstes soll es die Möglichkeit geben Templates und Workflows zu exportieren und importieren. Damit soll ees leichter werden, Templates und Workflows von einem Testsystem auf das Produktivsystem zu übertragen. Außerdem soll ein Transaction-Modul für das Prozessmanagement entwickelt werden, dass es ermöglicht Tickets auf Basis von Templates zu erstellen und auch das Starten von Workflows soll ermöglicht werden.

Haben Sie noch weitere Ideen und Wünsche? Dann schreiben Sie uns bitte.

Permalink:

Vortrag auf der OpenRheinRuhr 2016:

22.10.2016 // Renée Bäcker

Auf der diesjährigen OpenRheinRuhr werde ich einen Vortrag halten: 20 freie Addons für OTRS. Der Vortrag steht am Sonntag, 06. November 2016 um 10 Uhr auf dem Plan.

Ich würde mich freuen, wenn möglichst viele Zuhörer erscheinen und wir dann noch in eine Diskussion übergehen können.

Wer noch eine Karte für die OpenRheinRuhr benötigt, kann sich gerne bei mir melden.

Permalink:

Kundensuche anpassen - was wird durchsucht

21.10.2016 // Renée Bäcker

Die Kundensuche wird sehr häufig benötigt: Beim Erstellen eines Tickets, beim Antworten, bei der Suche nach Kunden usw. Was aber wenn die Suche des Standards nicht ausreicht? Wenn nicht nur nach Vor- oder Nachname gesucht werden soll, sondern auch nach der Kombination Vor- und Zuname oder nach der Telefonnummer?

Die Anpassung ist sehr einfach in der Kernel/Config.pm machbar. Es muss kein Kernmodul angepasst werden. Im Standard-OTRS ist in der Kernel/Config/Defaults.pm folgendes zu finden:

CustomerUserSearchFields => [ 'login', 'first_name', 'last_name', 'customer_id' ];

Damit wird festgelegt, dass die Kundensuche in den Spalten login, first_name und customer_id suchen soll. Das reicht dann aber nicht aus. Diese Liste muss um alle Felder erweitert werden, die durchsucht werden sollen.

Gehen wir davon aus, dass wir diese Kunden haben:

Kundenübersicht

Jetzt wollen wir nach Fax Kunde suchen. Bis wir fax eingegeben haben, wird der Kunde auch gefunden:

Suche nur nach Vorname

Aber sobald wir noch das k vom Nachnamen eingeben ist es vorbei:

Suche nach Vor- und Nachname im Standard

Einfach folgende Zeile in die Config.pm eintragen:

$Self->{CustomerUser}->{CustomerUserSearchFields}  = 
    [ 'login', 'first_name', 'last_name', 'customer_id', 'CONCAT( first_name, " ", last_name )' ];

Da OTRS die Felder einfach 1:1 übernimmt kann man hier beliebigen SQL-Code eintragen oder auch einfach nur neue Spalten hinzufügen. Ab sofort kann man auch nach Vor- und Nachname suchen:

Suche nach Vor- und Nachname nach der Änderung

Permalink:

Archiv

    Start 1 2 3 4 5 6