OTRS 3.3 Helpdesk Software Administrator-Handbuch

PDF

Document

Documentation

OTRS 3.3 -

Administrator-Handbuch

Build Date:

2013-04-30

OTRS 3.3 - Administrator-Handbuch

René Bakker, Stefan Bedorf, Michiel Beijen, Shawn Beasley, Hauke Böttcher, Jens Bothe, Udo Bretz, Martin Edenhofer, Carlos Javier García, Martin Gruner, Manuel Hecht, Christopher Kuhn, André Mindermann, Marc Nilius, Elva

María Novoa, Henning Oschwald, Martha Elia Pascual, Thomas Raith, Carlos Fernando Rodríguez, Stefan Rother,

Burchard Steinbild, Michael Thiessmeier, Daniel Zamorano.

Dieses Werk ist geistiges Eigentum der OTRS AG.

Es darf als Ganzes oder in Auszügen kopiert werden, vorausgesetzt, dieser Copyright-Vermerk befindet sich auf jeder Kopie.

Der Quellcode dieses Dokuments kann bei github gefunden werden, im Repository doc-admin .

UNIX ist ein eingetragenes Warenzeichen von X/Open Company Limited. Linux ist ein eingetragenes Warenzeichen von Linus Torvalds.

MS-DOS, Windows, Windows 95, Windows 98, Windows NT, Windows 2000, Windows XP, Windows 2003 und Windows Vista sind eingetragene Warenzeichen der Microsoft Corporation. Andere Warenzeichen oder registrierte

Warenzeichen: SUSE und YaST von SUSE Linux GmbH, Red Hat und Fedora von Red Hat Inc., Debian von Software in the Public Interest, Inc., Mandrake von MandrakeSoft, SA. MySQL und das MySQL Logo sind eingetragene

Warenzeichen Oracle Corporation und/oder verbundener Unternehmen.

Alle Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt und sind möglicherweise eingetragene Warenzeichen.

Die Firma OTRS AG richtet sich im Wesentlichen nach den Schreibweisen der Hersteller. Andere hier genannte

Produkte können Warenzeichen des jeweiligen Herstellers sein.

Inhaltsverzeichnis

Vorwort ......................................................................................................................... viii

1. Einführung .................................................................................................................. 1

1. Trouble-Ticket-Systeme - die Grundlagen ........................................................... 1

1.1. Was ist ein Trouble-Ticket-System, und warum benötigen Sie eins? ......... 1

1.2. Was ist ein Trouble-Ticket? ....................................................................... 2

2. OTRS-Helpdesk ................................................................................................... 2

2.1. Grundlagen .............................................................................................. 2

2.2. Features ................................................................................................... 3

2.3. Hardware und Software-Anforderungen ................................................. 11

2.4. Community ............................................................................................. 12

2.5. Kommerzieller Support und Dienstleistungen für OTRS ......................... 13

2. Installation ............................................................................................................... 14

1. Der einfache Weg - Installation fertiger Pakete ................................................ 14

1.1. Installation des RPM auf einem SuSE-Linux-Server ................................ 14

1.2. Installation von OTRS auf einem REd Hat Enterprise Linux oder CentOS-System .................................................................................................... 16

1.3. Installation von OTRS auf einem Debian- oder Ubuntu-System ............. 21

1.4. Installation von OTRS auf Microsoft Windows-Systemen ........................ 21

2. Manuelle Installation (Linux, Unix) ................................................................... 23

2.1. Vorbereiten der manuellen Installation .................................................. 23

2.2. Installation der für OTRS benötigten Perl-Module .................................. 24

2.3. Konfiguration des Apache-Webservers ................................................... 25

2.4. Einrichten der Datenbank ...................................................................... 26

2.5. Einrichten der von OTRS benötigten cron-Jobs ...................................... 27

2.6. OTRS Scheduler-Dienst .......................................................................... 30

3. Benutzen des Web-Installers ............................................................................ 31

4. Upgrade des OTRS Frameworks ....................................................................... 34

5. Upgrade mit dem Windows-Installer ................................................................ 38

5.1. Performing patch level upgrades on Windows ....................................... 39

5.2. Performing minor level upgrades on Windows ....................................... 39

6. Zusätzliche Applikationen ................................................................................ 39

6.1. FAQ ......................................................................................................... 39

3. Erste Schritte ........................................................................................................... 40

1. Agenten-Weboberfläche .................................................................................... 40

2. Kunden-Weboberfläche ..................................................................................... 40

3. Öffentliche Weboberfläche ............................................................................... 41

4. Die erste Anmeldung ....................................................................................... 41

5. Agenten-Weboberfläche - ein Überblick ........................................................... 42

6. Übersicht .......................................................................................................... 44

7. Was verbirgt sich hinter dem Begriff Queue? .................................................. 47

8. Was ist die Queue-Übersicht? .......................................................................... 48

9. Benutzereinstellungen ...................................................................................... 49

4. Administration .......................................................................................................... 51

1. Der Administrationsbereich von OTRS ............................................................. 51

1.1. Grundlagen ............................................................................................ 51

1.2. Benutzer, Gruppen und Rollen ............................................................... 51

1.3. Kundenbenutzer und Kundengruppen .................................................... 60

1.4. Queues ................................................................................................... 62

1.5. Anreden, Signaturen, Anlagen und Antwortvorlagen ............................. 64

1.6. Automatische Antworten ....................................................................... 73

1.7. E-Mail-Adressen ...................................................................................... 75

1.8. Benachrichtigungen ............................................................................... 76

1.9. S/MIME ................................................................................................... 78

1.10. PGP ...................................................................................................... 78

1.11. Status ................................................................................................... 79

iii

1.12. Die SysConfig (Verwaltung der Systemkonfiguration) .......................... 80

1.13. Einrichten von Mail-Konten .................................................................. 81

1.14. Einkommende E-Mail-Nachrichten filtern ............................................. 81

1.15. Ausführen von automatisierten Jobs mit Hilfe des GenericAgents ....... 84

1.16. Administrator-E-Mail ............................................................................. 86

1.17. Sitzungsverwaltung .............................................................................. 86

1.18. System Log .......................................................................................... 87

1.19. SQL-Abfragen mit Hilfe der SQL Box ................................................... 88

1.20. Paketverwaltung ................................................................................... 89

1.21. Web-Services ....................................................................................... 89

1.22. Dynamische Felder .............................................................................. 90

2. Systemkonfiguration ......................................................................................... 91

2.1. Die Konfigurationsdateien von OTRS ..................................................... 91

2.2. Konfiguration des Systems mit Hilfe des grafischen Konfigurations-Frontends ................................................................................................ 92

3. Datensicherung ................................................................................................ 93

3.1. Datensicherung ...................................................................................... 93

3.2. Wiederherstellung der Daten ................................................................. 93

4. Email-Einstellungen .......................................................................................... 94

4.1. E-Mails versenden/empfangen ............................................................... 94

4.2. Sichere E-Mail mit PGP .......................................................................... 99

4.3. Sichere E-Mail mit S/MIME ................................................................... 102

5. Einbinden externer Backends ......................................................................... 105

5.1. Kundenbenutzerdaten .......................................................................... 105

5.2. Kundenbenutzer Backend .................................................................... 105

5.3. Backends für die Authentifizierung von Agenten und Kunden ............. 113

5.4. Kunden-Selbstregistrierung anpassen .................................................. 116

6. Ticket-Einstellungen ........................................................................................ 118

6.1. Ticket Status ........................................................................................ 118

6.2. Ticket Prioritäten .................................................................................. 122

6.3. Ticket-Verantwortlicher und Beobachten von Tickets ........................... 122

7. Zeitabhängige Funktionen in OTRS ................................................................ 125

7.1. Arbeitszeiten, Feiertage und Zeitzonen für das System festlegen ....... 125

7.2. Automatische Ticket-"Freigabe" (unlock) ............................................. 126

8. Anpassen der PDF-Ausgabe ........................................................................... 126

9. Statistikmodul ................................................................................................. 127

9.1. Bedienung des Moduls durch den Agent ............................................. 127

9.2. Verwaltung des Statistik-Moduls durch den OTRS-Administrator ......... 137

9.3. Verwaltung des Statistik-Moduls durch den System-Administrator ...... 137

10. Dynamische Felder ....................................................................................... 140

10.1. Einführung .......................................................................................... 140

10.2. Konfiguration ...................................................................................... 140

11. Generic Interface .......................................................................................... 159

11.1. Generische Schnittstellenebenen ....................................................... 159

11.2. Generic Interface Kommunikationsfluss ............................................. 161

11.3. Web-Services ..................................................................................... 164

11.4. Web Service - Grafische Oberfläche .................................................. 164

11.5. Webdienst-Befehlszeilenoberfläche .................................................... 180

11.6. Webservice Konfiguration .................................................................. 181

11.7. Verbinder ............................................................................................ 188

12. OTRS Scheduler ............................................................................................ 201

12.1. Scheduler - Grafisches Interface ........................................................ 201

12.2. Scheduler-Befehlszeilenoberfläche ..................................................... 203

5. Anpassung .............................................................................................................. 207

1. Access Control Lists (ACLs) ............................................................................ 207

1.1. Einführung ............................................................................................ 207

1.2. Beispiele ............................................................................................... 207

1.3. Referenz ............................................................................................... 209

2. Prozess-Management ...................................................................................... 213

2.1. Einführung ............................................................................................ 213

2.2. Beispiel Prozess ................................................................................... 213

2.3. Implementierung des Beispiels ............................................................ 213

2.4. Prozesskonfigurationsempfehlung ........................................................ 237

3. Erstellung eigener Themes ............................................................................ 256

4. Übersetzung des OTRS-Frontends .................................................................. 256

6. Leistungsverbesserung .......................................................................................... 257

1. OTRS ............................................................................................................... 257

1.1. TicketIndexModule ............................................................................... 257

1.2. TicketStorageModule ............................................................................ 257

1.3. Tickets archivieren ............................................................................... 258

2. Datenbank ...................................................................................................... 258

2.1. MySQL .................................................................................................. 259

2.2. PostgreSQL ........................................................................................... 259

3. Webserver ...................................................................................................... 259

3.1. Persistente Datenbankverbindungen ................................................... 259

3.2. Vorgeladene Module - startup.pl .......................................................... 259

3.3. Perl Module bei Änderung neu laden ................................................... 259

3.4. Die richtige Strategie wählen .............................................................. 260

3.5. mod_gzip/mod_deflate ......................................................................... 260

A. Weitere Quellen ..................................................................................................... 261

1. Webseite OTRS Gruppe .................................................................................. 261

2. Mailinglisten .................................................................................................... 261

3. Fehler berichten ............................................................................................. 261

4. Kommerzieller Support ................................................................................... 262

B. Referenz der Konfigurationsoptionen ..................................................................... 263

1. DynamicFields ................................................................................................. 263

2. Framework ...................................................................................................... 268

3. GenericInterface ............................................................................................. 398

4. ProcessManagement ....................................................................................... 410

5. Scheduler ........................................................................................................ 418

6. Ticket .............................................................................................................. 421

C. Danksagungen ....................................................................................................... 652

D. GNU Free Documentation License ......................................................................... 654

0. PREAMBLE ...................................................................................................... 654

1. APPLICABILITY AND DEFINITIONS ................................................................... 654

2. VERBATIM COPYING ........................................................................................ 655

3. COPYING IN QUANTITY ................................................................................... 655

4. MODIFICATIONS .............................................................................................. 656

5. COMBINING DOCUMENTS ............................................................................... 657

6. COLLECTIONS OF DOCUMENTS ...................................................................... 657

7. AGGREGATION WITH INDEPENDENT WORKS .................................................. 658

8. Übersetzung ................................................................................................... 658

9. TERMINATION .................................................................................................. 658

10. FUTURE REVISIONS OF THIS LICENSE .......................................................... 658

How to use this License for your documents ..................................................... 659

Tabellenverzeichnis

2.1. Die verschiedenen Skripte für die cron-Jobs von OTRS. ....................................... 28

4.1. Standardmäßig vorhandene Gruppen in OTRS ..................................................... 52

4.2. Mit OTRS-Gruppen verknüpfte Rechte .................................................................. 55

4.3. Weitere Berechtigungsgruppen ............................................................................. 56

4.4. Ereignisse für automatische Antworten ................................................................ 74

4.5. Funktion der verschiedenen X-OTRS-Header ........................................................ 82

4.6. Die folgenden Felder werden zu dem System hinzugefügt: ................................ 142

4.7. Liste der init-Skripte und der unterstützten Betriebssysteme ............................. 203

A.1. Mailinglisten ........................................................................................................ 261

Liste der Beispiele

4.1. Aussortierung von Spammails in eine bestimmte Queue ..................................... 84

4.2. .fetchmailrc ............................................................................................................ 96

4.3. Beispiel-Jobs für das Filtermodul Kernel::System::PostMaster::Filter::Match ......... 97

4.4. Beispiel-Job für das Filtermodul Kernel::System::PostMaster::Filter::CMD ............. 98

4.5. Example job for the filter module

Kernel::System::PostMaster::Filter::ExternalTicketNumberRecognition ........................ 98

4.6. Konfiguration eines Datenbank-Kunden-Backends .............................................. 105

4.7. Firmen-Tickets mit einem Datenbank-Backend .................................................... 108

4.8. Konfiguration eines LDAP Kunden-Backends ....................................................... 108

4.9. Verwendung von Firmentickets mit einem LDAP-Backend .................................. 110

4.10. Gleichzeitige Einbindung mehrerer verschiedener Kunden Backends ............... 110

4.11. Agentenauthentifizierung gegen ein Datenbank-Backend ................................ 113

4.12. Agentenauthentifizierung gegen ein LDAP Backend ......................................... 113

4.13. Agentenauthentifizierung über HTTPBasic ........................................................ 114

4.14. Agentenauthentifizierung gegen ein Radius-Backend ....................................... 115

4.15. Kundenauthentifizierung gegen ein Datenbank-Backend .................................. 115

4.16. Kundenauthentifizierung gegen ein LDAP Backend .......................................... 115

4.17. Kundenauthentifizierung über HTTPBasic ......................................................... 116

4.18. Kundenauthentifizierung gegen ein Radius-Backend ........................................ 116

4.19. Festlegen einer Wertereihe bei einem Element ................................................ 135

4.20. Festlegen einer Wertereihe bei zwei Elementen ............................................... 135

4.21. Feld1 im Dialog NewPhoneTicket anzeigen ....................................................... 151

4.22. Activate Field1 in New Phone Ticket Screen as mandatory. Feld1 als verpflichtend in Dialog NewPhoneTicket setzen. ..................................................................... 152

4.23. Aktivieren von verschiedenen Feldern in der Oberfläche 'Neues Telefonticket'. ........................................................................................................................... 153

4.24. Deaktivieren von Feldern in der Oberfläche 'Neues Telefonticket'. ................... 154

4.25. Aktiviert Feld1 in der TicketZoom-Oberfläche. .................................................. 155

4.26. Aktiviert Feld1 in der kleinen Ticketübersicht. .................................................. 156

4.27. Aktiviert Feld1 im Event TicketCreate. .............................................................. 157

4.28. Aktiviert Field1 in den Benutzereinstellungen ................................................... 158

4.29. Ein Beispiel wie der OTRS Scheduler unter Linux gestartet wird. ..................... 203

4.30. Ein Beispiel wie der OTRS Scheduler gestartet wird. ........................................ 204

4.31. Beispiel für das erzwungene stoppen des OTRS Scheduler. ............................. 204

4.32. Ein Beispiel wie der OTRS Scheduler unter Windows als Service registriert wird. ............................................................................................................................ 205

4.33. Ein Beispiel wie der OTRS Scheduler unter Windows gestartet wird. ................ 205

4.34. Beispiel für das erzwungene stoppen des OTRS Scheduler unter Windows. ..... 206

5.1. ACL, die das Verschieben von Tickets in eine Queue nur bei einer Ticket-Priorität von 5 erlaubt. ....................................................................................................... 207

5.2. ACL, die das Verschieben von Tickets in eine Queue nur bei einer Ticket-Priorität von 5 erlaubt. ....................................................................................................... 208

5.3. ACL, die das Schließen von Tickets in der raw-Queue verbietet und den Schlie-

ßen-Schalter ausblendet. ........................................................................................... 208

5.4. ACL entfernt immer den Status Erfolgreich geschlossen .................................... 209

5.5. ACL, die nur Hardware-Services für Tickets anzeigt, die in Queues erstellt wurden, die mit "HW" beginnen. ..................................................................................... 209

5.6. Die Liste zeigt alle möglichen und wichtigen ACL-Einstellungen ........................ 210

vii

Vorwort

Dieses Buch soll das Leben von OTRS-Administratoren und -Neulingen erleichtern.

Die folgenden Kapitel beschreiben die Installation, Konfiguration und Administration von

OTRS. Das erste Drittel des Textes beschreibt die Hauptfunktionalität der Software, während der Rest als Referenz aller vorhandenen Konfigurationseinstellungen dient.

This book continues to be a work in progress, given a moving target on new releases. We need your feedback in order to make this a high quality reference document: one that is usable, accurate, and complete. Please write to us if you find content missing in this book, if things are not explained sufficiently, or even if you see spelling mistakes, grammatical errors, or typos. Any kind of feedback is highly appreciated and should be made via our bug tracking system on http://bugs.otrs.org

. Thanks in advance for your contributions!

viii

Kapitel 1. Einführung

1. Trouble-Ticket-Systeme - die Grundlagen

Dieses Kapitel enthält eine Kurzeinführung in Ticketsysteme, zusammen mit einer Erklärung des Kernkonzepts eines "Trouble-Tickets". Ein kurzes Beispiel illustriert die Vorteile der

Nutzung eines solchen Systems.

1.1. Was ist ein Trouble-Ticket-System, und warum benötigen Sie eins?

Das folgende Beispiel soll verdeutlichen, was ein Trouble Ticket System ist und wie Sie damit in Ihrem Unternehmen Zeit und Geld eingesparen können.

Max Mustermann ist ein Hersteller von Video-Rekordern. Herr Mustermann empfängt viele E-Mails von Kunden, die Hilfe benötigen. An manchen Tagen ist er aber nicht in der

Lage, zeitnah auf Nachrichten zu reagieren. Einige Kunden werden dann ungeduldig und schreiben eine zweite E-Mail mit derselben Frage. Alle diese Support-Anfragen werden unsortiert im Posteingang von Herrn Mustermanns E-Mail-Programm gespeichert, womit er die Anfragen auch abarbeitet.

Weil Herr Mustermann nicht schnell genug auf all diese E-Mails antworten kann, wird er dabei von den Entwicklern Meier und Schulze unterstützt, die das gleiche E-Mail-System nutzen und auf den gleichen Posteingang zugreifen. Sie berücksichtigen dabei aber nicht, dass Herr Mustermann oft zwei identische Anfragen vom gleichen Kunden erhält.

Manchmal kommt es vor, dass beide unabhängig voneinander auf die gleiche Anfrage antworten, was zur Folge hat, dass der Kunde zwei unterschiedliche Antworten erhält.

Des Weiteren weiß Herr Mustermann wiederum nicht, was seine Kollegen dem Kunden genau geantwortet haben. Außerdem kennt er weder die Details der Anfragen oder die

Lösungsvorschläge seiner Kollegen, oder wie oft bestimmte Probleme bei verschiedenen

Kunden auftreten und wie viel Zeit und Geld er für die Unterstützung von Kunden bereits verbraucht hat.

In einem Meeting erfährt Herr Mustermann von sogenannten Trouble-Ticket-Systemen und wie sie Herrn Mustermanns Probleme mit den Kunden-Anfragen lösen können. Nachdem er sich im Internet erkundigt hat, entscheidet sich Herr Mustermann, das frei verfügbare

Ticket-System "OTRS" auf einem Rechner zu installieren, der sowohl für seine Kunden, als auch für ihn und seine Mitarbeiter über das Internet erreichbar ist. Jetzt landen die Kunden-Anfragen nicht mehr in seinem persönlichen Posteingang, sondern direkt in einem

Mail-Account, der für OTRS eingerichtet wurde. Das Ticket-System speichert alle eingehenden E-Mails in seiner Datenbank. Für jede Anfrage generiert das System automatisch eine Antwort, so dass der Kunde weiß, dass seine Anfrage angekommen ist und bald beantwortet werden wird. OTRS erstellt dabei für jede Anfrage eine eindeutige Referenz

- die Ticket-Nummer. Die Kunden sind jetzt zufriedener, da sie wissen, dass ihre Anfragen berücksichtigt werden und senden keine Mehrfach-Anfragen mehr. Herr Mustermann und seine Kollegen können sich jetzt mit einem einfachen Web-Browser in OTRS anmelden und die Anfragen bearbeiten. Weil das System Tickets sperrt, die gerade beantwortet werden, wird keine Nachricht mehr versehentlich doppelt bearbeitet.

Stellen wir uns vor, dass Herr Schmidt eine Anfrage ans System gestellt hat und Herr Meier diese kurz und knapp beantwortet. Herrn Schmidt reicht diese Antwort jedoch nicht aus und so antwortet er auf die Lösungsmail am folgenden Tag. Herr Meier ist jedoch gerade mit anderen Dingen beschäftigt, so dass sich Herr Mustermann der Sache annimmt.

Über die History-Funktion von OTRS kann er jetzt auf alle vergangenen E-Mails von Herrn

Schmidt und Herrn Meier zugreifen, deren Inhalt abfragen und eine ausführlichere Antwort versenden. Herr Schmidt erhält nun die Lösung für sein Problem, weiß aber nicht, dass diese von unterschiedlichen Personen stammt.

Natürlich handelt es sich dabei um ein verkürztes Beispiel-Szenario, das nur einige der

Möglichkeiten und Features von Trouble Ticket-Systemen aufzeigt. Aber wenn Ihr Unternehmen eine große Anzahl von Kunden-Anfragen bewältigen muss und verschiedene Service-Mitarbeiter zu verschiedenen Zeiten auf diese Anfragen reagieren können müssen, kann ein Ticket-System sie dabei optimal unterstützen. Es hilft dabei, Arbeitsabläufe und

-Prozesse zu vereinheitlichen, effizienter zu machen und Ihre Produktivität insgesamt zu steigern. Ein Ticket-System hilft Ihnen, Ihren Support- oder Help-Desk-Bereich flexibel zu strukturieren. Kommunikations-Abläufe zwischen Kunden und Service-Mitarbeitern werden transparenter. Das Resultat ist eine gesteigerte Service-Effizienz. Und zweifelsohne bedeuten zufriedene Kunden auch finanziell bessere Ergebnisse für Ihr Unternehmen.

1.2. Was ist ein Trouble-Ticket?

Ein Trouble-Ticket lässt sich im Wesentlichen mit einem Krankenblatt eines Krankenhauspatienten vergleichen. Bei der erstmaligen Einlieferung in das Krankenhaus wird das Krankenblatt im Zuge der Anamnese neu angelegt. Jeder Arzt trägt nun seine Diagnose sowie die verordnete Therapie und Medikation ein und dokumentiert deren Erfolg. Das Krankenblatt gibt nun einen schnellen Überblick, gewährleistet eine schnelle Einarbeitung und verhindert eineMehrfachdosierung von Medikamenten. Ist die Krankheit besiegt und der

Patient entlassen, wird das Krankenblatt archiviert.

Im OTRS werden Trouble-Tickets, also die Krankenblätter aus dem obigen Beispiel, als normale E-Mails behandelt und gespeichert. Schickt ein Kunde eine Anfrage an das Trouble-Ticket-System, wird das Krankenblatt eingerichtet - ein neues Ticket wird geöffnet. Die

Antwort eines Mitarbeiters auf die Anfrage kann als Eintrag eines Arztes gesehen werden, eine erneute Antwort (bzw. Anfrage des Kunden auf dasselbe Ticket) als Veränderung oder

Erweiterung des Krankheitsbildes. Ein Ticket gilt als erledigt bzw. geschlossen, wenn eine

Antwort auf die Anfrage an den Kunden zurückgesendet wurde oder das Ticket über das

System als geschlossen markiert wird. Antwortet ein Kunde auf ein bereits geschlossenes

Ticket, wird es erneut geöffnet und um die neuen Informationen ergänzt. Um die Konsistenz der Daten sicherzustellen, werden alle Tickets mit all ihren spezifischen Informationen archiviert und verbleiben im System. Durch die Speicherung der Tickets als normale

E-Mails ist es möglich, dass diese auch E-Mail-Anhänge enthalten können. Zusätzlich zu den normalen Informationen einer E-Mail, lassen sich beliebige Notizen zu jedem Ticket hinzufügen. Die Tickets selbst werden auf der Festplatte bzw. in einer Datenbank archiviert, ebenso zusätzliche Meta-Informationen des Tickets wie Notizen, an der Beantwortung des Tickets beteiligte Mitarbeiter, Zeit und Datum der Bearbeitung, Bearbeitungsdauer usw. Eine Sortierung oder eine Suche über den Datenbestand wird mit Hilfe aller vorhandenen Informationen zu den Tickets realisiert.

2. OTRS-Helpdesk

In diesem Abschnitt werden die Features des Open Ticket Request Systems (OTRS) vorgestellt. Des Weiteren wird näher auf die Systemanforderungen von OTRS eingegangen und erläutert, wie Kontakt zur OTRS-Community aufgenommen werden kann bzw. wie kommerzieller Support erhältlich ist.

2.1. Grundlagen

OTRS Help Desk (OTRS) ist eine Webanwendung, die auf einem Webserver installiert und mit einem Browser genutzt wird.

OTRS ist in mehrere Komponenten aufgeteilt. Die Basis bildet ein Framework, das alle grundlegenden Komponenten für die Applikation und das Trouble-Ticket-System enthält.

Es können zusätzliche Komponenten wie das OTRS::ITSM-Modul, eine Knowledge-Base

(FAQ) oder Netzwerk-Überwachungs-Lösungen installiert werden.

2.2. Features

OTRS bietet viele verschiedene Features. Die folgende Aufzählung gibt einen Überblick

über die wichtigsten Eigenschaften und Fähigkeiten des OTRS-Frameworks.

2.2.1. Benutzeroberfläche

• OTRS enthält getrennte, moderne Benutzeroberflächen für Agenten und Kunden.

• Es kann mit jedem modernen Web-Browser und auf mobile Plattformen genutzt werden und ist für Retina-Bildschirme optimiert.

• Die Benutzeroberfläche kann mit Skins den eigenen Vorstellungen angepasst werden

(z.B. gemäß der Corporate Identity Ihres Unternehmens).

• Umfangreiches und anpassbares Agenten-Dashboard mit persönlichen Ticket-Übersichten und Unterstützung für grafische Statistiken.

• Eine erweiterbare Reporting-Engine stellt verschiedene Statistiken und zeitlich planbare

Reports zur Verfügung.

• Mit dem Prozess-Management ist es möglich, eigene Ticket-basierte Masken und Prozesse zu definieren (Ticket-Workflows).

• OTRS hat eine eingebaute Rechte-Verwaltung, die um hochgranulare Zugriffskontrolllisten (ACLs) ergänzt werden kann.

• Unterstützung in mehr als 30 Sprachen und verschiedenen Zeit Zonen.

2.2.2. E-Mail-Schnittstelle

• Unterstützung für MIME-E-Mails mit Anhängen.

• Automatische Umwandlung von HTML- in reine Text-Nachrichten (höhere Sicherheit vor schädlichen Inhalten und schneller durchsuchbar).

• Eingehende E-Mails können gefiltert und mithilfe komplexer Regeln vorverarbeitet werden, zum Beispiel zum Erkennen von Spam-Nachrichten und zur Verteilung in passende

Queues.

• Unterstützung für PGP- und S/MIME-Standards mit Schlüssel- und Zertifikatsverwaltung und E-Mail-Verarbeitung.

• Automatische Antworten, für jede Queue konfigurierbar.

• E-Mail-Benachrichtigungen für Agenten über neue Tickets, Follow-ups oder freigegebene Tickets.

• Es ist möglich, eigene Definitionen zur Erkennung von Folge-Kommunikation zu treffen

(z.B. Anruf#, Ticket# oder Anfrage#). Es stehen verschiedene Nummern-Generatoren

(Datumsbasiert, zufällig, etc.) zur Verfügung, außerdem können eigene Generatoren verwendet werden. Folge-Kommunikation kann außerdem anhand von In-Reference-To-

Header oder externen Ticket-Nummern erkannt werden.

2.2.3. Ticket

• OTRS nutzt Tickets, um interne und externe Kommunikation zu bündeln. Dieses Tickets sind wiederum in Queues organisiert.

• Es gibt verschiedene Möglichkeiten (z.B. Queue-, Status- oder Eskalationsbasiert) und verschiedene Detailgrade (klein/mittel/Vorschau) zum Betrachten von Tickets im System.

• Die Ticket Historie speichert alle Änderungen am Ticket.

• Tickets können zum Beispiel durch Antworten, Weiterleiten, Umleiten, Verschieben in eine andere Queue, Ändern von Attributen (Status, Priorität, etc.), Sperren oder Einbuchen von Zeiteinheiten bearbeitet werden. Es ist auch möglich, mehrere Tickets gleichzeitig zu bearbeiten (Stapelverarbeitung).

• "Warten bis"-Zeiten, Eskalationszeiten und das SLA-Management ermöglichen zeitgesteuerte Planung und Einschränkungen für Tickets.

• Tickets können mit anderen Tickets oder generischen Objekten (z.B. FAQ-Artikeln) verlinkt werden.

• Automatische und zeitgesteuerte Aktionen können mit Hilfe eines sog. "GenericAgent" auf Tickets ausgeführt werden.

• OTRS enthält eine mächtige Suchfunktion, die komplexe und Volltextsuchen auf Tickets ermöglicht.

2.2.4. System

• OTRS unterstützt viele Betriebssysteme (Linux, Solaris, AIX, FreeBSD, OpenBSD, Mac

OS 10.x, MS Windows) und Datenbanksysteme für das zentrale OTRS-Backend (MySQL,

PostgreSQL, Oracle, MSSQL).

• Der OTRS-Kern kann durch Installation von Paketen erweitert werden. Viele Pakete sind frei verfügbar (wie FAQ, OTRS::ITSM etc.), zusätzlich stehen weitere Pakete als Feature-AddOns für Service-Kunden der OTRS-Gruppe zur Verfügung.

• Integration von externen Backends für Kundendaten, z.B. Active Directory, eDirectory oder OpenLDAP. Kunden können sich per Datenbank, LDAP, HTTPAuth oder Radius authentifizieren.

• Mit dem GenericInterface ist es leicht möglich, OTRS mit anderen Web-Services zu verbinden. Einfache Web-Services können ohne Programmieraufwand angebunden werden, komplexe Szenarios mithilfe von eigenen Anpassungen. Der OTRS Ticket-Connector erlaubt die Erstellung und Aktualisierung von, sowie die Suche nach Tickets aus

Dritt-Applikationen via Web-Service.

Nachfolgend finden Sie einen Überblick über Veränderungen in den letzten Versionen von

OTRS.

2.2.5. Neue Features von OTRS 3.3

2.2.5.1. Produktivität

• Ticketlisten im Dashboard und regulären Übersichten können jetzt anhand von auswählbaren Spalten gefiltert und sortiert werden; die anzuzeigenden Spalten sind konfigurierbar.

• Die medium- und Vorschauansicht der Ticketübersichten sind jetzt sortierbar.

• Es wurde ein Kalender-Widget zum Dashboard hinzugefügt, das Tickets als Ereignisse anzeigen kann.

• Es wurde ein Widget zum Dashboard hinzugefügt, das Tickets pro Status und Queue in

Form einer Matrize anzeigen kann.

• Agenten können nun wichtige Artikel markieren.

• Ein neues Baumauswahl-Widget erleichtert und beschleunigt die Arbeit mit verzweigten

Daten (Queues, Services, etc.).

• Unterstützung für die Suche nach relativen Zeiträumen (z.B. "vor mehr als einem

Monat") für dynamische Datums- und Datum-Zeit-Felder hinzugefügt.

• Es ist nun möglich, Vorlagen (vorher "Standard-Antworten") auch für die Erstellung neuer oder Weiterleitung bestehender Tickets zu definieren.

• Die Liste verfügbarer Prozesse kann nun per ACL gefiltert werden.

• Starten von Prozessen nun auch über die Kunden-Oberfläche möglich.

• An vielen Stellen wird Text nun nicht mehr nach einer festen Anzahl von Zeichen abgeschnitten, sondern abhängig vom verfügbaren Platz auf dem Bildschirm. So wird mehr

Information sichtbar dargestellt.

• OTRS ist jetzt für Retina-Bildschirme geeignet. Bilder wurden für höhere Auflösungen angepasst und viele Symbole durch Schriftzeichen aus der FontAwesome-Schriftart ersetzt.

• Mithilfe des neuen "Management-Dashboard"-Features ist es jetzt möglich, grafische

Statistiken (z.B. als Balken- oder Linien-Diagramm) im Dashboard anzuzeigen. Hinweis:

Dieses Feature wird vom IE8 nicht unterstützt.

2.2.5.2. Arbeiten mit externen Systemen

• OTRS kann nun mehrere Kundenfirmen-Datenbanken nutzen (Danke an Cyrille @ belnet-ict).

• OTRS kann nun Kundendaten automatisch (permanent) in dynamischen Feldern speichern. Dies ist hilfreich für Reportingzwecke.

• OTRS kann nun eingehende E-Mails korrekt bestehenden Tickets anhand von externen

Ticketnummern zuordnen.

• OTRS kann nun auch E-Mails über POP3/TLS-Verbindungen abholen.

2.2.5.3. Installation & Administration

• Der Web-Installer kann OTRS nun (zusätzlich zu MySQL) auch auf PostgreSQL-, Oracleund SQL-Server-Datenbanken installieren.

• OTRS unterstützt MySQL 5.6 nun vollständig.

• Generic Agent-Aufgaben können jetzt bei konfigurierten Ticket-Ereignissen ausgeführt werden.

• Der neue grafische ACL-Editor erleichtert das Bearbeiten von Zugriffskontrolllisten

(ACLs).

• Postmaster-Filter können jetzt negierte Filterbedingungen verwenden (Danke an Renée

Bäcker).

• Postmaster-Filter können jetzt relative "Warten bis"-Zeiten und Besitzer/Verantwortlichen für neue Tickets auf Basis von eingehenden E-Mail-Daten festlegen.

• Kunden- und Agentenpasswörter können jetzt mit dem (im Vergleich zu SHA) stärkeren bcrypt-Algorithmus verschlüsselt werden.

• Viele Symbole wurden durch Schriftzeichen ersetzt, was das Erstellen eigener Skins mit angepasster Farbgebung stark erleichtert und zudem die Ladezeiten verbessert.

2.2.6. Neue Features von OTRS 3.2

2.2.6.1. Stärkerer Fokus auf Kunden

• Das neue "Kunden-Informationszentrum" bietet eine schöne Ansicht auf einen Kunden

(bzw. die Kundenfirma). Sie können

• Listen zeigen jetzt eskalierte, neue und offene Tickets der Kundenfirma und solche, die die Erinnerungszeit erreicht haben.

• Kundenbenutzer (Kontakte), die zu dieser Firma gehören, mit ihren individuellen

Ticketzahlen und Shortcuts zur Erstellung von neuen Tickets für diese Nutzer.

• Eine allgemeine Ticket-Statusübersicht für diese Kundenfirma.

• Das neue "Zu Kunde wechseln"-Feature ermöglicht es Agenten, die über die notwendigen Berechtigungen verfügen, die Kunden-Oberfläche aus Sicht des jeweiligen Kunden zu betrachten.

2.2.6.2. Höhere Anpassbarkeit

2.2.6.2.1. Prozess-Management

• Das neue Prozessmanagement macht es möglich, Prozesse in OTRS abzubilden.

2.2.6.2.2. Verbesserungen der Kundenoberfläche

• Die Kundenoberfläche unterstützt jetzt AJAX und ACLs umfassend.

• Die Kundenoberfläche setzt nun JavaScript voraus und ist nicht mehr kompatibel zu

Internet Explorer 6 (und älter).

• In der Kundenoberfläche können Sie jetzt den Standard-Tickettyp für neue Tickets einstellen. Zusätzlich kann der Ticket-Typ versteckt werden, wobei alle Tickets mit dem

Standard-Ticket-Typ erstellt werden.

2.2.6.2.3. Verbesserungen in der Agenten-Oberfläche

• Agenten können Tickets nun nach der Eskalationszeit suchen.

• Es ist nun möglich, dynamische Felder standardmäßig in der Ticketsuche anzuzeigen.

• Verbesserte Bildschirmnutzung in den Ticketmasken, durch die unnötiges Scrollen vermieden wird. In jeder Maske kann die Größe des Rich-Text-Editors jetzt separat konfiguriert werden.

• Es ist nun möglich, Tickets aus den Ticketmasken heraus in eine andere Queue zu verschieben (z. B. aus Ticket Schließen), nachdem eine Konfigurationsoption aktiviert wurde. Dies ist standardmäßig nicht aktiviert.

• Die Ticketsuche leitet nun direkt zur Detailansicht (Zoom) des gefundenen Tickets um, wenn nur ein Ticket gefunden wurde.

• Es ist nun möglich, die Artikeltyp-Auswahl in TicketActionCommon-basierten Masken auszublenden, was es ermöglicht, mehr Daten in der jeweiligen Maske sichtbar zu machen.

• Es gibt ein neues "Out of Office" Widget im Dashboard, welches alle Agenten-Kollegen auflistet, die derzeit nicht verfügbar sind.

• Der neue CKEditor 4 macht das Arbeiten mit Rich-Text-Inhalten (wie HTML-Mails) leichter und stabiler.

2.2.6.2.4. Administrative Verbesserungen

• Ereignisbasierte benachrichtigungen können nun nur für besteimmte Artikel-Sender-Typen versendet werden.

• Die Statistik-Engine von OTRS kann nun zusätzlich zu Tagen, Monaten und Jahren auch mit Wochen umgehen. Dies gestattet es beispielsweise, Reports über alle Tickets, die

(in einer bestimmten Queue) "in der letzten Woche" eröffnet wurden, zu erstellen.

• Es ist nun möglich, angepasste DTL (Template)-Dateien in Custom/Kernel/Output/HTML abzulegen. Diese überschreiben dann die Dateien des Systems, genau wie dies bereits auch mit Perl-Dateien möglich ist.

• AdminSMIME kann nun Zertifikate in menschenlesbarer Form anzeigen.

• In der SysConfig können nun Datum und Datum+Zeit als Konfigurationstypen verwendet werden.

2.2.6.3. Bessere Skalierfähigkeit

2.2.6.3.1. Ticket-Archivierung verbessert

• Wenn tickets archiviert werden, wird die Information, welcher Agent das Ticket bereits gelesen hat, gelöscht, genau wie die Information, welche Agenten das Ticket beobachten. Diese Einstellung ist standardmäßig aktiv und reduziert die Datenmenge, die in großen Systemen mit vielen Tickets und Agenten anfällt.

• Es steht auch ein Skript zur Verfügung, welches diese Daten aus bereits archivierten

Tickets entfernt.

• Archivierte Tickets werden nun immer als bereits vom Agenten gelesen angezeigt.

2.2.6.3.2. Performance-Verbesserungen

• Die Sitzungsverwaltung von OTRS ist nun bis zu 10-mal schneller, besonders bei vielen aktiven Nutzern.

• Es ist möglich, die Zahl der gleichzeitig aktiven Agenten und/oder Kunden zu beschränken, um eine Überlastung des Servers zu vermeiden.

• Signifikante Reduzierung der Anzahl an ausgeführten Datenbankabfragen in Ticketübersichten und Ticketmasken in Agenten- und Kundenoberfläche.

• Dies wird die Last auf Datenbankservern reduzieren, besonders auf großen Systemen.

In manchen Fällen wird OTRS dadurch auch sichtbar schneller.

• Die Geschwindigkeit der LDAP-Benutzersynchronisation wurde verbessert.

• Die Geschwindigkeit des Caches im Umgang mit vielen Dateien wurde erhöht.

2.2.6.4. Bessere Zusammenarbeit mit Fremdsystemen

2.2.6.4.1. FAQ-Connector für das GenericInterface

• Es ist nun möglich, die Daten des FAQ-Moduls (OTRS-Wissensdatenbank) mittels Webservice (GenericInterface) zu nutzen. Damit können FAQ-Artikel zum Beispiel zusätlich in Ihrer Unternemenswebsite angezeigt werden.

2.2.7. Neue Features von OTRS 3.1

2.2.7.1. GENERIC INTERFACE - Ein Webservice Framework

• Der GI ist ein flexibles Framework, um Webservice Erstellung (Verbindung mit externen

Services) zu erleichtern und ermöglichen.

• OTRS fungiert jeweils als Provider (Server - remote Anfragen beantworten) und Requester (Client - remote Abfrage stellen).

• Einfache Web Services können auch ohne Programmierkenntnisse über die Konfiguration des Generic Interface umgesetzt werden.

• Komplexe Szenarien können über individuelle OTRS Erweiterungen realisiert werden.

Diese erweitern das Generic Interface um den notwendigen Perl Code.

• Konnektoren erlauben den Zugriff auf OTRS über die Web Services des Generic

Interface. Beispielsweise erlaubt der Ticket Konnektor das erstellen/aktualisieren von

Tickets, so dass diese, unabhängig vom Netzwerk Transport in einem Web Service verwendet werden können.

• Der Scheduler-Daemon unterstützt das asynchrone ausführen von Ereignissen. Das ist hilfreich um Webservice-Anfragen von OTRS an ein anderes System zu starten, nachdem die Agentenanfrage beantwortet wurde (z.B.: nachdem ein Ticket erstellt wurde).

Ansonsten kann es passieren das die Anfrage blockiert wird, das resultiert wiederrum in einer erhöhten Antwortzeit für den Agenten.

Mit dem Generic Interface können neue Web-Services ohne zusätzlichen Programmcode mithilfe bestehender OTRS-Module konfiguriert werden. Sie können auch kombiniert werden, um einen neuen Web-Service zu erstellen. Beim Konfigurieren einer neuen Web-Service-Verbindung muss ein Administrator folgendes hinterlegen:

• Ein neuer Web Service in der Admin Oberfläche

• Die grundlegenden Meta Daten (Transport Typ (SOAP), URL, etc.) und

• Existierende Operations (Teil eines Connectors) spezifizieren für jede Operation wie die

Daten zugeordnet werden müssen (eingehend und ausgehend)

Ein Generic Interface Debugger hilft dem OTRS Administrator dabei zu überprüfen, wie

Anfragen eingehen und wie diese in den verschiedenen Ebenen des GI behandelt werden.

2.2.7.1.1. Aktuelle Features

• Netzwerkprotokolle: SOAP/HTTP. Andere wie REST und JSON werden in der Zukunft, je nach Kundenbedarf, hinzugefügt

• Konfigurierbares grafisches Daten-Mapping-Benutzerinterface für Schlüssel/Werte-Transformationen in Bezug auf eingehende und ausgehende Daten.

• Grafischer Debugger um die Konfiguration und den Informationsfluss des erstellten

Webservices zu überprüfen.

• Ein Ticketconnector erlaubt die Benutzung von OTRS als ein Webservice für die Tickethandhabung

2.2.7.1.2. Zukünftige Features

• Weitere Netzwerkprotokolle (REST,JSON)

• Das Generic Interface ersetzt das iPhoneHandle als Backend für Mobile-Anwendungen

• Zusätzliche Konnektoren werden in der Zukunft zur Verfügung gestellt, damit ein grö-

ßerer Teil von OTRS über Web Service angesprochen werden kann (bspw. die Erstellung,

Aktualisierung oder Löschung von Agenten, Benutzern, Services oder CIs).

2.2.7.2. Dynamische Felder

Die Dynamischen Felder ersertzen die existierenden Ticket- und Artikel-FreiText-Felder und Zeit-Felder durch eine dyanmische Struktur. Diese erlaubt zudem die Erstellung indiviudeller Eingabeformulare in OTRS.

• Eine unbegrenzte Anzahl von Feldern kann vom Administrator über ein grafisches

Benutzerinterface konfiguriert werden.

• Die Felder können verschiedene Typen haben, welche sowohl für Tickets, als auch für

Artikel verwendet werden können. Standardmäßig verfügbar sind:

• Text

• Mehrzeiliger Text

• Kontrollkästchen

• Einfachauswahl

• Mehrfachauswahl

• Datum

• Datum/Zeit

• Neue eigene Feldtypen (bpsw. eigener Feldtyp 'dropdown' mit einer externen Datenquelle) können mit wenig Aufwand hinzugefügt werden, da die Felder modular angelegt werden.

• Ein zukünftiges Szenario könnte sein, dass dynamische Felder für nicht Ticket-Objekte oder in eigenen Modulen benutzt werden könnten. Zum Beispiel: ein eigenes Modul fügt

Objekte hinzu um "Bestellungen" in OTRS zu verwalten. OTRS kann dynamische Felder verwenden, um diese Eigenschaften/Daten anzufügen.

• Ein Datenbank Update Skript transformiert historische FreiText Felder und die zugehörigen Konfiguration in die neue Struktur.

2.2.7.3. VERBESSERUNGEN IM TICKET MANAGEMENT

2.2.7.3.1. Ticketerstellung verbessert

• Mehrere Email Adressen können nun spezifiziert werden als 'An:', 'Cc:' oder 'Bcc:' wenn ein neues Telefon- oder Email-Ticket erzeugt wird.

2.2.7.3.2. Unterstützung für eingehende Telefonanrufe

• Eingehende Telefonanrufe können nun innerhalb eines existierenden Tickets erfasst werden (bsiher konnten nur ausgehende Telefonanrufe erfasst werden).

2.2.7.3.3. Ticket Übersicht Vorschau wurde verbessert

• Es ist nun möglich Artikel mit einem bestimmten Sendertypen (bspw. Artikel von interen

Agenten) über die SysConfig von der Anzeige in der Übersicht auszuschließen.

• Artikel eines bestimmten Typs können standardmäßig expandiert dargestellt werden.

Dies ist konfigurierbar.

2.2.7.3.4. Ticket verschieben verbessert.

• Die Anzeige, die nach dem Verschieben eines Tickets erscheinen soll kann nun konfiguriert werden. Möglich ist entweder der Ticket Zoom (LastScreenView) oder die Ticket

Liste (LastScreenOverview).

2.2.7.3.5. Sammel-Aktion verbessert

• Mit der neuen Sammelaktion, können augehende E-Mails nun von mehreren Tickets gleichzeitig versendet werden. Weil Tickets unterschiedliche Queues besitzen können und diese Queues wiederrum unterschiedliche Templates, Anreden und Signaturen, werden diese nicht in der E-Mail Sammelaktion verwendet.

• Eine zusätzliche Sammelaktion erlaubt die Konfiguration von Ticket Typen für die ausgewählten Tickets.

2.2.7.3.6. Konfigurierbare ablehnbare Absender-E-Mail-Adressen

• Diese Funktion erlaubt das Konfigurieren einer E-Mailadresse, die verwendet wird um zu verhindern das neue Tickets per E-Mail angelegt werden. Diese Fuktion kann überall verwendet werden, wo es Kunden nicht erlaubt ist neue Tickets per E-Mail anzulegen.

2.2.7.4. Prozessautomatisierung

2.2.7.4.1. Eskalationsereignisse hinzugefügt

• OTRS erstellt nun Ereignisse für jede der verfügbaren Eskalationsarten (Antwort, Update und Lösung). Dies erlaubt nun Aktionen (wie z.B. Benachrichtigungen) auszuführen bevor die Eskalation auftritt, während sie auftritt und in dem Moment wenn die Eskalation endet.

2.2.7.4.2. Benachrichtigungsmechanismus verbessert

• Ein neues Generic Agent Benachrichtigungsmodul erlaubt dem OTRS Administrator

Nachrichten zu definieren, die angezeigt werden sobald sich ein Agent im Agenten-Interface anmeldet.

2.2.7.4.3. Zeitberechnung verbessert

• Alle Arten von Zeiten werden nun anhand des Anwendungsserver berechnet. Das löst eventuelle Probleme, die durch die Abweichungen der Taktzeiten zwischen den Anwendungs- und Datenbank-Servern verursacht wurden.

2.2.7.4.4. GenericAgent verbessert

• Der GenericAgent kann nun nach "Ticket Change time" filtern.

• Weiterhin kann der GenericAgent bei Übereinstimmung einen Ticketverantwortlichen setzen.

2.2.7.5. Benutzeroberfläche, RichTextEditor, Charset

2.2.7.5.1. Benutzeroberflächengeschwindigkeit verbessert

• Die Geschwindigkeit für die Darstellung und Artikelanzeige wurde verbessert, danke

Stelios Gikas < [email protected]>!

2.2.7.5.2. Rich Text Editor aktualisiert

• IOS5 Unterstützung hinzugefügt

• Zitate können mit der Enter-Taste verlassen werden.

• Update von CKEditor 3.4 auf CKEditor 3.6, diese Verbesserungen beziehen sich auf die

Versionen CKEditor 3.5

und CKEditor 3.6

• IE9 Unterstützung verbessert.

• Größen veränderbare Dialoge.

2.2.7.5.3. Unicode-Unterstützung - Nicht-UTF-8 Kodierung entfernt

• UTF-8 ist nun der einzig erlaubte Zeichensatz im OTRS.

• Alle Sprachdateien sind nun in UTF-8 formatiert, was die Benutzung und zukünftige

Verbesserungen des Übersetzungs-Mechanismus vereinfacht.

2.2.7.6. Unterstützung von Datenbank Treibern

2.2.7.6.1. Verbesserte PostgreSQL Treiber kompatibilität

• PostgreSQL 9.1 Unterstützung hinzugefügt.

• Ein neuer Legacy-Treiber ist nun für PostgreSQL 8.1 oder ältere Versionen verfügbar.

2.2.7.6.2. Verbesserte MS SQL Treiber Kompatibilität

• Der MS SQL-Treiber speichert Binärdaten nun in VARBINARY-Zeichenfolgen anstatt in

TEXT-Zeichenfolgen oder NVARCHAR Zeichenfolgen anstatt VARCHAR-Zeichenfolgen

(für bessere Unicode-Unterstützung).

2.2.7.7. MAIL integration

2.2.7.7.1. Mailverwaltung verbessert

• Wenn Sie zu IMAP E-Mailkonten verwenden, ist es nicht möglich E-Mails aus einem speziellen E-Mailordner, neben dem INBOX-Ordner, zu verwenden,

• OTRS kann sichere Verbindungen zu IMAP-Servern über Transport Layer Security (TLS) aufbauen.

2.3. Hardware und Software-Anforderungen

OTRS kann auf vielen Betriebssystemen installiert werden. OTRS kann auf Linux und den verschiedenen Unix-Derivaten (z. B. OpenBSD oder FreeBSD) betrieben werden. Ebenfalls läuft OTRS auch unter allen Windows-Versionen. Bezüglich der Hardware empfiehlt es sich, mindestens einen 2 GHz Pentium Xeon oder vergleichbare CPU, 2 GB RAM und eine

160 GB Festplatte zu verwenden.

Um OTRS zu betreiben, wird ein Web- sowie ein Datenbankserver benötigt. Weiterhin ist eine funktionierende Perl-Installation mit einigen Zusatzmodulen die Grundvorraussetzung für ein funktionierendes System. Der Webserver und Perl müssen auf der gleichen

Maschine installiert sein, auf der später auch OTRS ausgeführt werden soll. Das Datenbank-Back-End kann auf der lokalen oder auf einer entfernten Maschine installiert werden.

Für den Webserver empfehlen wir die Verwendung von apache 2. Durch die Verwendung des Modules mod_perl, kann die Geschwindigkeit von OTRS enorm gesteigert werden.

Prinzipiell sollte OTRS aber auf jedem Webserver betrieben werden können, der die Ausführung von Perl-Skripten unterstützt.

Sie können OTRS auf verschiedenen Datenbanksystemen verwenden. OTRS unterstützt aktuell MySQL, PostgreSQL, Oracle, oder Microsoft SQL Server. Wenn Sie MySQL als Datenbank im Einsatz haben, haben Sie den Vorteil das die Datenbank- und einige Systemeinstellung über ein Webfrontend konfiguriert werden können.

Für Perl gilt mindestens die Version 5.8.8 zu verwenden. Es werden einige Zusatzmodule benötigt, die Sie entweder direkt über die Shell von Perl und CPAN oder mit Hilfe des

Paketmanagers (yast, apt-get) Ihres Betriebssystems einspielen müssen.

Software-Anforderungen

2.3.1. PERL Unterstützung

• Perl 5.10 oder höher

2.3.2. Web Server Unterstützung

• Apache2 + mod_perl2 oder höher (empfolen)

• Webserver mit CGI support (CGI nicht empfohlen)

• Microsoft Internet Information Server (IIS) 6 oder höher

2.3.3. Datenbankunterstützung

• MySQL 5.0 oder höher

• PostgreSQL 8.0 oder höher (8.2 oder höher empfohlen)

• Oracle 10g oder höher

• Microsoft SQL Server 2005 oder höher

Im Abschnitt für die Installation der für OTRS benötigten Perl-Module wird beschrieben,

wie Sie Perl-Module manuell einspielen können.

Wenn Sie ein bereits vorgefertigtes OTRS-Paket für Ihr Betriebssystem zur Installation verwenden (rpm, Windows-Installer), sollten die benötigten Perl-Module automatisch installiert werden.

2.3.4. Webbrowser-Unterstützung

Um OTRS zu benutzen benötigen Sie einen modernen Browser mit eingeschaltetem JavaScript Support. Die folgenden Browser werden nicht unterstützt:

• Internet Explorer vor Version 8

• Firefox vor Version 10

• Safari vor Version 5

Wir empfehlen immer die neueste Version Ihres Browser zu benutzen, da diese die beste

JavaScript- und Rendering-Leistung besitzt. Mit großen Datenmengen oder großen Systemen können signifikante Performace-Unterschiede zwischen den verwendeten Browsern auftreten. Wir beraten Sie gerne über dieses Thema.

2.4. Community

Um OTRS hat sich in den letzten Jahren eine große Community gebildet. Über Mailinglistentauschen sich Anwender und Entwickler zu den verschiedensten Themen rund um das

Trouble Ticket System aus. Behandelt werden Fragen rund um die Installation, Konfiguration, Benutzung, Lokalisation und Entwicklung. Fehler in der Software können über ein

Bug Tracking System gemeldet werden und erreichen so die zuständigen Entwickler bzw.

gehen nicht verloren, so dass schnell Fixes bereit gestellt werden können.

Die Webseite der OTRS-Community ist: http://www.otrs.com/open-source/ .

2.5. Kommerzieller Support und Dienstleistungen für OTRS

Wenn Sie Hilfe bei der Konfiguration oder Anpassung von OTRS benötigen oder Sie auf der sicheren Seite sein wollen, zögern Sie nicht uns zu kontaktieren: Wir bieten eine breite Palette von professionellen Dienstleistungen, wie weltweiten Enterprise-Support,

Consulting und Engineering einschließlich Prozess-Design, Implementierung, Anpassung,

Anwendungsunterstützung und vollständig verwalteten Service an.

Unsere Service Verträge garantieren sofortige Hilfe und professionelle Unterstützung und nicht zu vergessen freien Zugang zu OTRS Feature Add-Ons - hilfreiche zusätzliche Funktionen für Ihr OTRS.

Die OTRS Group bietet Trainingsprogramme in verschiedenen Ländern an. Sie können entweder an einem unserer regelmäßig stattfindenen öffentlichen OTRS Administrator-Trainings teilnehmen oder an einer Inhouse-Schulung, die alle spezifischen Anforderungen

Ihres Unternehmens abdeckt.

Kapitel 2. Installation

Dieser Abschnitt beschreibt die Installation und die grundlegende Einrichtung des zentralen

OTRS Frameworks. Dabei wird die Installation von OTRS aus dem Quellcode erläutert, wie auch über Binärpakete wie RPM oder ausführbare Dateien für Windows.

Dieses Kapitel beschreibt die Einrichtung des Web- und Datenbankservers, die Schnittstelle zwischen OTRS und der Datenbank, das Einspielen einzelner Perl-Module, das Setzen der richtigen Berechtigungen, die Einrichtung der OTRS-eigenen cron-Jobs sowie grundlegende

Einstellungen in den OTRS-Konfigurationsdateien.

Folgen Sie den Schritten in diesem Kapitel, um OTRS auf Ihrem Server zu installieren. Dann können Sie sich über die Weboberfläche anmelden und das System administrieren.

1. Der einfache Weg - Installation fertiger Pakete

If available for your platform you should use pre-built packages to install OTRS, since it is the simplest and most convenient method. You can find them in the download area at http://www.otrs.com

. The following sections describe the installation of OTRS with a prebuilt or binary package on SUSE, Red Hat and Microsoft Windows systems. Only if you are unable to use the pre-built packages for some reason should you follow the manual process.

1.1. Installation des RPM auf einem SuSE-

Linux-Server

This section describes the installation of our RPM package on a SUSE Linux server. We have tested against all recent SLES and openSUSE versions. Before you start the installation, please visit http://www.otrs.com/downloads and make sure you use the latest OTRS RPM package available.

1.1.1. Vorbereiten der Datenbank für OTRS

You can use OTRS using different database back-ends: MySQL, PostgreSQL, Oracle or

Microsoft SQL Server. The most popular database to deploy OTRS on is MySQL. This chapter shows the steps you need to take to configure MySQL on a SUSE-based server. Of course you can install the database on a dedicated database server if needed for scalability or other purposes.

Anmerkung

If you follow this chapter on openSUSE 12.3 and up you'll actually not install MySQL but MariaDB instead, a MySQL compatible fork of the MySQL code. This is no problem, it will work just as well (and even a little better at some points).

Installieren Sie MySQL als root mit folgenden Befehl:

linux:~ # zypper install mysql perl-DBD-mysql

This will install MySQL with the default options on your system. You'll need to change the defaults in order to make it suitable for OTRS. With a text editor open the file /etc/my.cnf

and change the line with max_allowed_packet on it, and add a line below, like this:

max_allowed_packet=20M query_cache_size=32M

Now execute rcmysql restart to re-start the database server and activate these changes. Then run /usr/bin/mysql_secure_installation and follow the on-screen instructions to set a database root password, remove anonymous access and remove the test database. Lastly, run chkconfig -a mysql in order to make sure mysql is automatically started at server startup time.

1.1.2. OTRS installieren

Install OTRS with via the command line using zypper. This will also pull in some dependencies such as the apache web server and some Perl modules. Make sure you copied the OTRS RPM file to the current directory.

otrs-sles:~ # zypper install otrs-3.3.*.rpm

....

Retrieving package otrs-3.3.3-01.noarch (1/26), 17.5 MiB (74.3 MiB unpacked)

Installing: otrs-3.3.3-01 [done]

Additional rpm output:

Check OTRS user ... otrs added.

Next steps:

[start database and Apache]

Make sure your database is running and execute 'rcapache2 restart'.

[install the OTRS database]

Use a webbrowser and open this link: http://myserver.example.com/otrs/installer.pl

[OTRS services]

Start OTRS 'rcotrs start-force' (rcotrs {start|stop|status|restart|start-force| stopforce}).

((enjoy))

Your OTRS Team http://otrs.org/ otrs-sles:~ #

Skript: Kommando für die Installation von OTRS.

Die OTRS-Installation ist fertig. Starten Sie Ihren Webserver neu, wie im unteren Skript gezeigt, um die OTRS spezifischen Änderungen zu laden. Ebenfalls sollten Sie den Befehl

chkconfig aufrufen, um sicherzustellen das OTRS automatisch startet, wenn der Webserver neu gestartet wird.

otrs-sles:~ # chkconfig -a apache2 apache2 0:off 1:off 2:off 3:on 4:off 5:on 6:off otrs-sles:~ # rcapache2 start

Starting httpd2 (prefork) httpd2-prefork: Could not reliably determine the server's fully

qualified domain name, using 10.x.x.x for ServerName done otrs-sles:~ #

Skript: Starten des Webservers.

1.1.3. Installation zusätzlicher Perl-Module

OTRS needs some more modules than can be installed by the RPM. You can post-install them manually. You can check what modules you are missing by running the bin/ otrs.CheckModules.pl

script located in the /opt/otrs directory. Some modules are only needed for optional functionality, such as communication with IMAP(S) servers or PDF

generation. On SLES you should add an external repository to the zypper configuration in order to get the modules needed for your system. Choose the module needed for your

OS version from here: http://download.opensuse.org/repositories/devel:/languages:/perl/ .

Add the repository like this for SLES 11 SP2:

zypper ar -f -n perl http://download.opensuse.org/repositories/devel:/languages:/perl/

SLE_11_SP2 Perl

On openSUSE 12.3 the extra repository is only needed for the Mail::IMAPClient module, which you'd only need if you need to collect mails from an IMAP server secured with TLS.

The corresponding line would look like this:

zypper ar -f -n perl http://download.opensuse.org/repositories/devel:/languages:/perl/ openSUSE_12.3/ Perl

The first time you use zypper after you added this repository, you will be prompted to add its key. Now you can install missing modules like below.

otrs-sles:/opt/otrs # zypper install -y "perl(YAML::LibYAML)"

Refreshing service 'susecloud'.

Retrieving repository 'perl' metadata [\]

New repository or package signing key received:

Key ID: DCCA98DDDCEF338C

Key Name: devel:languages:perl OBS Project <devel:languages:[email protected]>

Key Fingerprint: 36F0AC0BCA9D8AF2871703C5DCCA98DDDCEF338C

Key Created: Wed Oct 10 22:04:18 2012

Key Expires: Fri Dec 19 22:04:18 2014

Repository: perl

Do you want to reject the key, trust temporarily, or trust always? [r/t/a/?] (r): a

Retrieving repository 'perl' metadata [done]

Building repository 'perl' cache [done]

Loading repository data...

Reading installed packages...

'perl(YAML::LibYAML)' not found in package names. Trying capabilities.

Resolving package dependencies...

The following NEW package is going to be installed:

perl-YAML-LibYAML

The following package is not supported by its vendor:

perl-YAML-LibYAML

Retrieving package perl-YAML-LibYAML-0.38-12.4.x86_64 (1/1), 75.0 KiB (196.0 KiB unpacked)

Retrieving: perl-YAML-LibYAML-0.38-12.4.x86_64.rpm [done (55.7 KiB/s)]

Installing: perl-YAML-LibYAML-0.38-12.4 [done]

The next step is to configure OTRS using the web installer, as described in this section.

1.2. Installation von OTRS auf einem REd Hat

Enterprise Linux oder CentOS-System

This section describes the installation of our RPM package on a Red Hat Enterprise Linux

(RHEL) or CentOS server. For OTRS 3.3 and up, RHEL 6 or CentOS 6 is a requirement, version 5 is not supported. Before you start the installation, please visit http://www.otrs.com/ downloads and make sure you use the latest OTRS RPM package available.

1.2.1. Vorbereiten der Datenbank für OTRS

You can use OTRS using different database back-ends: MySQL, PostgreSQL, Oracle or

Microsoft SQL Server. The most popular database to deploy OTRS on is MySQL. This chap-

ter shows the steps you need to take to configure MySQL on a RHEL-based server. Of course you can install the database on a dedicated database server if needed for scalability or other purposes.

Installieren Sie MySQL als root mit folgenden Befehl:

[root@otrs-centos6 ~]# yum -y install mysql-server

This will install MySQL with the default options on your system. You'll need to change the defaults in order to make it suitable for OTRS. With a text editor open the file /etc/my.cnf

and add the next two lines under the [mysqld] section: max_allowed_packet=20M query_cache_size=32M

Now execute service mysqld start to re-start the database server and activate these changes. Then run /usr/bin/mysql_secure_installation and follow the on-screen instructions to set a database root password, remove anonymous access and remove the test database. Lastly, run chkconfig mysqld on in order to make sure mysql is automatically started at server startup time.

1.2.2. OTRS installieren

Install OTRS with via the command line using yum. This will also pull in some dependencies such as the apache web server and some Perl modules. Make sure you copied the

OTRS RPM file to the current directory.

[root@otrs-centos6 ~]# yum install --nogpgcheck otrs-3.3.*.rpm

...

Dependencies Resolved

================================================================================

Package Arch Version Repository Size

================================================================================

Installing:

otrs noarch 3.3.3-01 /otrs-3.3.3-01.noarch

74 M

Installing for dependencies:

apr x86_64 1.3.9-5.el6_2 updates 123 k

...

procmail x86_64 3.22-25.1.el6 base 163 k

Transaction Summary

================================================================================

Install 26 Package(s)

Total size: 80 M

Total download size: 6.0 M

Installed size: 88 M

Downloading Packages:

(1/25): apr-1.3.9-5.el6_2.x86_64.rpm | 123 kB 00:00

...

(25/25): procmail-3.22-25.1.el6.x86_64.rpm | 163 kB 00:00

--------------------------------------------------------------------------------

Total 887 kB/s | 6.0 MB 00:06

Running rpm_check_debug

Running Transaction Test

Transaction Test Succeeded

Running Transaction

Installing : apr-1.3.9-5.el6_2.x86_64 1/26

...

Installing : otrs-3.3.3-01.noarch 26/26

Check OTRS user ... otrs added.

Next steps:

[httpd services]

Restart httpd 'service httpd restart'

[install the OTRS database]

Make sure your database server is running.

Use a web browser and open this link:

http://myserver.example.com/otrs/installer.pl

[OTRS services]

Start OTRS 'service otrs start' (service otrs {start|stop|status|restart).

((enjoy))

Your OTRS Team

Installed:

otrs.noarch 0:3.3.3-01

Dependency Installed:

...

Complete!

[root@otrs-centos6 ~]#

Skript: Kommando für die Installation von OTRS.

The OTRS installation is complete. Now you should make sure that Apache is started and that it starts whenever the server reboots.

[root@otrs-centos6 ~]# chkconfig httpd on

[root@otrs-centos6 ~]# service httpd start

Starting httpd: httpd: Could not reliably determine the server's fully qualified domain

name, using 10.x.x.x for ServerName [ OK ]

[root@otrs-centos6 ~]#

Skript: Starten des Webservers.

1.2.3. Installation zusätzlicher Perl-Module

OTRS needs some more modules than can be installed by the RPM. You can post-install them manually. You can check what modules you are missing by running the bin/ otrs.CheckModules.pl

script located in the /opt/otrs directory. Some modules are only needed for optional functionality, such as communication with IMAP(S) servers or PDF generation. On Red Hat or CentOS we recommend installing these modules from the EPEL repository, a repository maintained by the Fedora project, which provides high quality packages for RHEL and derivatives. Check for more information the EPEL web site .

If you're on RHEL 6 or CentOS 6, you can get the latest package for EPEL from this site .

You can add this repository to yum it in one go by copying the RPM URL you find on this page and executing this command:

[root@otrs-centos6 otrs]# yum -y install http://download.fedoraproject.org/pub/epel/6/i386/ epel-release-6-8.noarch.rpm

Loaded plugins: security

Setting up Install Process epel-release-6-8.noarch.rpm | 14 kB 00:00

Examining /var/tmp/yum-root-7jrJef/epel-release-6-8.noarch.rpm: epel-release-6-8.noarch

Marking /var/tmp/yum-root-7jrJef/epel-release-6-8.noarch.rpm to be installed

Resolving Dependencies

--> Running transaction check

---> Package epel-release.noarch 0:6-8 will be installed

--> Finished Dependency Resolution

Dependencies Resolved

=====================================================================================

Package Arch Version Repository Size

=====================================================================================

Installing:

epel-release noarch 6-8 /epel-release-6-8.noarch 22 k

Transaction Summary

=====================================================================================

Install 1 Package(s)

Total size: 22 k

Installed size: 22 k

Downloading Packages:

Running rpm_check_debug

Running Transaction Test

Transaction Test Succeeded

Running Transaction

Installing : epel-release-6-8.noarch 1/1

Verifying : epel-release-6-8.noarch 1/1

Installed:

epel-release.noarch 0:6-8

Complete!

[root@otrs-centos6 otrs]#

The first time you use yum after you added this repository, you will be prompted to add its key. Now you can install missing modules like below.

[root@otrs-centos6 otrs]# yum -y install "perl(Text::CSV_XS)"

Loaded plugins: security

Setting up Install Process

Resolving Dependencies

--> Running transaction check

---> Package perl-Text-CSV_XS.x86_64 0:0.85-1.el6 will be installed

--> Finished Dependency Resolution

Dependencies Resolved

=====================================================================================

Package Arch Version Repository Size

=====================================================================================

Installing:

perl-Text-CSV_XS x86_64 0.85-1.el6 epel 71 k

Transaction Summary

=====================================================================================

Install 1 Package(s)

Total download size: 71 k

Installed size: 154 k

Downloading Packages: perl-Text-CSV_XS-0.85-1.el6.x86_64.rpm | 71 kB 00:00 warning: rpmts_HdrFromFdno: Header V3 RSA/SHA256 Signature, key ID 0608b895: NOKEY

Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6

Importing GPG key 0x0608B895:

Userid : EPEL (6) <[email protected]>

Package: epel-release-6-8.noarch (@/epel-release-6-8.noarch)

From : /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6

Is this ok [y/N]: y

Running rpm_check_debug

Running Transaction Test

Transaction Test Succeeded

Running Transaction

Installing : perl-Text-CSV_XS-0.85-1.el6.x86_64 1/1

Verifying : perl-Text-CSV_XS-0.85-1.el6.x86_64 1/1

Installed:

perl-Text-CSV_XS.x86_64 0:0.85-1.el6

Complete!

[root@otrs-centos6 otrs]#

The next step is to configure OTRS using the web installer, as described in this section.

1.2.4. Installation der Oracle-Datenbanktreiber auf Red

Hat / CentOS

If you want to deploy OTRS on an Oracle database, you'll need to compile and install the

DBD::Oracle database driver. This is slightly more complicated than installing any of the other packages; this is because Oracle is a proprietary database and Red Hat nor the

CentOS project are allowed to distribute drivers in their RPM repositories.

First of all, we'd need to install gcc, make and CPAN so we can compile and install the driver. Below you see the command on CentOS; on other versions it might look a little different.

[root@otrs-centos6 otrs]# yum -y install gcc make "perl(CPAN)"

The next step is to obtain and install the database client. For this you would need to sign up for a free account at the Oracle website. You can download the drivers from this page: http://www.oracle.com/technetwork/database/features/instant-client/index-097480.html

Please choose the Linux x86 or x86-64 version corresponding to the architecture of your system. You can check this with the uname -i. It is either 'x86_64' for x86-64 or 'i386' for x86. You should download the packages 'Instant Client Package -

Basic', 'Instant Client Package - SQL*Plus', and 'Instant Client Package - SDK'. Save them to a location on your disk. Now as the root user you can install the packages using the following command:

[root@otrs-centos6 otrs]# yum install oracle-instantclient*

After this you should set two environment variables and compile the DBD::Oracle driver.

Again, perform these tasks as the root user. The steps are outlined below. Please note that for briefness some lines outputted by the commands have been removed.

[root@otrs-centos6 otrs]# export ORACLE_HOME=/usr/lib/oracle/11.2/client64

[root@otrs-centos6 otrs]# export LD_LIBRARY_PATH=$ORACLE_HOME/lib

[root@otrs-centos6 otrs]# cpan cpan[1]> look DBD::Oracle

...

Fetching with LWP:

http://www.perl.org/CPAN/authors/id/P/PY/PYTHIAN/CHECKSUMS

Checksum for /root/.cpan/sources/authors/id/P/PY/PYTHIAN/DBD-Oracle-1.62.tar.gz ok

Scanning cache /root/.cpan/build for sizes

DONE

...

Working directory is /root/.cpan/build/DBD-Oracle-1.62-ZH6LNy

[root@localhost DBD-Oracle-1.62-ZH6LNy]# perl Makefile.PL

...

[root@localhost DBD-Oracle-1.62-ZH6LNy]# make

...

[root@localhost DBD-Oracle-1.62-ZH6LNy]# make install

...

cpan[2]> exit

Terminal does not support GetHistory.

Lockfile removed.

Now you should edit the file Kernel/Config.pm to provide ORACLE_HOME. The next step is

to configure OTRS using the web installer, as described in this section.

1.3. Installation von OTRS auf einem Debianoder Ubuntu-System

Wichtig

Please install OTRS from source, and do not use the OTRS packages that Debi-

an/Ubuntu provides.

The installation of required Perl modules is easier if you use the available packages: apt-get install libapache2-mod-perl2 libdbd-mysql-perl libtimedate-perl libnet-dns-perl \

libnet-ldap-perl libio-socket-ssl-perl libpdf-api2-perl libdbd-mysql-perl libsoap-liteperl \

libgd-text-perl libtext-csv-xs-perl libjson-xs-perl libgd-graph-perl libapache-dbi-perl

1.4. Installation von OTRS auf Microsoft Windows-Systemen

1.4.1. Benutzen des Windows-Installer

Installing OTRS on a Microsoft Windows system is very easy. Download the latest installer for Win32 from http://www.otrs.com/try/ and save the file to your local file system. Then simply double-click on the file to execute the installer, and follow the few installation steps to setup the system. The installation wizard will take care of installing all components for

OTRS. The next step is to configure OTRS using the web installer, as described in this section.

Wichtig

The Windows installer for OTRS contains all needed components for OTRS, i.e. the

Apache web server, the MySQL database server, Perl (with all needed modules) and cron for Windows. However you can also use it to set up OTRS on the Microsoft

IIS Web Server instead of on Apache. Also you can choose to not let it install the bundled MySQL, for instance if you want to deploy on a central MySQL database; a PostgreSQL database, on Microsoft SQL Server or on Oracle.

1.4.2. Installation der Oracle-Datenbanktreiber bei

Windows Systemen

If you install OTRS using the Windows Installer, it will automatically configure all Perl modules you will typically need. There is one exception to this: if you need to deploy OTRS on an Oracle database, you'll need to post-install the Oracle driver. This is needed because there is no open source driver for Oracle available; we are not allowed to redistribute it in the OTRS package. There are two different perls you can use on Windows; you can choose the bundled Strawberry Perl, which is the default option and is recommended for proof-ofconcept setups; or you can choose Active State perl which is a separate download and install. This last option is recommended for production setups.

1.4.2.1. Installation von DBD::Oracle auf ActiveState Perl

If you have installed ActiveState Perl it already comes with the Perl database driver

DBD::Oracle only this should be linked to the Oracle C client. OTRS only works on 32-bit

ActiveState Perl. This means you should also download the 32-bit Oracle client. Navigate to the Oracle client web site

Instant Client Downloads for Microsoft Windows (32-bit)

and choose 'Instant Client Package - Basic'. You'll need to sign up for a free Oracle Web account in order to download the software. Extract the download, a zip file, to the root of your drive, for instance C:\instantclient_11_2.

Now you should add the client libraries to your path and set an environment variable; 'ORACLE_HOME'. Navigate to Control Panel > System and Security > System, choose 'Advanced System Settings', click on 'New' under 'System variables', enter

'ORACLE_HOME' as Variable Name and use 'C:\instantclient_11_2' as the Variable Value.

Select the 'PATH' variable, and append the directory 'C:\instantclient_11_2' to the path. If you now start a new cmd.exe session and run the otrs.CheckModules.pl script located in the OTRS directory, you should see that the DBD::Oracle driver is successfully installed.

After this, you should restart the system in order for the other applications to detect the new environment variables.

1.4.2.2. Installation von DBD::Oracle auf Strawberry Perl

In order to compile the DBD::Oracle module, you need to have installed the components of the OTRS web installer in a path without spaces. It should NOT be in C:\Program Files

\OTRS but it should rather be in C:\OTRSComponents or similar.

On Strawberry Perl you should compile the Oracle driver manually. The OTRS Windows

Installer bundles 32-bit Strawberry Perl. This means you should also download the 32-bit

Oracle client. Navigate to the Oracle client web site

Instant Client Downloads for Microsoft

Windows (32-bit)

and download the packages 'Instant Client Package - Basic', 'Instant

Client Package - SQL*Plus', and 'Instant Client Package - SDK'. You'll need to sign up for a free Oracle Web account in order to download the software. Extract the downloads, all zip files, to the root of your drive, for instance C:\instantclient_11_2.

'ORACLE_HOME' as Variable Name and use 'C:\instantclient_11_2' as the Variable Value.

Select the 'PATH' variable, and append the directory 'C:\instantclient_11_2' to the path.

After this, you should restart the system in order for the other applications to detect the new environment variables.

Now you can compile and install the DBD::Oracle module. For this, open a cmd.exe window, and start the cpan client. Download and extract DBD::Oracle via look DBD::Oracle, then type perl Makefile.PL, dmake and dmake install. Sample output is below.

C:\Users\max>cpan cpan shell -- CPAN exploration and modules installation (v1.9800)

Enter 'h' for help.

cpan> look DBD::Oracle

Database was generated on Thu, 16 May 2013 14:52:41 GMT

Running look for module 'DBD::Oracle'

Trying to open a subshell in the build directory...

....

C:\OTRSCO~1\StrawberryPerl\cpan\build\DBD-Oracle-1.62-kq6los>perl Makefile.PL

Using DBI 1.623 (for perl 5.016003 on MSWin32-x86-multi-thread) installed in C:/

OTRSComponents/StrawberryPerl/perl/vendor/lib/auto/DBI/

Configuring DBD::Oracle for perl 5.016003 on MSWin32 (MSWin32-x86-multi-thread)

...

Checking if your kit is complete...

Looks good

LD_RUN_PATH=c:/instantclient_11_2/lib:c:/instantclient_11_2/rdbms/lib

Using DBD::Oracle 1.62.

Using DBI 1.623 (for perl 5.016003 on MSWin32-x86-multi-thread) installed in C:/

OTRSComponents/StrawberryPerl/perl/vendor/lib/auto/DBI/

Writing Makefile for DBD::Oracle

Writing MYMETA.yml and MYMETA.json

...

C:\OTRSCO~1\StrawberryPerl\cpan\build\DBD-Oracle-1.62-kq6los>dmake

... lots of output and compiler warnings ...

C:\OTRSCO~1\StrawberryPerl\cpan\build\DBD-Oracle-1.62-kq6los>dmake install

Files found in blib\arch: installing files in blib\lib into architecture depende nt library tree

Installing C:\OTRSCO~1\StrawberryPerl\perl\site\lib\auto\DBD\Oracle\dbdimp.h

...

Appending installation info to C:\OTRSCO~1\StrawberryPerl\perl\lib/perllocal.pod

C:\OTRSCO~1\StrawberryPerl\cpan\build\DBD-Oracle-1.62-kq6los>exit cpan> quit

Lockfile removed.

C:\Users\max>

1.4.2.3. Konfiguration von OTRS durch den Web Installer

The web installer may be used to configure basic OTRS settings as described in this section.

2. Manuelle Installation (Linux, Unix)

2.1. Vorbereiten der manuellen Installation

If you want to install OTRS from source, first download the source archive as .tar.gz, .tar.bz2, or .zip file from http://www.otrs.com/try/

Unpack the archive (for example, using tar) into the directory /opt, and rename the directory from otrs-x.x.x to otrs (see Script below).

linux:/opt# tar xf /tmp/otrs-x.x.x.tar.gz

linux:/opt# mv otrs-x.x.x otrs linux:/opt# ls otrs linux:/opt#

Skript: Erste Schritte bei der Installation von OTRS.

OTRS should NOT be run with root rights. Next you should add a new user for OTRS. The home directory of this new user should be /opt/otrs. If your web server is not running with the same user rights as the new 'otrs' user, which is the case on most systems, you will need to add the new 'otrs' user to the group of the web server user (see Script below).

linux:/opt# useradd -r -d /opt/otrs/ -c 'OTRS user' otrs linux:/opt# usermod -G www otrs linux:/opt#

(SUSE=www, Red Hat/CentOS/Fedora=apache, Debian/Ubuntu=www-data)

Skript: Anlegen eines neuen Nutzers 'otrs' und Hinzufügung zu desselben zu einer Gruppe.

Im nächsten Schritt werden einige Demo-Konfigurationsdateien innerhalb der entpackten

Quelldateien bzw. innerhalb des Homeverzeichnisses des OTRS-Benutzers kopiert. Die

Dateien befinden sich in den Verzeichnissen /opt/otrs/Kernel bzw. /opt/otrs/Kernel/Config und haben die Endung .dist.

linux:/opt# cd otrs/Kernel/ linux:/opt/otrs/Kernel# cp Config.pm.dist Config.pm

linux:/opt/otrs/Kernel# cd Config linux:/opt/otrs/Kernel/Config# cp GenericAgent.pm.dist GenericAgent.pm

Skript: Kopieren von Beispieldateien.

Zum Abschluss der Vorbereitungen werden noch die richtigen Zugriffsrechte für die Dateien des Ticket Systems gesetzt. Dazu kann das Skript SetPermissions.sh verwendet werden, das sich im Verzeichnis bin innerhalb des Homeverzeichnisses des OTRS-Benutzers befindet. Das Skript kann mit folgenden Parametern aufgerufen werden: otrs.SetPermissions.pl

{Homedirectory des OTRS Benutzers} {OTRS Benutzer} {Webserver

Benutzer } [Gruppe des OTRS Benutzers] [Gruppe des Webserver Benutzers]

Läuft Ihr Webserver mit den Benutzerrechten des Benutzers 'otrs', dann lautet das Kommando alsootrs.SetPermissions.pl /opt/otrs --otrs-user=otrs --web-

user=otrs. Unter SUSE Linux wird der Webserver mit dem Benutzer wwwrun betrieben. Auf Debian-basierten Systemen ist dies www-data. Geben Sie hier das Komando otrs.SetPermissions.pl /opt/otrs --otrs-user=otrs --web-user=wwwrun --otrs-

group=nogroup --web-group=www ein, um die korrekten Zugriffsrechte zu setzen.

2.2. Installation der für OTRS benötigten Perl-

Module

OTRS requires some additional Perl modules, as described in Table 3-1. If you install OTRS from source, you will need to install these modules manually. This can be done either with the package manager of your Linux distribution (yast, apt-get) or, as described in this section, through the Perl shell and CPAN. If you're using ActiveState Perl, for instance on

Windows, you could use PPM, the built-in Perl Package Manager. We recommend using your package manager if possible.

You can verify which modules you need to install with otrs.CheckModules.pl. This script is located in the bin directory, in the home directory of the 'otrs' user (see Script below).

Please note that some modules are optional.

linux:~# cd /opt/otrs/bin/ linux:/opt/otrs/bin# ./otrs.CheckModules.pl

o CGI..............................ok (v3.60) o Crypt::PasswdMD5.................ok (v1.3) o Crypt::SSLeay....................Not installed! (Optional - Required for Generic Interface

SOAP SSL connections.) o CSS::Minifier....................ok (v0.01) o Date::Format.....................ok (v2.22) o Date::Pcalc......................ok (v1.2)

...

Skript: Überprüfung benötigter Module.

You should strive to install the missing modules from your Linux distribution's package management system. By doing so, the packages will be automatically updated when new

versions are available or when security issues are found. Please refer to your distribution's documentation on how to install additional packages. If the (correct version of) the module is not available from the package repositories, you can also install from CPAN, the Comprehensive Perl Archive Network.

Um eines der oben aufgeführten Module mit Hilfe von CPAN zu installieren, geben Sie als root das Kommando perl -e shell -MCPAN ein. Perl wird im interaktiven Modus gestartet und das CPAN Modul wird geladen. Ist CPAN bereits ordentlich konfiguriert, können Sie die für OTRS benötigten Module mit Hilfe des Kommandos install gefolgt vom Modulnamen einrichten. CPAN weist darauf hin, wenn Abhängigkeiten zwischen einzelnen Modulen nicht erfüllt sind und schlägt automatisch die zusätzlich benötigten Module für die

Installation vor.

Führen Sie weiterhin die beiden Befehle perl -cw bin/cgi-bin/index.plperl -cw bin/cgi-

bin/customer.pl und perl -cw bin/PostMaster.pl aus, nach dem Sie in das Verzeichnis

/opt/otrs gewechselt sind. Wird bei beiden Befehlen die Meldung "syntax OK" angezeigt, verfügt Ihre Perl-Installation über alle von OTRS benötigten Module und Sie können im nächsten Schritt mit der Einrichtung des Webservers beginnen.

linux:~# cd /opt/otrs linux:/opt/otrs# perl -cw bin/cgi-bin/index.pl

cgi-bin/installer.pl syntax OK linux:/opt/otrs# perl -cw bin/cgi-bin/customer.pl

cgi-bin/customer.pl syntax OK linux:/opt/otrs# perl -cw bin/otrs.PostMaster.pl

bin/otrs.PostMaster.pl syntax OK linux:/opt/otrs#

Skript: Crontab-Datei.

2.3. Konfiguration des Apache-Webservers

First of all, you should install the Apache2 web server and mod_perl; you'd typically do this from your systems package manager. Below you'll find the commands needed to set up Apache on the most popular Linux distributions.

# rhel / centos:

linux:# yum install httpd mod_perl

# suse:

linux:# zypper install apache2-mod_perl

# debian/ubuntu:

linux:# apt-get install apache2 libapache2-mod-perl2

To access the web interface of OTRS via a short URL, Alias and ScriptAlias entries are needed. Most Apache installations have a conf.d directory included. On Linux systems you can usually find this directory under /etc/apache or /etc/apache2. Log in as root, change to the conf.d directory and copy the appropriate template in /opt/otrs/scripts/ apache2-httpd.include.conf

to a file called otrs.conf in the Apache configuration directory.

Starten Sie Ihren Webserver neu, um die neue Konfiguration zu laden. Auf den meisten

Systemen lässt sich der Webserver über den Befehl /etc/init.d/apache2 restart neu starten (siehe skript unten).

linux:/etc/apache2/conf.d# /etc/init.d/apache2 restart

Forcing reload of web server: Apache2.

linux:/etc/apache2/conf.d#

Skript: Neustart des Webservers.

Das war bereits die grundlegende Konfiguration des Webservers für OTRS.

2.4. Einrichten der Datenbank

2.4.1. Manuelle Installation der OTRS Datenbank

use this for some reason, you can also configure the database manually, as described in this chapter. If you can't use the web installer to setup the OTRS database, you have to set it up manually. Scripts with the SQL statements to create and configure the database are located in scripts/database, in the home directory of the 'otrs' user (see Script below).

linux:~# cd /opt/otrs/scripts/database/ linux:/opt/otrs/scripts/database# ls otrs-initial_insert.db2.sql otrs-schema.mysql.sql

otrs-schema.oracle.sql

otrs-initial_insert.mssql.sql otrs-schema-post.db2.sql

otrs-initial_insert.mysql.sql otrs-schema.postgresql.sql

otrs-initial_insert.oracle.sql

otrs-initial_insert.postgresql.sql otrs-schema-post.mssql.sql

otrs-initial_insert.xml otrs-schema-post.mysql.sql

otrs-schema.db2.sql otrs-schema-post.oracle.sql

otrs-schema-post.postgresql.sql

otrs-schema.mssql.sql otrs-schema.xml

linux:/opt/otrs/scripts/database#

Skript: Für die Datenbankerstellung benötigte Dateien.

Für die verschiedenen Datenbanktypen sind mehrere .sql-Dateien vorhanden, die nacheinander abgearbeitet werden müssen.

Die OTRS-Datenbank manuell Schritt für Schritt anlegen

1. Anlegen der Datenbank für OTRS: Legen Sie mit Hilfe Ihres Datenbankinterfaces bzw.

Ihrer Datenbankoberfläche die Datenbank an, die später von OTRS verwendet werden soll.

2. Erstellen der Tabellen: Mit Hilfe der otrs-schema.Datenbanktyp.sql-Dateien (z. B. otrsschema.oracle.sql

, otrs-schema.postgresql.sql, usw.) können Sie die Tabellen innerhalb der OTRS Datenbank erzeugen.

3. Inserting the initial system data: OTRS needs some initial system data to work properly (e.g. the different ticket states, ticket and notification types). Depending on the type of database that you are using, you will need to use one of the following files: otrs-initial_insert.mysql.sql, otrs-initial_insert.oracle.sql, otrsinitial_insert.postgresql.sql

or otrs-initial_insert.mssql.sql .

4. Erzeugen von "foreign keys" auf andere Tabellen: Abschließend müssen noch die "foreign keys" erstellt werden, über die die verschiedenen Tabellen in der OTRS Datenbank voneinander abhängen. Dies kann mit Hilfe der otrs-schema-post.Datenbanktyp.sql-

Dateien erreicht werden (z. B. otrs-schema-oracle.post.sql, otrs-schema-post.postgresql.sql

, usw.).

Nachdem Sie die Datenbank angelegt haben, sollten Sie die Zugriffsrechte dafür setzen und z. B. sicherstellen, dass nur ein bestimmter Benutzer ohne Datenbank-Administrati-

onsrechte Zugriff auf die OTRS Datenbank hat. Je nachdem, welche Datenbank Sie einsetzen, unterscheiden sich hier die Vorgehensweisen, es sollte jedoch möglich sein dies mit Hilfe Ihres Datenbankinterfaces bzw. Ihrer Datenbankoberfläche zu erledigen.

Wurden die nötigen Einstellungen für die Datenbank vorgenommen, muss nun noch dem

Ticket-System mitgeteilt werden, welche Datenbank es verwenden soll. Öffnen Sie die

Datei Kernel/Config.pm innerhalb des Homeverzeichnisses des OTRS Benutzers und passen Sie die dafür vorgesehenen Parameter an.

# DatabaseHost

# (The database host.)

$Self->{'DatabaseHost'} = 'localhost';

# Database

# (The database name.)

$Self->{Database} = 'otrs';

# DatabaseUser

# (The database user.)

$Self->{DatabaseUser} = 'otrs';

# DatabasePw

# (The password of database user.)

$Self->{DatabasePw} = 'some-pass';

Skript: Anzupassende Einstellungen.

2.5. Einrichten der von OTRS benötigten cron-

Jobs

Damit OTRS voll funktioniert, werden einige cron-Jobs benötigt. Die cron-Jobs sollten mit denselben Benutzerrechten ausgeführt werden, die auch für die restlichen OTRS-Skripte vergeben wurden, d.h. die cron-Jobs sollten in die crontab des Benutzers 'otrs' eingetragen werden.

Alle Skripte für die verschiedenen cron-Jobs befinden sich im Verzeichnis var/cron innerhalb des Homeverzeichnisses des Benutzers 'otrs'.

linux:~# cd /opt/otrs/var/cron linux:/opt/otrs/var/cron# ls aaa_base.dist generic_agent.dist rebuild_ticket_index.dist

cache.dist pending_jobs.dist session.dist

fetchmail.dist postmaster.dist unlock.dist

generic_agent-database.dist postmaster_mailbox.dist

linux:/opt/otrs/var/cron#

Skript: Für die Erstellung der Cronjobs benötigte Dateien.

Alle Skripte tragen die Endung .dist und sollten zunächst so umkopiert werden, dass keine

Endung mehr vorhanden ist.

linux:/opt/otrs/var/cron# for foo in *.dist; do cp $foo `basename $foo .dist`; done linux:/opt/otrs/var/cron# ls aaa_base generic_agent-database.dist rebuild_ticket_index aaa_base.dist generic_agent.dist rebuild_ticket_index.dist

cache pending_jobs session cache.dist pending_jobs.dist session.dist

fetchmail postmaster unlock fetchmail.dist postmaster.dist unlock.dist

generic_agent postmaster_mailbox generic_agent-database postmaster_mailbox.dist

linux:/opt/otrs/var/cron#

Skript: Kopieren und Umbenennen der für die Erstellung der Cronjobs benötigten Dateien.

Die folgende Tabelle gibt eine kurze Übersicht über die Aufgabe der verschiedenen Skripte.

Tabelle 2.1. Die verschiedenen Skripte für die cron-Jobs von OTRS.

Skript

aaa_base cache fetchmail generic_agent generic_agent-database pending_jobs postmaster postmaster_mailbox rebuild_ticket_index session unlock

Funktion

Über dieses Skript werden die grundlegenden Einstellungen für die crontab des

Benutzers 'otrs' festgelegt.

Löscht abgelaufene Cache-Einträge von der

Festplatte. Leert den Cache von CSS- und

JavaScript-Dateien.

Falls Nachrichten mit Hilfe von fetchmail in das System eingespeist werden sollen, kann dieses Skript verwendet werden.

Mit Hilfe dieses Skripts werden die Jobs des

GenericAgents ausgeführt, die über eigene

Konfigurationsdateien festgelegt wurden.

Mit Hilfe dieses Skripts werden die Jobs des GenericAgents ausgeführt, die über dem Administrations-Bereich innerhalb von

"GenericAgent" angelegt wurden.

Mit Hilfe dieses Skripts wird das System auf

"wartende" (pending) Tickets überprüft.

Mit Hilfe dieses Skripts wird die Nachrichten-Warteschlange von OTRS überprüft und noch nicht verarbeitete Nachrichten werden im System gespeichert bzw. zugestellt.

Mit Hilfe dieses Skripts werden die verschiedenen pop3-Konten abgefragt, die im Administrations-Bereich innerhalb von "PostMaster POP3 Account" eingerichtet wurden.

Mit Hilfe dieses Skripts wird der Ticket-Index für die Queue-Ansicht neu erzeugt, wodurch die Anzeige beschleunigt wird.

Über dieses Skript werden alte und nicht mehr gültige Session-IDs entfernt.

Mit Hilfe dieses Skripts wird die Freigabe von

Tickets innerhalb des Systems ermöglicht.

To setup all cron jobs, the script bin/Cron.sh located in the home directory of the 'otrs' user can be used. When this script is executed, it needs a parameter to specify whether you want to install, remove, or reinstall the cron jobs. The following parameters can be used:

Cron.sh

{start} {stop} {restart} [OTRS-Benutzer]

Da die cron-Jobs für den Benutzer 'otrs' angelegt werden sollen, muss das Skript von diesem Benutzer ausgeführt werden. Sind Sie z. B. als Benutzer root am System angemeldet,

können Sie mit Hilfe des Kommandos su otrs zum OTRS-Benutzer wechseln. Nehmen Sie also die Installation wie folgt vor.

Warnung

Bitte beachten Sie, dass durch die Verwendung von Cron.sh evtl. andere Cron-

Jobs des OTRS-Benutzers überschrieben bzw. gelöscht werden. Um weitere, nicht von OTRS benötigte Cron-Jobs für den OTRS-Benutzer zu installieren, erweitern Sie bitte Cron.sh dementsprechend.

linux:/opt/otrs/var/cron# cd /opt/otrs/bin/ linux:/opt/otrs/bin# su otrs linux:~/bin$ ./Cron.sh start

/opt/otrs/bin

Cron.sh - start/stop OTRS cronjobs

(using /opt/otrs) done linux:~/bin$ exit exit linux:/opt/otrs/bin#

Skript: Installation der Cronjobs.

Mit Hilfe des Kommandos crontab -l -u otrs, das Sie als root ausführen können, wird die crontab-Datei des Benutzers 'otrs' angezeigt und Sie können überprüfen, ob alle Einträge vorhanden sind.

linux:/opt/otrs/bin# crontab -l -u otrs

# --

# cron/aaa_base - base crontab package

# --

# This software comes with ABSOLUTELY NO WARRANTY.

# --

# Who gets the cron emails?

MAILTO="root@localhost"

# --

# cron/cache - delete expired cache

# This software comes with ABSOLUTELY NO WARRANTY.

# --

# delete expired cache weekly (Sunday mornings)

20 0 * * 0 $HOME/bin/otrs.CacheDelete.pl --expired >> /dev/null

30 0 * * 0 $HOME/bin/otrs.LoaderCache.pl -o delete >> /dev/null

# --

# cron/fetchmail - fetchmail cron of the OTRS

# --

# This software comes with ABSOLUTELY NO WARRANTY.

# --

# fetch every 5 minutes emails via fetchmail

#*/5 * * * * /usr/bin/fetchmail -a >> /dev/null

# --

# cron/generic_agent - otrs.GenericAgent.pl cron of the OTRS

# --

# This software comes with ABSOLUTELY NO WARRANTY.

# --

# start generic agent every 20 minutes

*/20 * * * * $HOME/bin/GenericAgent.pl >> /dev/null

# example to execute GenericAgent.pl on 23:00 with

# Kernel::Config::GenericAgentMove job file

#0 23 * * * $HOME/bin/otrs.GenericAgent.pl -c "Kernel::Config::GenericAgentMove" >> /dev/ null

# --

# cron/generic_agent - GenericAgent.pl cron of the OTRS

# --

# This software comes with ABSOLUTELY NO WARRANTY.

# --

# start generic agent every 10 minutes

*/10 * * * * $HOME/bin/otrs.GenericAgent.pl -c db >> /dev/null

# --

# cron/pending_jobs - pending_jobs cron of the OTRS

# --

# This software comes with ABSOLUTELY NO WARRANTY.

# --

# check every 120 min the pending jobs

45 */2 * * * $HOME/bin/otrs.PendingJobs.pl >> /dev/null

# --

# cron/postmaster - postmaster cron of the OTRS

# --

# This software comes with ABSOLUTELY NO WARRANTY.

# --

# check daily the spool directory of OTRS

10 0 * * * $HOME/bin/otrs.ReprocessMails.pl >> /dev/null

# --

# cron/postmaster_mailbox - postmaster_mailbox cron of the OTRS

# --

# This software comes with ABSOLUTELY NO WARRANTY.

# --

# fetch emails every 10 minutes

*/10 * * * * $HOME/bin/otrs.PostMasterMailbox.pl >> /dev/null

# --

# cron/rebuild_ticket_index - rebuild ticket index for OTRS

# --

# This software comes with ABSOLUTELY NO WARRANTY.

# --

# just every day

01 01 * * * $HOME/bin/otrs.RebuildTicketIndex.pl >> /dev/null

# --

# cron/session - delete old session ids of the OTRS

# --

# This software comes with ABSOLUTELY NO WARRANTY.

# --

# delete every 120 minutes old/idle session ids

55 */2 * * * $HOME/bin/otrs.DeleteSessionIDs.pl --expired >> /dev/null

# --

# cron/unlock - unlock old locked ticket of the OTRS

# --

# This software comes with ABSOLUTELY NO WARRANTY.

# --

# unlock every hour old locked tickets

35 * * * * $HOME/bin/otrs.UnlockTickets.pl --timeout >> /dev/null linux:/opt/otrs/bin#

Skript: Crontab-Datei.

2.6. OTRS Scheduler-Dienst

OTRS wird mit einem Scheduler-Dienst ausgeliefert, der asynchrone Aufgaben ausführt.

The OTRS RPMs will set up the Scheduler Service automatically. If you install from source, you can install the service by copying the scripts/otrs-scheduler-linux file to /

etc/init.d

and giving it the appropriate permissions. This will make sure the scheduler service starts when the system starts up.

3. Benutzen des Web-Installers

You can use the OTRS Web Installer, after you installed the OTRS software, to set up and configure the OTRS database. The Web Installer is a web page you can visit in your browser. The URL for the web installer is http://localhost/otrs/installer.pl

Wenn der Webinstaller gestartet ist, folgen Sie den Anweisungen auf dem Bildschirm.

1. Lesen Sie die Informationen über die OTRS-Niederlassungen und klicken Sie auf "Weiter" um fortzufahren. (siehe untere Abbildung)

Abb.: Willkommensbildschirm.

2. Lesen Sie die GNU Affero General Public License und akzeptieren Sie sie durch Klick auf "Akzeptieren".

Abb.: GNU Affero General Public License.

3. Choose the database that you want to use with OTRS. If you choose MySQL, PostgreSQL or Microsoft SQL Server as a database, you can also select here if you want the web installer to create a database for you or if your database administrator has already created

an empty database for you that you would like to use. After that, click the Next button

(see figure below).

Abbildung: Datenbankeinstellungen.

4. Depending of the database you chose and if you wanted the web installer to create a database or use an existing one in the previous step, this screen might differ a little.

Enter the credentials for the database in this screen.

Abbildung: Datenbank-Benutzerdaten.

5. Erstellen Sie einen neuen Datenbankbenutzer, wählen Sie einen Namen für die Datenbank und klicken Sie auf "Weiter" (siehe untere Abbildung).

Warnung

OTRS will generate a strong password for you. It's possible to enter your own password if you prefer this. The password will be written to the configuration file Kernel/Config.pm

so there is no need to remember this password.

Abb.: Datenbankeinstellungen.

6. The database will be created if needed, and populated, as shown in this image. Click

'Next' to go to the next screen.

Abbildung: Bestätigung der erfolgreichen Datenbankeinrichtung.

7. Provide all the required system settings and click on 'Next' (see Figure below).

Abb.: Systemeinstellungen.

8. If desired, you can provide the needed data to configure your inbound and outbound mail, or skip this step by pressing the right button at the bottom of the screen (see Figure below).

Abb.: E-Mail-Konfiguration.

9. Congratulations! Now the installation of OTRS is finished and you should be able to work with the system (see Figure below). To log into the web interface of OTRS, use the address

http://localhost/otrs/index.pl

from your web browser. Log in as OTRS administrator, using the username 'root@localhost' and the generated password. After that, you can configure the system to meet your needs.

Warnung

Bitte notieren Sie das generierte Passwort für den Benutzer 'root@locaclhost'.

Figure: Web installer final screen.

4. Upgrade des OTRS Frameworks

Diese Hinweise sind für Leute gedacht, die von OTRS 3.2 auf 3.3 upgraden, und gilt für

RPM-basierte und manuelle Upgrades (tarball).

Anmerkung

Please note that OTRS 3.3 requires at least perl version 5.10.0. Make sure before you plan your upgrade that your server runs this version. You can check the version with the command perl -v on the command line.The only known Linux distribution that uses perl 5.8 and is still supported by its vendor is Red Hat Enterprise Linux (RHEL) 5 and its community supported derivative CentOS 5. If you're on any of these platforms and you plan to upgrade to OTRS 3.3 you should also plan migrating your operating system to a version with a supported perl, such as

RHEL 6 or CentOS 6.

Wenn Sie eine ältere Version von OTRS einsetzen, müssen sie zuerst dem Upgrade-Pfad zur 3.1 folgen (1.1->1.2->1.3->2.0->2.1->2.2->2.3->2.4->3.0->3.1->3.2->3.3 ...)! Sie müssen ein vollständiges Upgrade auf jede Zwischen-Version inklusive der Datenbankänderungen und der Perlskripte durchführen.

Bitte beachten Sie, falls Sie von OTRS 2.2 oder früher upgraden, müssen Sie einen extra

Schritt durchführen; bitte lesen Sie dazu http://bugs.otrs.org/show_bug.cgi?id=6798 .

Innerhalb einer Minor-Version können Sie einzelne Patch-Level-Versionen überspringen, falls Sie upgraden wollen. Beispielsweise können Sie direkt von OTRS 3.3.1 auf OTRS 3.3.4

upgraden. Wenn Sie so ein "Patch-Level-Upgrade" durchführen, können Sie Schritt 9 und

13-16- überspringen.

Bitte beachten Sie wenn Sie ein Upgrade von OTRS 3.3.6 oder früher durchführen, müssen

Sie einen neuen Cronjob aktivieren, der den Scheduler-Prozess kontrolliert. Bitte kopieren

Sie dazu die Datei /opt/otrs/var/cron/scheduler_watchdog.dist nach /opt/otrs/ var/cron/scheduler_watchdog und aktualisieren Sie anschließend ihre Crontabs mit / opt/otrs/bin/Cron.sh start (als "otrs" user, nicht root).

1. Stoppen Sie alle relevanten Dienste.

z. B. (hängt von eingesetzten Diensten ab): shell> /etc/init.d/cron stop

shell> /etc/init.d/postfix stop shell> /etc/init.d/apache stop

2. Sichern Sie folgende Daten in $OTRS_HOME (Standard: OTRS_HOME=/opt/otrs):

• Kernel/Config.pm

• Kernel/Config/GenericAgent.pm

• Kernel/Config/Files/ZZZAuto.pm

• var/*

• und die Datenbank

3. Bitte stellen Sie sicher das ein umfangreiches Backup vorliegt.

4. Installieren eines neuen Systems (optional)

Neues System aufsetzen (optional). Wenn möglich, installieren Sie zunächst auf einer separaten Testmaschine.

5. Installieren Sie das neue Release (tar oder RPM).

• Mit dem Tarball: shell> cd /opt shell> mv otrs otrs-old shell> tar -xzf otrs-x.x.x.tar.gz

shell> mv otrs-x.x.x otrs

Wiederherstellen alter Konfiguration Dateien

• Kernel/Config.pm

• Kernel/Config/GenericAgent.pm

• Kernel/Config/Files/ZZZAuto.pm

Wiederherstellung TicketCounter.log

Damit OTRS mit der richtigen Ticketnummer weiter arbeitet, stellen Sie die Datei

TicketCounter.log

in $OTRS_HOME/var/log/ (Standard: OTRS_HOME=/opt/otrs) wieder her. Das ist vorallem dann wichtig, wenn Sie inkrementelle Ticketnummern verwenden.

Wiederherstellung article data

Wenn Sie OTRS so konfiguriert haben, dass Artikeldaten im Dateisystem gespeichert werden, müssen Sie den Ordner article nach $OTRS_HOME/var/ (Standard:

OTRS_HOME=/opt/otrs ) wiederherstellen.

• Per RPM: shell> rpm -Uvh otrs-x.x.x.-01.rpm

In diesem Fall stellt das RPM-Update die alten Konfigurationsdateien automatisch wieder her.

6. Eigene Themes

Hinweis: Die OTRS-Themes von 3.2 sind NICHT zu 3.3 kompatibel, verwenden Sie ihre alten Themes daher nicht weiter!

Themes befinden sich in /opt/otrs/Kernel/Output/HTML/*/*.dtl (Standard:

OTRS_HOME=/opt/otrs).

Bitte beachten Sie das dtl-Dateien in UTF-8 sein müssen in OTRS 3.3.

7. Setzen Sie die Datei-Berechtigungen.

wenn der Tarball benutzt wird, führen Sie shell> cd /opt/otrs/ shell> bin/otrs.SetPermissions.pl

aus, um die Berechtigungen zu setzen, die für Ihr System benötigt werden.

8. Überprüfung benötigter Perl Module

Versichern Sie sich dass alle benötigten Perl-Module auf Ihrem System installiert sind und installieren Sie alle Module die fehlen.

shell> /opt/otrs/bin/otrs.CheckModules.pl

9. Schema aktualisieren:

Note: new tables created in the MySQL UPGRADING process will be created with the default table storage engine set in your MySQL server. In MySQL 5.5 the new default type is InnoDB. If existing tables, e.g. "users", have the table storage engine, e.g.

MyISAM, then an error will be displayed when creating the foreign key constraints.

You have two options: (1) you can change the default storage engine of MySQL back to MyISAM so that new tables will have the same engine as the existing tables, or (2) change the existing tables to use InnoDB as storage engine.

Any problems with regards to the storage engine will be reported by the otrs.CheckDB.pl script, so please run it to check for possible issues.

shell> cd /opt/otrs/

# MySQL: shell> bin/otrs.CheckDB.pl

shell> cat scripts/DBUpdate-to-3.3.mysql.sql | mysql -p -f -u root otrs

# PostgreSQL 8.2+: shell> cat scripts/DBUpdate-to-3.3.postgresql.sql | psql --set ON_ERROR_STOP=on --singletransaction otrs otrs

# PostgreSQL, older versions: shell> cat scripts/DBUpdate-to-3.3.postgresql_before_8_2.sql | psql --set

ON_ERROR_STOP=on --single-transaction otrs otrs

Note: If you use PostgreSQL 8.1 or earlier, you need to activate the new legacy driver for these older versions. Do this by adding a new line to your Kernel/Config.pm like this:

$Self->{DatabasePostgresqlBefore82} = 1;

Führen Sie das Migrationsskript aus (als OTRS-Benutzer, nicht als root!): shell> scripts/DBUpdate-to-3.3.pl

Do not continue the upgrading process if this script does not work properly for you.

Otherwise data loss may occur.

10.Aktualisieren Sie die Konfiguration und löschen Sie die Caches. Bitte führen Sie folgendes aus (als Benutzer 'OTRS', NICHT als 'root'): shell> bin/otrs.RebuildConfig.pl

shell> bin/otrs.DeleteCache.pl

11.Starten Sie Ihre Dienste neu.

e. g. (depends on used services): shell> /etc/init.d/cron start shell> /etc/init.d/postfix start shell> /etc/init.d/apache start

Now you can log into your system.

12.Installierte Pakete überprüfen

Prüfen Sie im Paketmanager, ob alle Pakete noch als korrekt installiert markiert sind oder eine Re-Installation oder ein Upgrade benötigen.

The following packages are automatically uninstalled after the upgrade process (if they where installed before):

• OTRSPostMasterFilterExtensions

• OTRSFreeTextFromCustomerUser

• OTRSExternalTicketNumberRecognition

• OTRSDashboardQueueOverview

• OTRSImportantArticles

• OTRSImportantArticlesITSM

• OTRSDashboardTicketCalendar

• OTRSMultiServiceSelect

• OTRSMultiQueueSelect

• OTRSDynamicFieldMultiLevelSelection

• OTRSEventBasedTicketActions

• OTRSTicketAclEditor

• OTRSCustomerProcessSelection

• OTRSACLExtensions

• OTRSGenericStandardTemplates

• OTRSExtendedDynamicDateFieldSearch

• OTRSDashboardTicketOverviewFilters

13.Check config settings of OTRSFreeTextFromCustomerUser

Note: This only applies if you used the package OTRSFreeTextFromCustomerUser previously.

If you used this module previously, you need to reconfigure it. The module is automatically uninstalled by the upgrading script as it is now a part of the OTRS framework.

If you want to keep using it, please enable the setting "Ticket::EventModulePost###930-DynamicFieldFromCustomerUser" to activate this feature and configure the mapping in the setting

"DynamicFieldFromCustomerUser::Mapping".

14.Importieren Sie ihre ACLs in den neuen ACL-Editor (optional)

In OTRS 3.3, there is a graphical editor for ACLs in the administration interface. You will need to import your existing ACLs (e.g. in Config.pm or additional files) to the editor by using bin/otrs.ImportACLsFromConfig.pl in order to make them available in the editor.

Please make sure to delete any ACLs from Config.pm (or other files) after successfully finishing the import procedure. Also you will need to use the deploy button in the ACL administration frontend in order to re-deploy the imported ACLs to your system.

15.Aktualisieren der Webserver-Konfiguration

Note: this applies only if you use the Apache web server, and do not use the configuration file directly from the OTRS installation directory (e. g. with a symlink from the

Apache configuration directory).

Please update the the Apache configuration file for OTRS as there have been several changes (see scripts/apache2-httpd.include.conf).

16.Aktualisieren und Aktivieren der Cronjobs

There are several OTRS default cronjobs in $OTRS_HOME/var/cron/*.dist. They can be activated by copying them without the ".dist" filename extension. Do this to make sure you get the latest versions of the cronjobs and new cronjobs as well.

shell> cd var/cron shell> for foo in *.dist; do cp $foo `basename $foo .dist`; done

Please check the copied files and re-apply any customizations that you might have made.

To schedule these cronjobs on your system, you can use the script Cron.sh. Make sure to execute it as the OTRS system user!

shell> /opt/otrs/bin/Cron.sh start

17.Gut gemacht!

5. Upgrade mit dem Windows-Installer

If you installed OTRS on Windows, it is possible to upgrade seamlessly by downloading the new Windows Installer and running it. The installer will automatically detect the OTRS installation and perform an upgrade on it. The installer will stop the OTRS services and start them after the installation is complete, so your users will experience downtime. Make sure you plan some time for the upgrade. Always make sure you have a backup of your server before you start the upgrade procedure!

5.1. Performing patch level upgrades on Windows

If you need to install a 'patch level' upgrade (i.e. from OTRS 3.3.1 to OTRS 3.3.2) on

Windows all you need to do is to download and run the new installer. Of course you should make sure you have a backup in place before you start the upgrade!

5.2. Performing minor level upgrades on Windows

Minor upgrades (from OTRS 3.2 to OTRS 3.3) take a little more time as there is also a database upgrade step involved. The installer will detect this and will automatically perform the upgrade for you. After installation you should still perform steps 12, 13 and 14

of the 'regular' upgrading section.

Please note that if you have any additional packages such as Feature Add-Ons installed on your OTRS system, you'll need to upgrade these as well. Make sure you obtain these before you start the upgrade. After upgrade is complete you can upgrade these packages via the Package Installer Web GUI. Packages from the 'standard' repositories such as

Survey, FAQ and ITSM can be upgraded from the Package Manager after the framework upgrade is complete.

6. Zusätzliche Applikationen

Zusätzlich zum OTRS-Framework haben Sie die Möglichkeit, weitere Applikationen aus einem Online-Verzeichnis über das Admin-Interface (Paketmanager) zu installieren. Dieser lädt Applikationen von einem Online-Verzeichnis herunter und löst die Paketabhängigkeiten auf. Es ist zudem möglich, Pakete in Form lokaler Dateien zu installieren, z. B. für den Fall, dass Ihr OTRS keine Internetverbindung hat.

6.1. FAQ

The FAQ is the Knowledge Base component. It supports editing and viewing of FAQ articles.

Articles can be viewed and restricted to agents, customer users, or anonymous users.

These can also be structured into groups, and be read in different languages.

Kapitel 3. Erste Schritte

Dieser Abschnitt soll einen ersten Überblick über die Funktionsweise von OTRS und den

Aufbau der Weboberfläche des Systems geben. Es werden die Unterschiede zwischen den

Mitarbeitern 'agents', den Kunden 'Customer' und Administratoren 'administrators' erklärt.

Anschließend wird die erste Anmeldung als OTRS-Administrator durchgeführt und erläutert, was mit Hilfe der Benutzereinstellungen für jeden Account innerhalb des Systems festgelegt werden kann.

1. Agenten-Weboberfläche

Die Mitarbeiter bearbeiten über die Weboberfläche des Systems die Anfragen der Kunden, erstellen neue Tickets für andere Mitarbeiter oder Kunden, legen Tickets über Telefongespräche mit Kunden an, schreiben FAQ-Einträge, bearbeiten Kundendaten usw.

Supposing your OTRS host is reachable via the URL

http://www.example.com

, then the

OTRS login screen can be reached by using the address http://www.example.com/otrs/ index.pl

in a web browser (see Figure below).

Abb.: Login-Bildschirm der Agenten-Weboberfläche.

2. Kunden-Weboberfläche

Customers have a separate web interface in OTRS through which they can create new accounts, change their account settings, create and edit tickets, get an overview on tickets that they have created, etc.

Das obige Beispiel fortsetzend kann der Kunden-Login-Bildschirm über die URL http:// www.example.com/otrs/customer.pl

mit einem Webbrowser erreicht werden (siehe Abbildung unten).

Abb.: Login-Bildschirm der Kunden-Weboberfläche.

3. Öffentliche Weboberfläche

In addition to the web interfaces for agents and customers, OTRS also has a public web interface which is available through the FAQ-Module. This module needs to be installed separately. It provides public access to the FAQ system and lets visitors search through

FAQ entries without any special authorization.

In our example, the public web interface can be reached via either of the following URLs: http://www.example.com/otrs/faq.pl

, http://www.example.com/otrs/public.pl

Abb.: Öffentliche Weboberfläche.

4. Die erste Anmeldung

Access the login screen as described in the section Agent web interface . Enter a user

name and password. Since the system has just been installed and no users have yet been

created, login as OTRS administrator first, using 'root@localhost' for username and 'root' for password.

Warnung

Diese Zugangsdaten werden bei jeder OTRS-Installation standardmäßig vergeben.

Da das Kennwort für den OTRS-Administrator somit öffentlich bekannt ist, sollten

Sie es schnellstmöglich ändern! Sie können dies nach der Anmeldung als OTRS-

Administrator über die Benutzereinstellungen vornehmen.

Wollen Sie sich nicht als OTRS-Administrator anmelden, geben Sie einfach den Benutzernamen und das Kennwort Ihres normalen OTRS-Accounts in die dafür vorgesehenen Eingabefelder ein.

Falls Sie einmal ihr Kennwort vergessen haben sollten, können Sie sich automatisch vom

System ein neues Kennwort an die Mailadresse schicken lassen, die für Ihren OTRS-

Account im System hinterlegt ist. Geben Sie dazu im unteren Bereich des Login-Bildschirms den Benutzernamen Ihres Accounts an.

Abb.: Neues Passwort anfordern.

5. Agenten-Weboberfläche - ein Überblick

Upon successfully logging into the system, you are presented with the Dashboard page

(see Figure below). It shows your locked tickets, allows direct access through menus to the queue, status and escalation views, and also holds options for creation of new phone and e-mail tickets. It also presents a quick summary of the tickets using different criteria.

Abb.: Dashboard der Agenten-Weboberfläche.

To improve clarity, the general web interface is separated into different areas. The top row of each page shows some general information such the current username, the logout button, icons listing the number of locked tickets with direct access to them, links to create a new phone/e-mail ticket, etc. There are also icons to go to the queue, status, and escalation views.

Below the icons row is the navigation bar. It shows a menu that enables you to navigate to different areas or modules of the system, letting you execute some global actions.

Clicking on the Dashboard button takes you to the dashboard. If you click on the Tickets button, you will get a submenu with options to change the ticket's view, create a new ticket

(phone/e-mail) or search for a specific ticket. The Statistics button presents a menu that allows you to choose from an overview of the registered statistics, creating a new one or importing an existing one. The Customers button leads you to the Customer Management screen. By clicking the Admin button, you can access all of the administrator modules, which allows you to create new agents, queues, etc. There is also a Search button to make ticket searches.

If any associated applications are also installed, e.g. the FAQ or the Survey, buttons to reach these applications are also displayed.

Die rote Leiste unterhalb des Navigationsbereiches zeigt verschiedene Systemnachrichten an. Wenn Sie als OTRS-Administrator-Benutzer angemeldet sind, erhalten Sie hier den

Hinweis, dass Sie mit diesem Benutzer nicht regulär arbeiten sollten.

Below the title of the section you are currently in, there are several subsections containing relevant information about the screen you are working on, each one in a separate box.

These boxes contains the main part of each screen, usually they are displayed in one or several columns, each box can store relevant information about the current screen like for example instructions, advises, overviews, etc. Also is displayed the form or tool necessary for performing the action associated to each screen, like for example, add, update or delete records, check the log, change configuration settings, etc.

Finally at the bottom of the page, the site footer is displayed (see Figure below). It contains links to directly access the OTRS official web site, or go to the Top of the page.

Normalerweise sehen die "icon row", die "navigation bar" und die Fußzeile überall im gesamten Webinterface gleich aus.

Abb.: Fußzeile.

6. Übersicht

The Dashboard is the main page of the system, here you can get an overview about the tickets and other stuff related to the ticket activity. It's thinking to be the starting point for the daily work of an agent, by default it presents a quick summary of the tickets which are pending, escalated, new, and open, among other information.

One of the most important features about Dashboard is that is completely customizable.

That means you that can configure each part as you want, showing or hiding elements.

It's even possible to relocate this elements within the same column by clicking on and dragging the element's header, and dropping them elsewhere. Each element is named

"Widget", the system has some widgets ready to use out of the box, but the modular design of the dashboard screen is prepared to integrate custom widgets easily.

The content of this screen is arranged in two main columns, on the left column you normally can see information about tickets classified by their states like: reminder, escalated, new, and open. On each of this widgets you can filter the results to see all of the tickets that you are allowed to access, tickets you have locked, the ones that are located in agent defiend queues, among other filters. There are also other kind of widgets in this column and they are all described below.

Left column dashboard widgets.

• Ticket List Widgets

Widgets under this category share same overall behavior, look and feel. This widgets shows a list of tickets on a determined state. the amount of tickets display on each list page can be configured in widget options (they appear when you hover the mouse pointer over the top right part of the widget). This widgets support the following filters:

• Meine gesperrten Tickets

The tickets that the logged agent has locked.

• Meine beobachteten Tickets

The tickets that the logged agent has in his/her watched list, requires Ticket::Watcher setting to be turned on to be displayed.

• Meine Verantwortlichkeiten

The tickets that the logged agent is set as responsible, Ticket::Responsible setting is required to be turned on in order to make this filter visible.

• TIckets in meinen Queues

The tickets that are on queues where the agent define as "My Queues".

• Alle Tickets

Alle Tickets auf die der Agent Zugriff hat.

Das sind folgende Widgets:

• Erinnerungs-Tickets

TIckets die auf 'warten' gesetzt sind und deren Erinnerungszeit erreicht ist.

• Eskaliert

Tickets die eskaliert sind.

• Neue Tickets

Tickets die den Status "Neu" haben.

• Offene Tickets / Beantwortung erforderlich

Tickets die den Status "Offen" haben.

• Ticket-Ereigniskalender

A calendar event (for this widget) is defined when a new ticket is created, the Events

Ticket Calendar feature has to be enabled, and it requires two new fields to be displayed in ticket creation screens, one for the event start time and the other one for the end time, this times determine the duration of the event.

This widget includes the following views: month, week and day, agents can scroll thru the pages by using the right and left arrows.

As mentioned before just enabling the widget is not enough, a couple of "Date/Time" dynamic fields for tickets should be added into the system (via Dynamic Fields link in

"Admin" panel) and set them up in the SysConfig for this widget, both Dynamic Fields should be configured to be displayed on the ticket creation screens, they should be filled during ticket creation or any other ticket action screen (e.g. Free Fields) to describe the time frame for the calendar event (start and end time), the ticket zoom screen might be configured to show this dynamic fields also, in case you consider it necessary.

Further configurations for this widget could be found under the

"Frontend::Agent::Dashboard::EventsTicketCalendar" SubGroup in the SysConfig:

• Kalenderbreite

Definiert die Kalenderbreite in Prozent. Standard ist 95%

• DynamicFieldStartTime

Definiert den Namen des dynamischen Feldes für die Startzeit.

• DynamicFieldEndTime

Definiert den Namen des dynamischen Feldes für die Endzeit.

• Queues

Only the tickets on the queues specified in this setting will be considered in the calendar view.

• DynamicFieldsForEvents

Definiert die dynamischen Felder die im Kalender-Overlay angezeigt werden.

• TicketFieldsForEvents

Definiert die Ticketattribute die im Kalender-Overlay angezeigt werden.

• Übersicht nach Queues

This widget shows in a ticket count matrix where the rows represents queues and the columns represents the ticket states, then on each cell the number of tickets on a defined state that belongs on a particular queue is displayed.

The widget also shows a Totals row and a Totals column, the Totals row shows the sum of the tickets for each state on all presented queues, while the Totals column represent the sum of the tickets for each queue on all presented states.

The queues and states that are presented can be changed via Sysconfig.

By clicking any of the ticket count numbers a ticket search results page will opened letting agents to have a more detailed overview of them.

In the right column is located an special widget that allow you to control the widgets you want to show or hide, This is the Settings widget. Click on it's header to expand the section and see all available widgets, as shown in Figure. Each widget name has a checkbox,

Use this checkboxes to define the visibility of the widgets in the dashboard (unchecked widgets will not be shown) after you define the visibility options and click on 'Save' for storing your changes. This section is fixed on the screen, this means you can't drag and drop it, or close it.

Abb.: Dashboard-Einstellungen.

Right column dashboard widgets.

• 7 Tage-Statistik

It shows a graph of ticket activity over the past 7 days that includes 2 lines. One that is usually blue color, represents the amount of created tickets per day and the second one, usually orange and represents the closed tickets per day.

• Anstehende Ereignisse

Tickets on short for escalating or already escalated are listed here, info from this widget is very helpful since you have the chance to know about tickets needs your attention and you can decide in which ones you want to focus your effort on, set priorities or simply check what's coming on.

• OTRS Neuigkeiten

A complete list about OTRS activities and so important information about new product releases or patches.

• Online

Here is showed a summary about the current agents logged the system, it also includes a section for customers on-line, please notice this widget is normally hidden, it can be shown using Settings widget described before.

7. Was verbirgt sich hinter dem

Begriff Queue?

Normalerweise werden E-Mails in einer INBOX gespeichert und verwaltet. Eine INBOX ist eine große Datei, in der alle E-Mails aneinandergereiht werden. Neue E-Mails werden einfach an das Ende der INBOX angehängt. Das E-Mail-Programm, welches Sie zum Lesen und Bearbeiten Ihrer Nachrichten benutzen, liest die INBOX-Datei aus und bereitet den

Inhalt für Sie als Nutzer auf.

Eine Queue in OTRS ist ein Mechanismus, mit dessen Hilfe viele Tickets gespeichert und verwaltet werden können, also auch eine Art INBOX. Als Anwender ist es völlig unwichtig zu wissen, wo oder wie das Ticket gesichert ist. Wichtig ist nur, zu wissen, welcher Queue das Ticket zugeordnet wurde. Anwender, also die sog. Agents (z. B. die Mitarbeiter ihrer

Supportabteilung), können nun Tickets zwischen den Queues verschieben! Warum aber sollten sie das tun?

Gehen wir zur praktischeren Erklärung noch mal von Max Mustermanns Unternehmen aus dem Abschnitt ein Beispiel für ein Trouble Ticket System aus. Max Mustermann hat nach seinem anfänglichen Support-Chaos OTRS installiert, und er und seine Mitarbeiter nutzen das System zur Bearbeitung der Anfragen für die Videorekorder.

One queue holding all requests is enough for this situation. However, after some time Max decides to also sell DVD recorders. Now, the customers have questions not only about the video recorder, but also about the new product. More and more emails get into the single queue of Max's OTRS and it's difficult to have a clear picture of what's happening.

Max decides to restructure his support system, and adds two new queues. So now three queues are being used. New messages arriving at the ticket system are stored into the old queue titled "raw". Of the two new queues, one titled "video recorder" is exclusively for video recorder requests, while the other one titled "dvd recorder" is exclusively for dvd recorder requests.

Max asks Sandra to watch the "raw" queue and sort (dispatch) the messages either into

"video recorder" or "dvd recorder" queue, depending on the customer request. John only has access to the "video recorder" queue, while Joe can only answer tickets in the "dvd recorder" queue. Max is able to edit tickets in all queues.

OTRS supports access management for users, groups, and roles, and it is easy to setup queues that are accessible only to some user accounts. Max could also use another way to get his requests into the different queues, with filter rules. Otherwise, if two different mail addresses are used, Sandra only has to dispatch those emails into the two other queues, which can't be dispatched automatically.

Das Sortieren von Mails in verschiedene Queues schafft also Ordnung und mehr Übersicht in der täglichen Mailflut, deshalb sind Queues sehr wichtig für OTRS. Durch die Einteilung der Mitarbeiter (agents) in verschiedene Benutzergruppen mit differenzierten Zugriffsrechten auf die einzelnen Queues, kann die Abarbeitung der Anfragen weiter optimiert werden. Mit Hilfe von Queues können Sie die Struktur Ihres Unternehmens abbilden bzw.

einzelne Geschäftsvorgänge abgrenzen. So könnte Max Mustermann neben seinem Support-Queues für die verschiedenen Geräte für Bestellungen eine Queue mit dem Namen

"Sales" anlegen und als Unter-Queues "Anfragen", "Angebote", "Bestellungen" usw. definieren, um den Bestellvorgang zu optimieren.

Je besser und strukturierter ein Support- system organisiert ist, desto weniger Zeit und letztlich auch finanzielle Mittel müssen dafür aufgebracht werden. Queues und Unter-

Queues helfen bei der Strukturierung bzw. bei der Abbildung von Abläufen.

8. Was ist die Queue-Übersicht?

The queue overview offers a view of all queues in which tickets are present, and for which the user has RW permissions.

The queue overview offers a variaty of options for daily work with OTRS. The first of theese is the My Queue. In the Agent Preferences, or when administering agents, a set of queuse

can be defined for which the agent has been assigned to work within. All the tickets will appear in this default view, when accessing the Ticket -> Queue View menu.

The second option offered by the Queue View is a drill down navigation into individual queues and sub-queues containing tickets to be worked upon.

In both of the view types, the user also has the added ability to see either all unlocked tickets (this is the default filter), or the user can then chooose to view all available tickets.

Tickets must be in one of the viewable state types to be shown in the queue view. Per default, these are 'open, new, pending reminder, pending auto'.

There are visual alarms, to aid the user.

visuelle Alarme

• Highlight Age 1: Sets the age in minutes (first level) for highlighting queues that contain untouched tickets. Seen in above in the "Raw" queue.

• Highlight Age 2: Sets the age in minutes (second level) for highlighting queues that contain untouched tickets. Seen in above in the "Postmaster" queue.

• Blink: Activates a blinking mechanism of the queue that contains the oldest ticket. Not supported in all browsers. In that case it will appear red, as seen in above in the "Junk" queue.

• Bold: The current queue will be bolded, as seen above in the "My Queues".

9. Benutzereinstellungen

Die Einstellungen eines Accounts lassen sich mit Hilfe der Benutzereinstellungen den eigenen Wünschen entsprechend anpassen. Dabei spielt keine Rolle, ob man als Mitarbeiter, Kunde oder Administrator am System angemeldet ist. Die Benutzereinstellungen sind über den Link auf den Benutzernamen erreichbar, Kunden müssen den "Einstellungen"-Link verwenden.

Abb.: Benutzereinstellungen des Agenten.

Ein Agent kann 3 verschiedene Kategorien von Einstellungen vornehmen: Benutzerprofil,

E-Mail-Einstellungen und andere Einstellungen. Folgende Einstellungen sind möglich:

Benutzerprofil

• Aktuelles Passwort ändern.

• Sprache der Benutzeroberfläche wechseln.

• Oberflächen-Skin auswählen.

• Oberflächen-Theme auswählen.

• Abwesenheitszeit aktivieren und konfigurieren.

E-Mail-Einstellungen

• Ereignisse auswählen, bei denen eine E-Mail-Benachrichtigung durch das System erfolgen soll.

Andere Einstellungen

• Wählen Sie die Queues aus, die sie in "Meine Queues" überwachen wollen.

• Aktualisierungszeit der Queue-Ansicht einstellen.

• Bildschirm auswählen, der nach Erstellung eines Tickets angezeigt wird.

Abb.: Benutzereinstellungen des Kunden.

Ein Kunde kann die Sprache der Benutzeroberfläche wechseln, die Aktualisierungszeit der

Ticketübersichten verändern und die max. Anzahl angezeigter Tickets pro Seite einstellen.

Zusätzlich kann das Passwort geändert werden.

Kapitel 4. Administration

1. Der Administrationsbereich von

OTRS

1.1. Grundlagen

The following system configuration settings are available to OTRS administrators by accessing the Admin page of the OTRS web interface - adding agents, customers and queues, ticket and mail settings, installing additional packages such as FAQ and ITSM, and much more.

Agents who are members of the admin group can access the Admin area by clicking the

Admin link in the navigation bar (see Figure below). Agents without sufficiently elevated access rights will not be able to access this link.

Abb.: OTRS Administrationsbereich.

1.2. Benutzer, Gruppen und Rollen

1.2.1. Benutzer

By clicking the link Agents, you get access to the agent management screen of OTRS (see

Figure below). Administrators can add, change or deactivate agent accounts. Furthermore they can also manage agent preferences, including the language and notification settings for the individual agent's interface.

Anmerkung

Ein OTRS-Benutzer kann deaktiviert, aber nicht gelöchst werden. Um einn Benutzer zu deaktivieren, setzen Sie die Einstellung für "Gültig" auf "ungültig" oder

"ungültig-temporär".

Abb.: Benutzerverwaltun.

To register an agent, click on the "Add agent" button, enter the required data and press the Submit button at the bottom of the screen, as shown in Figure.

Abb.: Hinzufügen einens Benutzers.

Nachdem Sie einen neuen Benutzer angelegt haben, muss dieser einer Gruppe bzw. einer

Rolle zugewiesen werden. Sie werden nach dem Anlegen eines neuen Benutzers automatisch auf die Bildschirmmaske für die Zuweisung eines Benutzers in Gruppen weitergeleitet. Weitere Informationen über Gruppen und Rollen finden Sie in den Abschnitten

Gruppen und Rollen dieses Kapitels.

1.2.2. Gruppen

Jeder Mitarbeiter mit einem Account im OTRS, sollte mindestens einer Benutzergruppe angehören. In einer Neuinstallation sind drei vordefinierte Gruppen verfügbar.

Tabelle 4.1. Standardmäßig vorhandene Gruppen in OTRS

Gruppe

admin

Beschreibung

Gruppe für die Benutzer mit Administrationsrechten.

Gruppe

stats users

Beschreibung

Benutzer in dieser Gruppe dürfen lesend

(ro) oder schreibend (rw) auf das Statistikmodul von OTRS zugreifen, d.h. sie können

Statistiken einsehen oder auch erstellen.

Dies ist die Gruppe, in die normale Mitarbeiter aufgenommen und mit den kompletten Rechten ausgestattet werden sollten.

Dadurch wird für die Mitarbeiter das normale Arbeiten im System ermöglicht, der

Zugriff auf alle Funktionen rund um Tickets ist gegeben.

Anmerkung

In a brand new OTRS installation, the users group initially does not have any members. The agent 'root@localhost' belongs by default to the admin and stats groups.

Sie können durch Klick auf "Gruppen" im Administrationsbereich in die Gruppenverwaltung gelangen.

Abb.: Gruppenverwaltung.

Anmerkung

In OTRS können Gruppen deaktiviert, aber nicht gelöscht werden. Deaktivieren Sie eine Gruppe, indem Sie für "Gültig" den Wert entweder auf "ungültig" oder auf

"ungültig-temporär" setzen.

Um einen Benutzer einer Gruppe zuzuweisen bzw. die Gruppenmitgliedschaft eines Benutzers zu ändern, kann der Link "Benutzer <-> Gruppen" im Administrationsbereich genutzt werden.

Abb.: Gruppenverwaltung.

An overview of all groups and agents in the system is displayed on this page. You can also use the available filters to find a specific entity. If you want to change the groups that an agent is a member of, just click on the agent's name (see Figure below). To change the agents associated with a group, just click on the group you want to edit (see Figure below).

Abb.: Bearbeiten der Gruppenzugehörigkeiten eines Benutzers.

Abb.: Bearbeiten der Benutzerzuordnungen einer Gruppe.

Each group has a set of rights associated with it, and each group member (agent) may have some combination of these rights for themselves. A list of the permissions / rights is shown in Table 5-2.

Tabelle 4.2. Mit OTRS-Gruppen verknüpfte Rechte

Berechtigung

Verschieben in (move into) erstellen

Besitzer (owner)

Priorität rw

Beschreibung

Nur Lesezugriff auf die Tickets bzw. Beiträge dieser Gruppe bzw. der Gruppe zugewiesenen Queues oder Bereiche.

Recht zum Verschieben von Tickets oder

Beiträgen innerhalb der Queues bzw. Bereiche dieser Gruppe.

Recht zum Erstellen von Tickets oder Beiträgen in den Queues, bzw. Bereichen dieser

Gruppe.

Recht zum Ändern des Eigentümers von

Tickets, bzw. Beiträgen in den der Gruppe zugewiesenen Queues bzw. Bereiche.

Recht zum Ändern der Priorität von Tickets, bzw. Beiträgen in den der Gruppe zugewiesenen Queues bzw. Bereiche.

Voller Lese- und Schreibzugriff auf alle

Inhalte der dieser Gruppe zugewiesenen

Queues, bzw. Bereiche.

Anmerkung

By default, the QueueView only lists tickets in queues that an agent has rw access to, i.e., the tickets the agent needs to work on. If you want to change this beha-

viour, you can set Ticket::Frontend::AgentTicketQueue###ViewAllPossibleTickets

to Yes.

Nicht alle verfügbaren Berechtigungen werden standardmäßig angezeigt. Diese zusätzlichen Berechtigungen können hinzugefügt werden.

Tabelle 4.3. Weitere Berechtigungsgruppen

Berechtigung

stats

Umleiten

Verfassen

Kunde

Weiterleiten

Warten

Telefon

Verantwortlicher

Beschreibung

Erlaubt den Zugriff auf die Statistikseite

Das Recht eine E-Mail umzuleiten (mit

Umleiten-Knopf im TicketZoom)

Das Recht eine Antwort zu einem Ticket zu verfassen.

Das Recht den Kunden eines Tickets zu

ändern.

Das Recht eine Nachricht weiterzuleiten

(mit dem Weiterleiten-Knopf)

Das Recht ein Ticket auf "warten" zu setzen.

Das Recht einen Telefonanruf zu einem

Ticket hinzuzufügen.

Das Recht den Verantwortlichen Agenten eines Tickets zu ändern.

Anmerkung

Diese Berechtigungen können durch ändern von System::Permission hinzugefügt

werden

1.2.3. Rollen

Roles are a powerful feature to manage the access rights of many agents in a very simple and quick manner. They are particularly useful for large, complex support systems with a lot of agents, groups and queues. An example below explains when they should be used.

Suppose that you have a system with 100 agents, 90 of them with access to a single queue called "support" where all support requests are handled. The "support" queue contains multiple sub queues. The other 10 agents have permission to access all queues of the system. These 10 agents dispatch tickets, watch the raw queue and move spam messages into the "junk" queue.

The company now opens a new department that sells some products. Order request and acceptance, order confirmation, bills, etc. must be processed, and some of the company's agents are supposed to do this using OTRS. The different agents have to get access to the new queues that must be created.

Because it would take a long time to change the access rights for the individual agents manually, roles that define the different access levels can be created. The agents can then be added to one or more roles, with their access rights being modified automatically. If a new agent account is created, it is also possible to add this account to one or more roles.

Anmerkung

Roles are really useful when dealing with complex organizations and when maintaining larger OTRS installations. Proper care is advised though. Mixing Agent to

Group with Agent to Role mappings can make for a complex access control scheme, that is difficult to understand and maintain. If you wish to use only roles and disable the Agents <-> Groups option in the Admin area, you can do so by modi-

fying the Frontend::Module###AdminUserGroup in the SysConfig. Be aware that

this won't remove already existing Agents to Group assignments!

Sie können die Rollenverwaltung durch Klick auf "Rollen" im Administrationsbereich erreichen.

Abb.: Rollenverwaltung.

Anmerkung

In OTRS können Rollen deaktiviert, aber nicht gelöscht werden. Deaktivieren Sie eine Rolle, indem Sie für "Gültig" den Wert entweder auf "ungültig" bzw. "ungültig-temporär" setzen.

Eine Übersicht aller Rollen im System erscheint, um einen Eintrag zu bearbeiten, klicken

Sie einfach auf den Rollennamen. In einer Neuinstallation gibt es keine vordefinierten

Rollen. Um eine anzulegen, klicken Sie auf den "Rolle hinzufügen"-Knopf und geben Sie die erforderlichen Daten an.

Abb.: Anlegen einer neuen Rolle.

Um einen Überblick über alle Rollen und Agenten im System zu erhalten, klicken Sie auf den Link "Rollen <-> Benutzer" im Administrationsbereich. Sie könnnen die Filter verwenden, um einen bestimmten Eintrag zu finden. Wenn Sie die Rollenzordnungen eines

Benutzers ändern wollen, klicken Sie auf den Benutzernamen. Um die Benutzerzuordnungen einer Rolle zu verändern, klicken Sie auf die Rolle.

Abb.: Bearbeiten der Rollenzuordnungen eines Agenten.

Abb.: Bearbeiten der Benutzerzuordnungen einer Rolle.

Um eine Übersicht aller Rollen und Gruppen im System zu erhalten, verwenden Sie den

Link "Rollen <-> Gruppen" im Administrationsbereich.

Abb.: Rollen-Gruppen-Zuordnungen verwalten.

Klicken Sie auf eine Gruppe oder Rolel, um die jeweiligen Zuordnungen zu verändern.

Abb.: Gruppenzuordnungen einer Rolle verändern.

Abb.: Rollenzuordnungen für eine Gruppe verändern.

1.3. Kundenbenutzer und Kundengruppen

1.3.1. Kunden

OTRS supports different types of users. Using the link "Customers" (via the navigation bar, or the Admin page), you can manage the accounts of your customers (see Figure below), who can log into the system via the Customers interface (customer.pl). Through this interface, your customers can not only create tickets but also review their past tickets for new updates. It is important to know that a customer is needed for the ticket history in the system.

Abb.: Kundenverwaltung.

Neben der Möglichkeit in der Datenbank nach einem bestimmten Kunden zu suchen, kann das Backend umgestellt werden, über das auf die Kundendaten zugegriffen wird. In OTRS lassen sich mehrere Datenbanken mit Kundendaten einbinden, genauere Informationen

hierzu finden Sie im Abschnitt Einbinden externer Backends für Agents und Customer.

Um einen neuen Kunden hinzuzufügen, klicken Sie auf "Kunde hinzufügen". Einige Felder sind Pflichtfelder, müssen also ausgefüllt werden.

Abb.: Hinzufügen eines Kunden.

Der Kunde kann mit Benutzername und Passwort auf das System zugreifen. Die Kundennummer wird vom System benötigt, um den Kunden und seine Tickets zu erkennen. Da

E-Mail-Adressen eindeutig sind, können sie als ID verwendet werden.

Anmerkung

In OTRS können Kunden deaktivert, aber nicht gelöscht werden. Sie können einen

Kunden deaktivieren, indem Sie den Wert für "Gültig" auf "ungültig" oder "ungültig-temporär" setzen.

1.3.2. Kundengruppen

Kunden können auch Gruppen zugeordnet werden. Das ist nützlich, wenn Kunden nur auf bestimmte Queues zugreifen können sollen. Legen Sie zuerst die benötigten Gruppen in

der Gruppenverwaltung an . Fügen Sie dann die Queues hinzu und ordnen Sie diese

der neuen Gruppe zu.

The next step is to activate the customer group support. This can be done with the confi-

guration parameter CustomerGroupSupport, from the Admin SysConfig option. Using the

parameter CustomerGroupAlwaysGroups, you can specify the default groups for a newly

added customer, so that every new account will be automatically added to these groups.

Über den Link "Kunden <-> Gruppen" können Sie nun die Zuordnung der Kundenbenutzer in die gewünschten Gruppen vornehmen.

Abb.: Verwaltung der Kunden-Gruppen-Zuordnungen.

Klicken Sie auf den Kunden- oder Gruppennamen, um die jeweiligen Zuordnungen zu bearbeiten.

Abb.: Gruppenzuordnungen eines Kunden bearbeiten.

Abb.: Kundenzuordnungen einer Gruppe bearbeiten.

1.4. Queues

Über den Link "Queue" innerhalb des Admin-Bereiches von OTRS können Sie die Queues

Ihres Systems verwalten. Nach einer Standard-Installation sind bereits die Queues "Junk",

"Misc", "Postmaster" und "Raw" im System angelegt. "Raw" ist die Default-Queue, in ihr landen alle neuen Tickets, so lange kein Filter definiert wurde. "Junk" kann z. B. zum Aussortieren von Spam-Mails genutzt werden.

Abb.: Queue-Verwaltung.

Hier können Sie Queues anlegen und verändern. Zusätzlich zum Namen der neuen Queue kann angegeben werden, für welche Benutzergruppe die Queue bereitgestellt werden und ob die neue Queue eine Unter-Queue (sub queue) von einer bereits in Ihrem System vorhandenen Queue sein soll.

Abb.: Hinzufügen einer Queue.

Wurde ein Ticket von einem Agenten gesperrt, so können Sie mit Hilfe des Freigabezeit-Intervalls festlegen, wann ein Ticket wieder automatisch vom System freigegeben werden soll. So können auch die anderen Mitarbeiter wieder auf dieses Ticket zugreifen und es bearbeiten.

Drei Arten von Eskalationszeiten können pro Queue eingestellt werden:

Eskalation - Zeit für die erste Reaktion

• After creation of the ticket, if the time defined here expires without any communication with the customer, either by email or phone, the ticket is escalated.

Eskalation - Aktualisierungszeit

• If there is a customer followup either via e-mail or the customer portal, that is recorded in the ticket, the escalation update time is reset. If there is no customer contact before the time defined here expires, the ticket is escalated.

Eskalation - Lösungszeit

• Wenn das Ticket nicht innerhalb der definierten Zeitdauer geschlossen werden kann, eskaliert es.

Weiterhin können Sie festlegen, dass bei einem Follow-Up auf ein Ticket wieder der Mitarbeiter Eigentümer dieses Tickets wird, der zuletzt als Eigentümer im System für dieses

Ticket vermerkt war. Dies stellt sicher, dass die Nachfrage eines Kunden zuerst bei demselben Mitarbeiter landet, der sich zuletzt um dieses Ticket gekümmert hat.

The parameter for the system address specifies the email address that will be used for the outgoing tickets of this queue. There is also the possibility to associate a queue with a salutation and a signature, for the email answers. For more detailed information, please

refer to the sections email addresses, salutations and signatures.

Anmerkung

In OTRS können Queues deaktiviert, aber nicht gelöscht werden. Sie können eine

Queue deaktivieren, indem Sie den Wert für "Gültig" auf "ungültig" oder "ungültig-temporär" setzen.

1.5. Anreden, Signaturen, Anlagen und Antwortvorlagen

1.5.1. Anreden

A salutation is a text module for a template. Salutations can be linked to one or more

queues, as described in the section about queues. A salutation is used only if a ticket from

a queue the salutation is linked to, is answered. To manage the different salutations of your system, use the "Salutations" link of the admin area (see Figure below).

Abb.: Verwaltung der Anreden.

Nach einer Standardinstallation von OTRS sind bereits eine Anrede im System gespeichert, "system standard salutation (en)".

To create a new salutation, press the button "Add salutation", provide the required data and submit it (see Figure below).

Abb.: Anrede hinzufügen.

In Anreden können Variablen verwendet werden. Wenn Sie auf ein Ticket antworten, werden die Variablennamen durch die zugehörigen Werte ersetzt.

The different variables you can use in templates are listed in the lower part of the salutation screen. If you use, for example, the variable <OTRS_LAST_NAME> the last name of the ticket's sender will be included in your reply.

Anmerkung

In OTRS können Anreden deaktiviert, aber nicht gelöscht werden. Sie können eine

Anrede deaktivieren, indem Sie den Wert für "Gültig" auf "ungültig" oder "ungültig-temporär" setzen.

1.5.2. Signaturen

Another text module for a template is the signature. Signatures can be linked to a queue,

as described in the section about the queues. Please note that a signature will only be

appended to a template text, if it has previously been linked to a queue. You can manage the signatures in your system by accessing the "Signatures" link of the Admin page, (see

Figure below).

Abb.: Signaturverwaltung.

Nach einer Standardinstallation von OTRS ist bereits eine Signatur im System vorhanden,

"system standard signature (en)".

Verwenden Sie den Knopf "Signatur hinzufügen", um eine neue Signatur anzulegen.

Abb.: Signatur hinzufügen.

Like salutations, signatures can also contain dynamic content, such as the first and last name of the agent who answers the ticket. Here too, variables can be used to replace the content of the signature text for every ticket. See the lower part of the signatures screen for the variables which can be used. If you include the variable <OTRS_LAST_NAME> in a signature for example, the last name of the agent who answers the ticket will replace the variable.

Anmerkung

In OTRS können Signaturen deaktiviert, aber nicht gelöscht werden. Sie können eine Signatur deaktivieren, indem Sie den Wert für "Gültig" auf "ungültig" oder

"ungültig-temporär" setzen.

1.5.3. Anlagen

You can also optionally add one or more attachments to a template. If the template is selected, the attachments will be attached to the message composition window. If necessary, the agent can remove the attachment from an individual template before sending it to the customer.

Über den "Anlagen"-Link im Admin-Bereich können Sie neue Anlagen in das System integrieren.

Abb.: Verwaltung der Anlagen.

To create a new attachment, press the button "Add attachment", provide the required data and submit it (see Figure below).

Abb.: Anlage hinzufügen.

If an attachment is stored it can be linked to one or more templates. Click on the "Attachment <-> Templates" link of the Admin page (see Figure below).

Abbildung.: Zuordnung von Anlagen zu Antworten.

To associate different attachments with a specific template and vice versa, click on the corresponding template name or attachment (see below the Figures 5.27 and 5.28, respectively).

Abbildung: Anlagenzuordnungen einer Vorlage verändern.

Abbildung: Antwortvorlagen-Zuordnungen einer Anlage verändern.

1.5.4. Vorlagen

To speed up ticket processing and to standardize the look of answers, you can define templates in OTRS. A template can be linked to one or more queues and vice versa.

There are different kind of templates that are used in different parts of OTRS and they have its own purpose, the following is the list of possible template types:

• Antwort: Als Ticketantwort oder Rückantwort verwendet.

• Erstellen: In neuen Telefon- oder E-Mailtickets verwendet.

• Weiterleiten: Verwendet um einen Artikel an jemand Anderen weiterzuleiten.

• Telefonanruf: In Telefonanruf eingehend und ausgehend verwendet.

Answer templates can be accessed in two ways, from the ticket zoom screen in the article menu, or on a quicker way: from any ticket overview large screen such as Status View or

Ticket View. For a fresh OTRS installation, the "empty answer" template (Answer) is set as the default for every queue.

As soon as Forward templates are added and assigned to queues, the "Forward" button in ticket zoom (that normally leads to a empty text forward screen) will change into a selection control, the selection is filled with the added Forward templates, by choosing one of the templates, the forward screen will be shown prefilled with the template text and attachments (similar to the reply selection box with the Answer templates).

Creating templates of type Create and PhoneCall will make visible the "Text Template" selection box in their respective screens, choosing a template for the list will populate the "Text" and "Attachment" fields (if available in the template). Notice that any previous change in the Text or attachments will be overwritten by selecting a template.

Clicking the "Templates" link on the Admin page brings you to the Template management screen (see Figure below).

Abbildung.: Vorlagen-Verwaltung.

To create a new template, click on the "Add template" button, provide the required data

(make sure to select the appropriate template type) and submit it (see Figure below).

Abbildung.: Anlegen einer Vorlage.

To add/remove templates to one or more queues, click on the "Templates <-> Queues" link on the Admin page (see Figure below). You can also use filters to get information regarding a specific entity.

Abbildung.: Queue-Antwort-Zuordnungen verwalten.

To define the different templates that will be available for a queue and vice versa, click on the corresponding template or queue (see below the Figures 5.32 and 5.33, respectively).

Abbildung.: Ändern der Queue-Zuordnungen einer Vorlage ändern.

Abbildung.: Antwort-Zuordnungen einer Queue ändern.

When choosing a template, additional information could be added to the template text, this depends on the template type:

PhoneCall and Create templates does not add any content to the template text, however

New Email Ticket screen adds the queue assigned signature to the resulting email body

(this screen has a separated box to visualize the signature).

Answer templates text when selected also included the salutation associated with the queue, then the text of the template, then the quoted ticket text, and finally the signature associated with the queue.

Forward templates are similar to Answer templates, but they does not include the salutation part.

1.6. Automatische Antworten

OTRS allows you to send automatic responses to customers based on the occurrence of certain events, such as the creation of a ticket in a specific queue, the receipt of a follow-up message in regards to a ticket, the closure or rejection of a ticket, etc. To manage such responses, click the link "Auto responses" on the Admin page (see Figure below).

Abb.: Verwaltung automatischer Antworten.

Verwenden Sie den Knopf "Automatische Antwort hinzufügen", um eine neue anzulegen.

Abb.: Automatische Antwort hinzufügen.

Für die Betreffzeile und den Text von automatischen Antworten kann genauso wie bei

Signaturen oder Anreden, der Inhalt mit Hilfe von OTRS-Variablen dynamisch erzeugt werden. So werden über die Variable <OTRS_CUSTOMER_EMAIL[5]> die ersten 5 Zeilen der an das System gesendeten E-Mail in die automatische Antwort eingefügt, oder durch

<OTRS_CUSTOMER_FROM> die From-Zeile. Die Anmerkungen im unterem Bereich der

Bildschirmmaske zur Verwaltung der automatischen Antworten listen alle OTRS-Variablen auf, die verwendet werden können.

Für jede automatische Antwort können Sie angeben, durch welches Ereignis sie ausgelöst werden soll. Folgende Ereignisse sind in einer Standardinstallation verfügbar:

Tabelle 4.4. Ereignisse für automatische Antworten

Name

auto reply auto reply/new ticket auto follow up auto reject auto remove

Beschreibung

Dieses Ereignis tritt ein, wenn ein neues

Ticket in einer Queue angelegt wird.

Dieses Ereignis tritt ein, wenn ein bereits geschlossenes Ticket, z. B. durch die Antwort eines Kunden, mit einer neuen Ticketnummer erneut geöffnet wird.

Dieses Ereignis tritt ein, wenn ein Follow up für ein bereits vorhandenes Ticket eintrifft.

Dieses Ereignis tritt ein, wenn ein Ticket vom System zurückgewiesen wird.

Dieses Ereignis tritt ein, wenn ein Ticket vom System entfernt wird.

Anmerkung

As with other OTRS entities, auto responses too cannot be deleted, only deactivated, by setting the Valid option to invalid or invalid-temporarily.

Um eine automatische Antwort einer oder mehreren Queues zuzuweisen, folgen Sie im

Admin-Bereich den Link "Auto Antworten <-> Queues". Dort sind für jede Queue die verschiedenen Ereignistypen aufgelistet und es kann eine Zuordnung einer Auto-Antwort vom gleichen Ereignistyp durchgeführt bzw. entfernt werden.

Abb.: Zuordnungen von Queues zu automatischen Antworten verwalten.

To define the different auto responses that will be available for a queue, click on the corresponding queue name (see Figure below). It is also possible to edit an existing auto response - to do so, click on the response and edit in the same manner as editing a new auto response.

Abb.: Zuordnung von automatischen Antworten zu einer Queue bearbeiten.

1.7. E-Mail-Adressen

Um aus OTRS heraus E-Mails verschicken zu können, benötigen Sie mindestens eine gültige Mailadresse. Da in vielen Fällen eine Mailadresse nicht ausreicht, ist OTRS auch in der

Lage, mit mehreren Mailadressen zu arbeiten. Eine Queue mit mehreren E-Mail-Adressen verknüpft werden, und umgekehrt. Die Adresse, die für ausgehende Nachrichten einer

Queue benutzt werden soll, kann bei Erstellung oder Bearbeitung der Queue ausgewählt werden. Verwenden Sie den Link "E-Mail-Adressen" im Administrationsbereich, um die

Adressen des Systems zu verwalten.

Abb.: Verwaltung der E-Mail-Adressen des Systems.

If you create a new mail address (see Figure below),you can select the queue or sub queue to be linked with it. This link enables the system to sort incoming messages via the address in the To: field of the mail into the right queue.

Abb.: Hinzufügen einer System-E-Mail-Adresse.

Anmerkung

In OTRS können E-Mail-Adressen deaktiviert, aber nicht gelöscht werden. Sie können eine Adresse deaktivieren, indem Sie den Wert für "Gültig" auf "ungültig" oder

"ungültig-temporär" setzen.

1.8. Benachrichtigungen

OTRS allows notifications to be sent to agents and customers, based on the occurrence of certain events. Agents can set the system events for their own notifications via the

preferences link.

Über den "Benachrichtigungen"-Link im Admin-Bereich erreichen Sie die Verwaltung der

Benachrichtigungen. Mit den Filtern können Sie bestimmte Einträge finden.

Abb.: Verwaltung der Benachrichtigungen.

Den Betreff und Text der Benachrichtigungen können Sie anpassen. Wählen Sie die gewünschte Benachrichtigung aus der Liste durch Klick aus. Beachten Sie: in jeder Sprache gibt es eine Benachrichtigung mit demselben Namen.

Abb.: Berarbeiten einer Benachrichtigung.

Auch innerhalb der Benachrichtigungen können die Textinhalte mit Hilfe der OTRS-Variablen dynamisch aufbereitet werden. Innerhalb der Anmerkungen im unteren Bereich der

Bildschirmmaske zur Benachrichtigungen-Verwaltung werden die verschiedenen zur Verfügung stehenden Variablen und deren Verwendung aufgelistet und näher erklärt.

Ebenso ist es möglich, Benachrichtigungen zu erstellen, die auf Ereignissen basieren. Hier können Sie detailliert einstellen, wann diese Benachrichtigung geschickt werden soll. Zudem kann ein weites Spektrum von Parametern konfiguriert werden, wie:

Empfängergruppen(n), Benutzer, Rollen, E-Mail-Adressen; Ereignistyp, der die Benachrichtigung auslöst, Ticket-Typ, Status, Priorität, Sperre, Service, SLA, usw.

Um eine Übersicht aller ereignisbasierten Benachrichtigungen zu erhalten, klicken Sie auf

"Benachrichtigungen (Ereignis)" im Administrationsbereich.

Abb.: Ereignisbasierte Benachrichtigungen verwalten.

Erstellen Sie eine neue Benachrichtigung durch Klick auf den "Hinzufügen"-Knopf.

Abb.: Ereignisbasierte Benachrichtigung einrichten.

Auch in den ereignisbasierten Benachrichtigungen können Sie mit den speziellen Variablen dynamische Texte erzeugen. Die Referenz der Variablen sehen Sie im unteren Bildschirmbereich.

1.9. S/MIME

OTRS can process incoming S/MIME encoded messages and sign outgoing mails. Before

this feature can be used, you need to activate it and change some configuration parameters in the SysConfig.

Über den "SMIME"-Link im Admin-Bereich von OTRS erreichen Sie die Verwaltung der SMI-

ME-Zertifikate. Es können Zertifikate und private Fingerprints hinzugefügt und entfernt werden und eine Suche in den Zertifikaten ist möglich.

Abb.: S/MIME-Verwaltung.

1.10. PGP

OTRS handles PGP keys, which allows you to encrypt/decrypt messages and to sign outgoing messages. Before this feature can be used, you need to activate it and change

some configuration parameters in the SysConfig.

Über den "PGP"-Link im Admin-Bereich von OTRS erreichen Sie die Verwaltung des Schlüsselrings Ihres Systems. Es können Schlüssel und Signaturen hinzugefügt und entfernt werden und eine Suche innerhalb des Schlüsselrings ist möglich.

Abb.: PGP-Verwaltung.

1.11. Status

Über den Link "Status" können Sie die verschiedenen Ticket-Status bearbeiten, die Sie in

OTRS verwenden möchten.

Abb.: Status-Verwaltung.

In einer Standardinstallation sind folgende Status definiert:

• erfolgreich geschlossen

• erfolglos geschlossen

• zusammengefasst

• neu

• öffnen

• warten auf erfolgreich schließen

• warten auf erfolglos schließen

• warten zur Erinnerung

• entfernt

Jeder Status ist mit einem Typ verküpft. Auch bei dem Neuanlegen eines Status muss ein

Typ angegeben werden. Die standardmäßig verfügbaren Status-Typen sind:

• geschlossen

• zusammengefasst

• neu

• öffnen

• warten auto

• warten zur Erinnerung

• entfernt

1.12. Die SysConfig (Verwaltung der Systemkonfiguration)

In der SysConfig werden die meisten Konfigurationseinstellungen von OTRS vorgenommen.

The SysConfig link on the Admin page loads the graphical interface for system configuration (see Figure below). You can upload your own configuration files for the system, as well as backup all your current settings into a file. Almost all configuration parameters of the OTRS framework and installed applications can be viewed and changed through this interface. Since all configuration parameters are sorted into groups and sub groups, it is possible to navigate quickly through the vast number of existing parameters. It is also possible to perform a full-text search through all of the configuration parameters.

Abb.: Das grafische Konfigurationsfrontend von OTRS (SysConfig).

Das Kapitel Nähere Beschreibung der grafischen Administrationsoberfläche geht ausführ-

licher auf das grafische Konfigurations-Frontend ein.

1.13. Einrichten von Mail-Konten

There are several possibilities to transport new emails into the ticket system. One way

is to use a local MTA and the otrs.PostMaster.pl script that pipes the mails directly into

the system. Another possibility is the use of mail accounts which can be administrated through the web interface. The "PostMaster Mail Accounts" link on the Admin page loads the management console for the mail accounts (see Figure below). OTRS supports the mail protocols: POP3, POP3S, IMAP and IMAPS.

Abb.: Verwaltung von Mail-Konten.

See the section about PostMaster Mail Accounts for more details.

1.14. Einkommende E-Mail-Nachrichten filtern

OTRS has the capability to filter incoming email messages. For example, it is possible to put certain emails automatically into specified queues, or to set a specific state or ticket type for some mails. The filters apply to all incoming mails. You can manage your filters via the link "PostMaster Filter" on the Admin page (see Figure below).

Abb 5.49. Verwaltung von Filterregeln für eingehende E-Mails.

A filter consists of one or more criteria that must be met in order for the defined actions to be executed on the email. Filter criteria may be defined for the headers or the body of an email, e.g. search for specific header entries, such as a sender address, or on strings in the body. Even regular expressions can be used for extended pattern matching. If your filter matches, you can set fields using the X-OTRS headers in the GUI. These values will be applied when creating the ticket or follow-up message in OTRS. The Table 5-4 lists the different X-OTRS headers and their meaning.

Hinweis: Sie können auch X-OTRS-FollowUp-* header für Follow-Up-E-Mails verwenden.

Tabelle 4.5. Funktion der verschiedenen X-OTRS-Header

Name

X-OTRS-Priority:

X-OTRS-Queue:

X-OTRS-Lock:

X-OTRS-Ignore:

Mögliche Werte

1 very low, 2 low, 3 normal,

4 high, 5 very high

Name einer Queue des Systems.

lock, unlock

Yes oder True

Beschreibung

Legt die Priorität eines

Tickets fest.

Sets the queue where the ticket shall be sorted. If set in X-OTRS header, all other filter rules that try to sort a ticket into a specific queue are ignored. If you use a sub-queue, specify it as

"Parent::Sub".

Setzt den "gesperrt"-Status eines Tickets.

Wird dieser Header gesetzt, wird die Mail komplett ignoriert und gelangt somit nie als Ticket in das System.

X-OTRS-State: new, open, closed successful, closed unsuccessful, ...

Setzt den nächsten Status eines Tickets.

X-OTRS-State-PendingTime: Z. B. 2010-11-20 00:00:00 Sets the pending time of a ticket (you also should sent a pending state via X-

OTRS-State). You can specify absolute dates like

"2010-11-20 00:00:00" or relative dates, based on the arrival time of the email.

Use the form "+ $Number $Unit", where $Unit can be 's' (seconds), 'm' (minutes), 'h' (hours) or 'd' (days).

Only one unit can be specified. Examples of valid settings: "+50s" (pending in 50 seconds), "+30m" (30 minutes), "+12d" (12 days). Note that settings like "+1d 12h" are not possible. You can specify "+36h" instead.

X-OTRS-Type:

X-OTRS-Service: default (systemabhängig) Setzt den Ticket-Typ (wenn

Ticket::Type aktiviert ist).

(systemabhängig) Sets the service of a ticket

(if Ticket::Service is active).

Name

X-OTRS-SLA:

X-OTRS-CustomerUser:

X-OTRS-CustomerNo:

X-OTRS-SenderType:

X-OTRS-ArticleType:

X-OTRS-

DynamicField-<Dynamic-

FieldName>:

X-OTRS-Loop:

Mögliche Werte

(systemabhängig)

CustomerUser

CustomerNo agent, system, customer

Beschreibung

If you want to set a sub-service you should specify it as

"Parent::Sub".

Setzt das Service-Level-

Abkommen eines Tickets

(wenn Ticket::Service aktiv ist).

Legt den Kunden-Benutzer fest, dem das Ticket zugeordnet werden soll.

Legt die Kunden-ID fest, die dem Ticket zugeordnet werden soll.

Legt die Art des Ticket-

Absenders fest.

Legt den Typ des Artikles für das eingehende Ticket fest.

email-external, email-internal, email-notification-ext, email-notification-int, phone, fax, sms, webrequest, note-internal, note-external, note-report

Depends on Dynamic Field configuration (Text: Notebook, Date: 2010-11-20

00:00:00, Integer: 1)

True

Saves an additional info value for the ticket on <DynamicFieldName>

Dynamic Field.

Ist dieser X-OTRS-Header gesetzt, wird keine automatische Antwort an den

Absender des neuen Tickets geschickt, z. B. um Mailschleifen zu vermeiden.

You should specify a name for every filter rule. Filter criteria can be specified in the section

"Filter Condition". Choose via the listboxes for "Header 1", "Header 2" and so on for the parts of the messages where you would like to search, and specify on the right side the values you wish to filter on. In the section "Set Email Headers", you can choose the actions that are triggered if the filter rules match. You can select for "Header 1", "Header 2" and so on to select the X-OTRS-Header and set the associated values (see Figure below). Filter rules are evaluated in alphabetical order, and are all executed except if the "Stop after match" setting has been set to "Yes" in one of the rule (in this case evaluation of the remaining filters is cancelled).

Abb.: Filter-Regeln für eingehende Nachrichten anlegen.

Beispiel 4.1. Aussortierung von Spammails in eine bestimmte

Queue

A useful filter rule would be to let OTRS automatically move mails marked for spam ,by using a spam detection tool such as SpamAssassin, into the "Junk" queue. SpamAssassin adds the "X-Spam-Flag" header to every checked mail. When the mail is marked as spam, the Header is set to "Yes". So the filter criteria would be "X-Spam-Flag: Yes". To create a filter rule with this criteria you can insert the name as, for example, "spam-mails". In the section for "Filter Condition", choose "X-Spam-Flag:" for "Header 1" from the listbox. Insert

"Yes" as value for this header. Now the filter criteria is specified. To make sure that all spam mails are placed into the "Junk" queue, choose in the section for "Set Email Headers", the

"X-OTRS-Queue:" entry for "Header 1". Specify "Junk" as value for this header. Finally add the new filter rule to activate it for new messages in the system.

There are additional modules, that can be used to filter incoming messages more speci-

fically. These modules might be useful when dealing with larger, more complex systems.

1.15. Ausführen von automatisierten Jobs mit

Hilfe des GenericAgents

The GenericAgent is a tool to execute tasks automatically. The GenericAgent, for example, can close or move tickets, send notifications on escalated tickets, etc.

Click the link "GenericAgent" on the Admin page (see Figure below). A table with all automated jobs in the system is displayed. These jobs can then be edited, run manually or removed entirely.

Abb.: Jobliste des GenericAgent.

Click the "Add job" button to create a new job. You first need to supply a name. Then you can specify how the job will be executed: automatic at fixed times (like a cronjob, this mode will operate on all tickets found by the ticket filter) or based on ticket events

(right after a single ticket was modified, if it matches the ticket filter). Note that if you manually run event based jobs from the overview screen, they will operate on all tickets fund by the ticket filter.

Abb.: Anlegen eines GenericAgent-Jobs.

For every job, you can specify a ticket filter, for example to only operate on tickets in a certain queue. All filter criteria must be met for a job to be run on a ticket.

Finally, the ticket can be modified by setting various ticket fields like a new queue or state.

It is possible to attach a note to the ticket(s) or run a execute a customized module. You also have the option to delete the ticket(s) from the database. This can be useful to purge outdated or invalid data from the system.

Warnung

If you use the ticket delete function, all affected tickets and their attachments will be removed from the database and cannot be restored!

After editing a job, OTRS will return to the overview screen. There you have the possibility to run any job manually. If you choose to run a job, you will first see all tickets which will be affected when the job actually is run. This list helps you to verify that the job is working as intended. At this point no changes have been made to these tickets yet. Only if you confirm the screen the job will be executed.

1.16. Administrator-E-Mail

Um als OTRS-Administrator eine Mail an bestimmte Benutzer (Agenten) oder Benutzergruppen im System zu versenden, folgen Sie dem Link "Admin Notification".

Abb.: Administrator-Benachrichtigung.

Es wird ein Formular geladen, in das Sie die Absenderadresse, den Betreff und den Inhalt der Administratoren-Mitteilung eintragen können. Weiterhin können Sie aus der Tabelle auswählen, an welche Benutzer und / oder Benutzergruppen bzw. Rollen die Mitteilung gesendet werden soll.

1.17. Sitzungsverwaltung

Um eine Übersicht über die gerade im System angemeldeten Benutzer und deren Sitzungseigenschaften zu erhalten, folgen Sie dem Link "Sitzungsverwaltung" der Administrationsoberfläche.

Abb.: Sitzungsverwaltung.

Some statistics about all active sessions are displayed, e.g. how many agents and customer users are logged in and the number of active sessions. Any individual session can be removed by clicking on the Kill this session link on the right-hand side of the list. You also have the option to Kill all sessions, which can be useful if you want to take the system offline. Detailed information for every session is available, too (see Figure below).

Abb.: Sitzungsdetails.

1.18. System Log

Der Link "System Log" ermöglicht es, die letzten Logeinträge des Ticket-Systems über die

Weboberfläche einzusehen.

Abb.: System Log.

Ein Logeintrag setzt sich aus der Zeit, der Priorität, der betroffenen Systemkomponente und der eigentlichen Meldung zusammen.

Anmerkung

System logs are available via the web interface only on Linux / Unix systems. On

Windows systems, you can see the logs using a text editor by opening the file

[install_dir]otrs\var\log\otrs.log

1.19. SQL-Abfragen mit Hilfe der SQL Box

The "SQL Box" link on the Admin page opens a screen that lets you query the content of the tables in the OTRS database (see Figure below). It is not possible to change the content of the tables, only 'select' queries are allowed.

Abb.: SQL Box.

1.20. Paketverwaltung

Mit der "Paketverwaltung" in der Administrationsoberfläche können Sie Pakete installieren und verwalten, die die Funktionalität von OTRS erweitern. Eine Liste von verfügbaren

Erweiterungsmodulen von OTRS finden Sie unter Zusätzliche Applikationen.

Abb.: Paketverwaltung.

In der Paketverwaltung können Sie die bereits installierten Pakete mit ihrer Versionsinformation einsehen.

Sie können Pakete von einem entfernten Server installieren, indem Sie das Paketverzeichnis im Abschnitt Online-Paketverzeichnis auswählen und auf Verzeichnisinformation

aktualisieren klicken. Die verfügbaren Pakete werden rechts tabellarisch dargestellt. Um eines zu installieren, klicken Sie auf "Installieren". Nach der Installation wird das Paket im

Abschnitt Lokales Verzeichnis dargestellt.

To upgrade an installed package, the list of available packages in the online repository will show Upgrade in the Action column for any package that has a higher version than the one that is installed locally. Just click Upgrade and it will install the new package version on your system.

In some cases, such as when your OTRS system is not connected to the Internet, you can also install those packages that you have downloaded to a local disk. Click the Browse button on the Actions side bar, and select the .opm file of the package on your disk. Click

Open and then Install Package. After the installation has been completed, the package is displayed in the Local Repository section. You can use the same steps for updating a package that is already installed.

In special cases, you might want to configure the Package Manager, e.g., to use a proxy or to use a local repository. Just take a look at the available options in SysConfig under

Framework:Core::Package.

1.21. Web-Services

The Web Services link leads to the graphical interface where web services (for the OTRS

Generic Interface) are created and maintained (see Figure below).

Abbildung.: Die grafische Konfigurationsoberfläche für Webservices.

The graphical interface for web services configuration is described in more detail in the

section "Web Service Graphical Interface".

1.22. Dynamische Felder

Dynamic Fields is the place where you setup and manage custom fields for tickets and articles (see figure below).

Abbildung.: Die Übersichtsseite der dynamischen Felder mit einigen dynamischen Feldern.

The dynamic fields configuration is described in more detail in the section "Dynamic Fields

Configuration".

Each dynamic field type has its own configuration settings and therefore its own configuration screen.

Anmerkung

In the OTRS framework, dynamic fields can only be linked to tickets and articles by default, but they can be extended to other objects as well.

2. Systemkonfiguration

2.1. Die Konfigurationsdateien von OTRS

Alle Konfigurationsdateien des OTRS-Frameworks befinden sich innerhalb des Verzeichnisses Kernel bzw. in Unterverzeichnissen dieses Directorys. Bis auf die Datei Kernel/Config.pm

sollten Sie keine Konfigurationsdatei manuell verändern, da alle anderen

Dateien beim Updaten des Systems überschrieben werden und so Ihre eigenen Einstellungen verloren gehen. Übertragen Sie lediglich die Parameter aus den anderen Dateien nach Kernel/Config.pm und passen Sie die Parameter Ihren Wünschen entsprechend an.

Das Verzeichnis Kernel/Config/Files enthält weitere Konfigurationsdateien, die beim

Starten von OTRS eingelesen werden. Sind zusätzliche Module wie der Filemanager oder der Webmailer installiert, liegen die Konfigurationsdateien dieser Applikationen ebenfalls in Kernel/Config/Files.

If the OTRS web interface is accessed, all .xml files in the Kernel/Config/Files directory are parsed in alphabetical order, and the settings for the central frame-

work and additional applications will be loaded. Afterwards, the settings in the files Kernel/Config/Files/ZZZAAuto.pm, Kernel/Config/Files/ZZZAuto.pm and Kernel/Config/Files/ZZZProcessManagement.pm

(if it exists) will be evaluated. These files are used by the graphical interface for system configuration caching and should never be changed manually. Lastly, the file Kernel/Config.pm that contains your individual settings and manually changed configuration parameters, will be parsed. Reading the configuration files in this order makes sure that your specific configuration settings are used by the system.

2.2. Konfiguration des Systems mit Hilfe des grafischen Konfigurations-Frontends

Since OTRS 2.0, nearly all configuration parameters of the central framework or additional installed applications, can be changed easily with the graphical interface for system configuration. Log in as OTRS administrator and follow the SysConfig link on the Admin page to execute the new configuration tool (see Figure below).

Abb.: Die grafische System-Konfigurationsoberfläche.

Da OTRS mittlerweile über mehr als 600 verschiedene Konfigurationsparameter verfügt, bietet das Konfigurations-Frontend mehrere Möglichkeiten zur schnellen Auffindung der gewünschten Einstellung. Es kann über alle Konfigurationsparameter hinweg nach einem bestimmten Stichwort gesucht werden. Bei der Suche werden neben dem Namen des

Konfigurationsparameters auch die Beschreibungen ausgewertet, eine Einstellung kann also auch gefunden werden, wenn ihr Name nicht bekannt ist.

Weiterhin wurden die verschiedenen Konfigurationsparameter in Haupt- und Untergruppen unterteilt. Die Hauptgruppe stellt die Applikation dar, für die der Konfigurationsparameter zuständig ist, also z. B. "Framework" für das OTRS-Framework oder "Ticket" für das

Ticketsystem. Die Untergruppen einer Hauptgruppe können eingesehen werden, indem die Gruppe bzw. Applikation aus der dazu vorgesehenen Listbox ausgewählt und der "Zeigen"-Knopf gedrückt wird.

Für jeden einzelnen Konfigurationsparameter kann über eine Checkbox festgelegt werden, ob er vom System beachtet werden soll oder nicht. Wird eine Einstellung verändert, kann die Änderung mit Hilfe des "Aktualisieren"-Buttons übernommen werden. Eine Einstellung kann mit Hilfe des "Rücksetzen"-Schalters auf ihren Default-Wert zurückgesetzt werden.

Für die Sicherung aller von Ihnen vorgenommenen Änderungen, kann eine .pm-Datei heruntergeladen werden, die alle vom Standard abweichenden Konfigurationsparameter

Ihres Systems enthält. Dieselbe Datei können Sie ebenfalls über die Konfigurationsoberfläche eines frisch installierten Systems zurück spielen und so alle Einstellungen wiederherstellen.

Anmerkung

Die Einstellungen für die Datenbankanbindung können aus Sicherheitsgründen nicht über das grafische Konfigurations-Frontend geändert werden und müssen manuell in die Datei Kernel/Config.pm eingefügt werden.

3. Datensicherung

In diesem Kapitel wird beschrieben, wie alle relevanten Daten der OTRS-Installation gesichert und wieder hergestellt werden können.

3.1. Datensicherung

Bei einem Backup gibt es zwei Arten von Datensicherung, die Applikation (z. B. /opt/ otrs/ ) und die Datenbank.

Um Backups zu vereinfachen, wird ein scripts/backup.pl mitgeliefert, das alle benötigten Komponenten sichert.

linux:/opt/otrs# cd scripts/ linux:/opt/otrs/scripts# ./backup.pl --help backup.pl <Revision 1.1> - backup script

Skript: Aufruf der Hilfe des Backup-Mechanismus.

Ein Backup kann also z. B. mit folgendem Befehl erstellt werden: linux:/opt/otrs/scripts# ./backup.pl -d /backup/

Backup /backup//2010-09-07_14-28/Config.tar.gz ... done

Backup /backup//2010-09-07_14-28/Application.tar.gz ... done

Dump MySQL rdbms ... done

Compress SQL-file... done linux:/opt/otrs/scripts#

Abb.: Erstellen einer Datensicherung.

Alle Daten wurden in das Verzeichnis /backup/2010-09-12_14-28/ gesichert und dort, getrennt nach Art der Daten, in einzelne .tar.gz-Dateien gespeichert.

linux:/opt/otrs/scripts# ls /backup/2010-09-07_14-28/

Application.tar.gz Config.tar.gz DatabaseBackup.sql.gz

linux:/opt/otrs/scripts#

Skript: Prüfung der gesicherten Dateien.

3.2. Wiederherstellung der Daten

Um ein Backup wieder einzuspielen, müssen die Applikation (z. B. nach /opt/otrs/) und die Datenbank wieder hergestellt werden.

Um Backups einspielen zu können, wird ein scripts/restore.pl mitgeliefert, das die benötigten Komponenten wieder zurück sichert. Es unterstützt MySQL und PostgreSQL.

linux:/opt/otrs/scripts# ./restore.pl --help restore.pl <Revision 1.1> - restore script

Skript: Aufruf der Hilfe des Restore-Mechanismus.

Daten, die im Verzeichnis /backup/2010-09-12_14-28/ gesichert wurden, können bei einer OTRS-Installation in /opt/otrs folgendermaßen zurückgespielt werden.

linux:/opt/otrs/scripts# ./restore.pl -b /backup/2010-09-07_14-28 -d /opt/otrs/

Restore /backup/2010-09-07_14-28//Config.tar.gz ...

Restore /backup/2010-09-07_14-28//Application.tar.gz ...

create MySQL decompresses SQL-file ...

cat SQL-file into MySQL database compress SQL-file...

linux:/opt/otrs/scripts#

Skript: Wiederherstellung des Systems.

4. Email-Einstellungen

4.1. E-Mails versenden/empfangen

4.1.1. E-Mails versenden

4.1.1.1. Via Sendmail (Standard)

OTRS ist in der Lage, E-Mails via Sendmail (z. B. Sendmail , Postfix , Qmail oder Exim ) zu versenden. Die Standard-Konfiguration sollte gleich ohne Probleme funktionieren.

Die Konfiguration kann über die

grafische Administrationsoberfläche

(Framework::Core::Sendmail) vorgenommen werden

4.1.1.2. Via SMTP server/smarthost

Wenn kein sendmail-Binary zur Verfügung steht, kann OTRS E-Mails via SMTP ( Simple

Mail Transfer Protocol / RFC 821 ) oder Secure SMTP versenden. Diese Möglichkeit kann hauptsächlich auf Nicht-Unix-Plattformen (z. B. Win32) genutzt werden.

Die SMTP-Einstellungen können über die SysConfig vorgenommen werden

(Framework::Core::Sendmail). Wenn SMTPS nicht als Option auftaucht, fehlen benötigte

Perl-Module. Lesen Sie in diesem Fall im Abschnitt "Installation benötigter Perl-Module"

nach.

4.1.2. E-Mails empfangen

4.1.2.1. E-Mail-Konten, die über die OTRS-Oberfläche konfiguriert werden

OTRS ist in der Lage, E-Mails von POP3, POP3S, IMAP und IMAPS E-Mail-Konten zu empfangen.

Konfigurieren Sie Ihre Mail-Konten im Admin-Bereich von OTRS im Bereich "PostMaster

Mail Account".

If a new mail account is to be created (see Figure below), then its mail server name, login name and password must be specified. Also, you need to select the mail server type, which can be POP3, POP3S, IMAP or IMAPS. If you don't see your server type available

as an option, the required Perl modules are missing on your system. In that case, please

refer to "Installation of Perl modules required for OTRS" for instructions.

Abb 7.1. Einen E-Mail-Account hinzufügen.

Wählen Sie für "Vertraut" den Wert "Ja" aus, dann werden die sog. X-OTRS-Header-Einträge ausgewertet und angewendet, sofern derartige Header-Einträge in einer abgerufenen Nachricht vorhanden sind. Da mit Hilfe der X-OTRS-Header einige Dinge am System beeinflusst werden können, sollten Sie "Vertraut" nur auf "Ja" setzen, wenn Sie genau wissen, von welchen Absendern die abgerufenen Nachrichten stammen. X-OTRS-Header

werden vom Modul für die Nachrichtenfilterung in OTRS benutzt, die X-OTRS-Header wer-

den in dieser Tabelle näher beschrieben.Eventuell eingerichtete Filterregeln werden auf

jeden Fall abgearbietet, egal welcher Wert für "Vertraut" ausgewählt wurde.

The distribution of incoming messages can be controlled if they need to be sorted by queue or by the content of the "To:" field. For the Dispatching field, if "Dispatching by selected queue" is selected, all incoming messages will be sorted into the specified queue.

The address where the mail was sent to is disregarded in this case. If "Dispatching by email To: field" is selected, the system checks if a queue is linked with the address in the

To: field of the incoming mail. You can link an address to a queue in the E-mail address management section of the Admin page. If the address in the To: field is linked with a

queue, the new message will be sorted into the linked queue. If no link is found between the address in the To: field and any queue, then the message flows into the "Raw" queue

in the system, which is the PostmasterDefaultQueue after a default installation.

Die Daten zu allen Mail-Konten werden in der Datenbank von OTRS gespeichert. Das Skript otrs.PostMasterMailbox.pl

, welches sich im Verzeichnis bin innerhalb des OTRS-

Homeverzeichnisses befindet, fragt die Einstellungen ab und holt die Mails von den einzelnen Mail-Konten. Sie können dieses Skript manuell ausführen, um zu prüfen, ob alle E-

Mail-Einstellungen korrekt funktionieren.

Auf einer Standardinstallation holt der Cron-Job postmaster_mailbox die E-Mails alle 10

Minuten ab. Das Kapitel "Einrichten der von OTRS benötigten cron-Jobs" beschreibt das

Zusammenspiel zwischen OTRS und cron ausführlicher.

Anmerkung

Beim Abholen löscht OTRS die E-Mails vom POP oder IMAP server. Es besteht keine

Möglichkeit, die Mails dort zu erhalten. Wenn Sie dies wünschen, erstellen Sie am

Besten Weiterleitungsregeln auf Ihrem Mail-Server. Lesen Sie hierzu bitte in der

Dokumentation ihres Mail-Servers nach.

4.1.2.2. Via Kommandozeilen-Programm und z. B. procmail

(otrs.PostMaster.pl)

OTRS ist in der Lage, E-Mails über ein Kommandozeilen-Programm (bin/ otrs.PostMaster.pl

) zu empfangen. Es nimmt die Mails über STDIN entgegen und fügt sie direkt in das OTRS-System ein. Das bedeutet, dass E-Mails im OTRS angezeigt werden, wenn der MDA (mail delivery agent, z. B. procmail) die E-Mails an bin/ otrs.PostMaster.pl

" weiterleitet.

Um bin/otrs.PostMaster.pl ohne MDA zu testen, führen Sie die Kommandos in Skript: aus.

linux:/opt/otrs# cd bin linux:/opt/otrs/bin# cat ../doc/sample_mails/test-email-1.box | ./otrs.PostMaster.pl

linux:/opt/otrs/bin#

Skript: PostMaster-Test ohne MDA.

Wird die E-Mail in der Queue-Ansicht angezeigt, sind Ihre Einstellungen in Ordnung.

Procmail ist in der Linux-Umgebung ein sehr bekannter E-Mail-Filter, der höchstwahrscheinlich auf Ihrem System installiert sein wird. Falls nicht, erhalten Sie auf der

procmail

Homepage

weitere Informationen.

Um procmail einzurichten (benötigt einen für procmail konfigurierten MDA (z. B. sendmail, postfix, exim oder qmail)), kann die Datei.procmailrc.dist aus dem OTRS-Homeverzeichnis verwendet werden. Kopieren Sie .procmailrc.dist nach .procmailrc und nehmen Sie die in Skript: dargestellten Änderungen vor.

SYS_HOME=$HOME

PATH=/bin:/usr/bin:/usr/local/bin

# --

# Pipe all email into the PostMaster process.

# --

:0 :

| $SYS_HOME/bin/otrs.PostMaster.pl

Skript: Konfiguration von procmail für OTRS.

Alle an den lokalen OTRS-Benutzer gesendeten E-Mails werden an bin/ otrs.PostMaster.pl

weitergeleitet und dadurch im Ticket-System gespeichert.

4.1.2.3. E-Mails via POP3 oder IMAP und fetchmail für otrs.PostMaster.pl empfangen

Um E-Mails von Ihrem Mailserver via POP3 oder IMAP für den OTRS-Rechner/lokalen OTRS-

Benutzer und procmail abzuholen, benutzen Sie fetchmail .

Anmerkung

Voraussetzung ist eine funktionierende SMTP-Konfiguration auf dem OTRS-Rechner.

Eine Beispielkonfiguration finden Sie in der Datei .fetchmailrc.dist im Homeverzeichnis von OTRS. Kopieren Sie diese Datei nach .fetchmailrc und erweitern Sie die Datei um die Daten Ihrer E-Mail-Accounts (siehe Beispiel 7-1).

Beispiel 4.2. .fetchmailrc

#poll (mailserver) protocol POP3 user (user) password (password) is (localuser)

poll mail.example.com protocol POP3 user joe password mama is otrs

Vergessen Sie nicht, die Zugriffsrechte von .fetchmailrc auf 710 zu setzen.

Wird das Kommando "fetchmail -a mit dieser Konfiguration ausgeführt, werden alle E-

Mails auf das lokale OTRS-Konto weitergeleitet. Richten Sie ggf. einen Cronjob ein, wenn die E-Mails regelmäßig geholt werden sollen.

4.1.2.4. Filterung/Verteilung über PostMaster-Module (für komplexere Verteilungsszenarien)

Falls die bin/otrs.PostMaster.pl oder bin/otrs.PostMasterMailbox.pl Methoden verwendet werden, können X-OTRS-Header mit Hilfe der PostMaster-Filtermodule in die eingehenden Mails eingefügt bzw. bereits vorhandene X-OTRS-Header verändert werden.

Mit Hilfe von X-OTRS-Headern kann das Ticket System bestimmte Aktionen für Mails ausführen, z. B. diese in eine bestimmte Queue einsortieren, sie einem bestimmten Kunden zuordnen, die Priorität ändern usw. Eine nähere Beschreibung der X-OTRS-Header finden

Sie im Kapitel zum Einrichten von Mail-Accounts über den Administrations-Bereich von

OTRS.

Es gibt verschiedene Standard-Filtermodule:

Anmerkung

Der Jobname (z. B. $Self->{"PostMaster::PreFilterModule"}->{"Jobname"}) muss eindeutig sein!

Kernel::System::PostMaster::Filter::Match ist ein Standard-Modul, um einige E-Mail-Header (z. B. From, To, Subject) zu prüfen und dann den neuen E-Mail-Header zu setzen (z.

B. X-OTRS-Ignore: yes oder X-OTRS-Queue: spam).

Beispiel 4.3. Beispiel-Jobs für

Kernel::System::PostMaster::Filter::Match das Filtermodul

# Job Name: 1-Match

# (block/ignore all spam email with From: noreply@)

$Self->{'PostMaster::PreFilterModule'}->{'1-Match'} = {

Module => 'Kernel::System::PostMaster::Filter::Match',

Match => {

From => 'noreply@',

Set => {

'X-OTRS-Ignore' => 'yes',

};

# Job Name: 2-Match

# (sort emails with From: [email protected] and Subject: **ORDER**

# into queue 'Order')

$Self->{'PostMaster::PreFilterModule'}->{'2-Match'} = {

Module => 'Kernel::System::PostMaster::Filter::Match',

Match => {

To => '[email protected]',

Subject => '**ORDER**',

Set => {

'X-OTRS-Queue' => 'Order',

};

Kernel::System::PostMaster::Filter::CMD ist ein Standard-Modul, um die E-Mails an ein externes Kommando zu leiten. Dessen Ergebniss wird an STOUT ausgegeben und, falls das Ergebnis aus STDOUT true ist, wird ein neuer E-Mail-Header gesetzt (z. B. X-OTRS-

Ignore: yes oder X-OTRS-Queue: spam).

Beispiel 4.4. Beispiel-Job für

Kernel::System::PostMaster::Filter::CMD das Filtermodul

# Job Name: 5-SpamAssassin

# (SpamAssassin example setup, ignore spam emails)

$Self->{'PostMaster::PreFilterModule'}->{'5-SpamAssassin'} = {

Module => 'Kernel::System::PostMaster::Filter::CMD',

CMD => '/usr/bin/spamassassin | grep -i "X-Spam-Status: yes"',

Set => {

'X-OTRS-Ignore' => 'yes',

};

Kernel::System::PostMaster::Filter::ExternalTicketNumberRecognition is a default module that adds the possibility to parse external identifiers, in the email subject, the body or both using regular expressions. It then stores this value in a defined dynamic field. When an email comes in, OTRS will first search for an external identifier and when it finds one, query OTRS on the pre-defined dynamic field field. If it finds an existing ticket, it will update this ticket, otherwise it will create a new ticket with the external reference number in the separate field.

OTRS SysConfig already provide 4 different settings to setup different external ticket numbers. If more settings are needed they need to need to be added manually. The following example can be used in Kernel/Config.pm to extend SysConfig settings.

Beispiel 4.5. Example job for the filter module

Kernel::System::PostMaster::Filter::ExternalTicketNumberRecognition

# Job Name: ExternalNumber

# External Ticket Number Reconition, check for Incident-<number> in incoming mails

subject and

# body from the addeesses <sender>@externalticket.com, if number is found it will be

stored in

# the dynamic field 'ExternalNumber' (that need to be setup in the Admin Panel).

$Self->{'PostMaster::PreFilterModule'}->{'000-ExternalTicketNumberRecognition5'} = {

'FromAddressRegExp' => '\\s*@externalticket.com',

'NumberRegExp' => 'Incident-(\\d.*)',

'SearchInSubject' => '1',

'SearchInBody' => '1',

'TicketStateTypes' => 'new;open'

'DynamicFieldName' => 'ExternalNumber',

'Module' =>

'Kernel::System::PostMaster::Filter::ExternalTicketNumberRecognition',

'Name' => 'Test External Ticket Number',

'SenderType' => 'system',

};

Konfigurationsoptionen

• FromAddressRegExp

This is an optional setting. Only mails matching this "From:" address will be considered for this filter. You can adjust this setting to the sender address your external system uses for outgoing mails. In case this address can differ, you can set this option to empty.

OTRS will in that case not check the sender address.

• NumberRegExp

This is a mandatory setting. This setting contains the regular expression OTRS will use to extract the ticket number out of the subject and/or ticket body. The default regular expression will match occurrences of for example 'Incident-12354' and will put the part between parentheses in the dynamic field field, in this case '12354'.

• SearchInSubject

Wenn diese Variable auf '1' gesetzt ist, wird der E-Mailbetreff nach einer Ticketnummer durchsucht.

• SearchInBody

Wenn diese Variable auf '1' gesetzt ist, wird der E-Mailbody nach einer Ticketnummer durchsucht.

• TicketStateTypes

This is an optional setting. If given, it will search OTRS only for open external tickets of given state types. The state types are separated with semicolons.

• DynamicField

This is a required setting. It defines the dynamic filed that is used to store the external number (the field name must exist in the system and has to be valid).

• SenderType

This defines the sender type used for the articles created in OTRS.

Natürlich ist es auch möglich, eigene PostMaster-Filtermodule zu entwickeln.

4.2. Sichere E-Mail mit PGP

OTRS has the capability to sign or encrypt outgoing messages with PGP. Furthermore, encrypted incoming messages can be decrypted. Encryption and decryption are done with the GPL tool GnuPG. To setup GnuPG for OTRS, the following steps have to be performed:

1. Erste Aufgabe ist es, das entsprechende GnuPG-Software-Paket zu installieren, welches bei den meisten Linux-Distributionen mitgeliefert wird. Dies sollte mit Hilfe des jeweiligen Paketmanagers leicht durchgeführt werden können.

2. Im zweiten Schritt muss das soeben installierte GnuPG zur Benutzung für OTRS konfiguriert werden. Dies geschieht auf der Kommandozeilenebene durch einen Aufruf von

GnuPG, der die notwendigen Verzeichnisse anlegt und den privaten Schlüssel erzeugt.

Der Aufruf muss als Benutzer 'otrs' durchgeführt werden.

linux:~# su otrs

linux:/root$ cd

linux:~$ pwd

/opt/otrs

linux:~$ gpg --gen-key

This program comes with ABSOLUTELY NO WARRANTY.

This is free software, and you are welcome to redistribute it

under certain conditions. See the file COPYING for details.

gpg: directory `/opt/otrs/.gnupg' created

gpg: new configuration file `/opt/otrs/.gnupg/gpg.conf' created

gpg: WARNING: options in `/opt/otrs/.gnupg/gpg.conf' are not yet active during t

his run

gpg: keyring `/opt/otrs/.gnupg/secring.gpg' created

gpg: keyring `/opt/otrs/.gnupg/pubring.gpg' created

Please select what kind of key you want:

(1) DSA and Elgamal (default)

(2) DSA (sign only)

(5) RSA (sign only)

Your selection? 1

DSA keypair will have 1024 bits.

ELG-E keys may be between 1024 and 4096 bits long.

What keysize do you want? (2048)

Requested keysize is 2048 bits

Please specify how long the key should be valid.

0 = key does not expire

<n> = key expires in n days

<n>w = key expires in n weeks

<n>m = key expires in n months

<n>y = key expires in n years

Key is valid for? (0)

Key does not expire at all

Is this correct? (y/N) y

You need a user ID to identify your key; the software constructs the user ID

from the Real Name, Comment and Email Address in this form:

"Heinrich Heine (Der Dichter) <[email protected]>"

Real name: Ticket System

Email address: [email protected]

Comment: Private PGP Key for the ticket system with address [email protected]

You selected this USER-ID:

"Ticket System (Private PGP Key for the ticket system with address support@examp

le.com) <[email protected]>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O

You need a Passphrase to protect your secret key.

Passphrase: secret

Repeat passphrase: secret

We need to generate a lot of random bytes. It is a good idea to perform

some other action (type on the keyboard, move the mouse, utilize the

disks) during the prime generation; this gives the random number

generator a better chance to gain enough entropy.

++++++++++.+++++++++++++++++++++++++....+++++.+++++...+++++++++++++++++++++++++.

+++++++++++++++++++++++++.+++++.+++++.+++++++++++++++++++++++++>++++++++++>+++++

.......>+++++<+++++................................+++++

Not enough random bytes available. Please do some other work to give

the OS a chance to collect more entropy! (Need 280 more bytes)

++++++++++.+++++..++++++++++..+++++....++++++++++++++++++++.+++++++++++++++.++++

++++++++++++++++++++++++++.++++++++++.+++++++++++++++.++++++++++.+++++++++++++++

..+++++>.+++++....>+++++........................................................

...........................................................>+++++<+++++.........

.............+++++^^^

gpg: /opt/otrs/.gnupg/trustdb.gpg: trustdb created

gpg: key 7245A970 marked as ultimately trusted

public and secret key created and signed.

gpg: checking the trustdb

gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model

gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u

pub 1024D/7245A970 2006-02-03

Key fingerprint = 2ED5 BC36 D2B6 B055 7EE1 5833 1D7B F967 7245 A970

uid Ticket System (Private pgp key for ticket system with addre

ss [email protected]) <[email protected]>

sub 2048g/52B97069 2006-02-03

linux:~$

Skript: Konfiguration von GnuPG.

Wie man sehen kann, genügt es bei den meisten Fragen die Vorgabe mit <EINGABE> zu bestätigen. Lediglich die Angabe zur Person des Schlüsselbesitzers ist zu vervollständigen bzw. zum Ende hin ist an der mit (passphrase) gekennzeichneten Stelle die

Passphrase für den zu generierenden Schlüssel einzugeben.

3. In the screen for the PGP settings, PGP should be activated for OTRS (first option). Also,

the path to the gpg program should be set and checked.

100

Die nächste Einstellung (PGP::Options) muss ggf. modifiziert werden. Es handelt sich

um die Parameter, mit denen OTRS das Programm gpg aufruft. Hier ist insbesondere die Option für die Lage des GnuPG-Konfigurationsverzeichnisses des OTRS-Benutzers otrs wichtig. Im Beispiel ist dies: /opt/otrs/.gnupg). Dieses Verzeichnis wurde im Schritt

1 automatisch von GnuPG angelegt.

Über die letzte Option können die Schlüssel-Werte-Paare für die ID(s) und Passphrase(n)

der eigenen PGP-Schlüssel dem Ticket System bekannt gemacht werden. Noch einmal genauer: da andere Kommunikationspartner an das Ticket-System (oder besser: an den

Mail-Eingang des Systems) E-Mails mit dessen öffentlichen Schlüssel verschlüsselt schicken, kann OTRSmit dem/n in dieser Option angegebenen privaten Schlüssel(n) solchermaßen verschlüsselte Mails entschlüsseln.

Woher bekommt man die ID des eigenen Schlüssels? Die ID steckt schon in der Ausgabe der Schlüsselgenerierung (siehe Schritt 1). Man kann die ID aber auch als Benutzer

'otrs' jederzeit über die Kommandozeile ermitteln:

linux:~# su otrs

linux:/root$ cd

linux:~$ pwd

/opt/otrs

linux:~$ gpg --list-keys

/opt/otrs/.gnupg/pubring.gpg

----------------------------

pub 1024D/7245A970 2006-02-03

uid Ticket System (Private pgp key for ticket system with

address [email protected]) <[email protected]>

sub 2048g/52B97069 2006-02-03

linux:~$

Skript: Die ID des eigenen privaten Schlüssels ermitteln.

Die ID des Schlüssels befindet sich in der Zeile, die mit sub beginnt und ist eine 8stellige hexadezimale Kennung (im Beispiel lautet sie "52B97069". Die für die Option geforderte Passphrase ist dieselbe, die beim Schlüsselgenerieren in Schritt 1 verwendet wurde.

Nach Eingabe all dieser Angaben können sie mit dem Aktualisieren-Button gespeichert werden. OTRS ist jetzt für das Empfangen mit PGP verschlüsselter E-Mails konfiguriert.

4. Der letzte Schritt ist der Import des öffentlichen PGP-Schlüssels eines Kunden. Dadurch wird sicher gestellt, dass aus OTRS heraus verschlüsselte Mails an den jeweiligen Kunden gesendet werden können. Es bestehen zwei Möglichkeiten für den Import.

Zum einem können über das Modul zur Verwaltung der Kunden die öffentlichen PGP-

Schlüssel beim Anlegen/Bearbeiten des jeweiligen Kunden im System hinterlegt werden.

Die zweite Möglichkeit bietet das System in den PGP-Einstellungen innerhalb des

Admin-Bereiches. In dieser Konfigurationsmaske ist im rechten Teil eine Liste der bereits dem System zur Verfügung stehenden öffentlichen Schlüssel zu sehen. Im Regelfall sollte nach der obigen Einrichtung hier schon der öffentliche Schlüssel des Ticket-Systems selbst zu sehen sein. Im linken Teil besteht neben der Suche die Möglichkeit, neue

Schlüssel als Schlüsseldatei ins System zu laden.

Sowohl für das Hinzufügen eines Schlüssels über die Kunden- als auch über die PGP-

Verwaltung gilt, dass die Dateien mit den Schlüsseln PGP/GnuPG-konforme Schlüssel sein müssen. Normalerweise wird der Schlüssel als "ASCII armored key"-Datei vorliegen, welches problemlos von OTRS verarbeitet werden kann.

101

4.3. Sichere E-Mail mit S/MIME

At first glance, encryption with S/MIME seems a little more complicated than with PGP.

First, you have to establish a Certification Authority (CA) for the OTRS system. The subsequent steps are very much like those needed with PGP: configure OTRS, install your own certificate, import other public certificates as needed, etc.

Die S/MIME-Konfiguration geschieht zu einem großen Teil außerhalb der OTRS-Web-Oberfläche und sollte als otrs-Benutzer (bzw. als der Benutzer mit dessen Rechten OTRS läuft) in einer Shell durchgeführt werden. Da die MIME-Konfiguration unter Linux im wesentlichen auf SSL (openssl basiert, sollte zuerst sichergestellt werden, dass das openssl-Paket installiert ist. Mit dem openssl-Paket kommt ein Skript, CA.pl, mit welchem die wichtigsten Schritte zur Zertifikatserstellung bewältigt werden können. Damit dieser Vorgang einfacher wird, sollte zuerst herausgefunden werden, wo sich das Skript CA.pl im Dateisystem befindet. Danach sollte diese Stelle der Einfachheit halber temporär in den Suchpfad der Shell übernommen werden.

otrs@linux:~> rpm -ql openssl | grep CA

/usr/share/ssl/misc/CA.pl

otrs@linux:~> export PATH=$PATH:/usr/share/ssl/misc otrs@linux:~> which CA.pl

/usr/share/ssl/misc/CA.pl

otrs@linux:~> mkdir tmp; cd tmp otrs@linux:~/tmp>

Skript: Konfiguration von S/MIME.

Im Beispiel sieht man auch, dass ein temporäres Verzeichnis ~/tmp angelegt wurde, in welchem die Zertifikatsgenerierung durchgeführt wird.

Im einzelnen sind zur Zertifikatserzeugung folgende Schritte durchzuführen, die einzelnen Schritte sind in der Kommandozeile auszuführen. Sollte ein beglaubigtes SSL-Zertifikat für die Verschlüsselung bereits vorhanden sein, so sollte natürlich dieses verwendet werden. Dann können die nun folgenden Schritte übersprungen werden. Der beschriebene Ablauf geht davon aus, dass der OTRS-Administrator sich das SSL-Zertifikat zu Testund Lernzwecken selbst anlegen muss.

1. Anlegen einer eigenen Certification Authority für SSL. Diese wird benötigt, um die Anfrage für ein eigenes SSL-Zertifikat zu beglaubigen.

otrs@linux:~/tmp> CA.pl -newca

CA certificate filename (or enter to create)

Making CA certificate ...

Generating a 1024 bit RSA private key

...++++++

......++++++ writing new private key to './demoCA/private/cakey.pem'

Enter PEM pass phrase:

Verifying - Enter PEM pass phrase:

-----

You are about to be asked to enter information that will be incorporated into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [AU]:DE

State or Province Name (full name) [Some-State]:OTRS-state

Locality Name (eg, city) []:OTRS-town

Organization Name (eg, company) [Internet Widgits Pty Ltd]:Your company

Organizational Unit Name (eg, section) []:

102

Common Name (eg, YOUR name) []:OTRS Admin

Email Address []:[email protected]

otrs@linux:~/tmp> ls -la demoCA/ total 8

-rw-r--r-- 1 otrs otrs 1330 2006-01-08 17:54 cacert.pem

drwxr-xr-x 2 otrs otrs 48 2006-01-08 17:53 certs drwxr-xr-x 2 otrs otrs 48 2006-01-08 17:53 crl

-rw-r--r-- 1 otrs otrs 0 2006-01-08 17:53 index.txt

drwxr-xr-x 2 otrs otrs 48 2006-01-08 17:53 newcerts drwxr-xr-x 2 otrs otrs 80 2006-01-08 17:54 private

-rw-r--r-- 1 otrs otrs 17 2006-01-08 17:54 serial otrs@linux:~/tmp>

Skript: Anlegen einer Certification Authority für SSL.

2. Erzeugen der Zertifikatsanfrage.

otrs@linux:~/tmp> CA.pl -newreq

Generating a 1024 bit RSA private key

..........................................++++++

....++++++ writing new private key to 'newreq.pem'

Enter PEM pass phrase:

Verifying - Enter PEM pass phrase:

-----

You are about to be asked to enter information that will be incorporated into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [AU]:DE\keyreturn

State or Province Name (full name) [Some-State]:OTRS-state

Locality Name (eg, city) []:OTRS-town

Organization Name (eg, company) [Internet Widgits Pty Ltd]:Your company

Organizational Unit Name (eg, section) []:

Common Name (eg, YOUR name) []:OTRS admin

Email Address []:[email protected]

Please enter the following 'extra' attributes to be sent with your certificate request

A challenge password []:

An optional company name []:

Request (and private key) is in newreq.pem

otrs@linux:~/tmp> ls -la total 4 drwxr-xr-x 6 otrs otrs 232 2006-01-08 17:54 demoCA

-rw-r--r-- 1 otrs otrs 1708 2006-01-08 18:04 newreq.pem

otrs@linux:~/tmp>

Skript: Erstellen einer Zertifikatsanfrage.

3. Die Zertifikatsanfrage durch die CA signieren lassen. Die Zertifikatsanfrage kann entweder durch die selbst angelegte CA signiert (= beglaubigt) werden. Allerdings ist es natürlich seriöser, wenn das eigene SSL-Zertifikat von einer fremden, externen und ihrerseits beglaubigten CA beglaubigt wird.

otrs@linux:~/tmp> CA.pl -signreq

Using configuration from /etc/ssl/openssl.cnf

Enter pass phrase for ./demoCA/private/cakey.pem:

Check that the request matches the signature

Signature ok

Certificate Details:

Serial Number:

fd:85:f6:9f:14:07:16:c8

103

Validity

Not Before: Jan 8 17:04:37 2006 GMT

Not After : Jan 8 17:04:37 2007 GMT

Subject:

countryName = DE

stateOrProvinceName = OTRS-state

localityName = OTRS-town

organizationName = Your Company

commonName = OTRS administrator

emailAddress = [email protected]

X509v3 extensions:

X509v3 Basic Constraints:

CA:FALSE

Netscape Comment:

OpenSSL Generated Certificate

X509v3 Subject Key Identifier:

01:D9:1E:58:C0:6D:BF:27:ED:37:34:14:D6:04:AC:C4:64:98:7A:22

X509v3 Authority Key Identifier:

keyid:10:4D:8D:4C:93:FD:2C:AA:9A:B3:26:80:6B:F5:D5:31:E2:8E:DB:A8

DirName:/C=DE/ST=OTRS-state/L=OTRS-town/O=Your Company/

CN=OTRS admin/[email protected]

serial:FD:85:F6:9F:14:07:16:C7

Certificate is to be certified until Jan 8 17:04:37 2007 GMT (365 days)

Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y

Write out database with 1 new entries

Data Base Updated

Signed certificate is in newcert.pem

otrs@linux:~/tmp>

Skript: Signieren der Zertifikatsanfrage.

4. Mit der signierten Zertifikatsanfrage das eigene Zertifikat und alle dazugehörigen

Dateien erzeugen.

otrs@linux:~/tmp> CA.pl -pkcs12 "OTRS Certificate"

Enter pass phrase for newreq.pem:

Enter Export Password:

Verifying - Enter Export Password: otrs@linux:~/tmp> ls -la total 12 drwxr-xr-x 6 otrs otrs 328 2006-01-08 18:04 demoCA

-rw-r--r-- 1 otrs otrs 3090 2006-01-08 18:13 newcert.p12

-rw-r--r-- 1 otrs otrs 3791 2006-01-08 18:04 newcert.pem

-rw-r--r-- 1 otrs otrs 1708 2006-01-08 18:04 newreq.pem

otrs@linux:~/tmp>

Skript: Neues Zertifikat erstellen.

Nach der Durchführung dieser Schritte ist es notwendig die Einrichtung von S/MIME in

OTRS abzuschließen.

Die OTRS-seitige Einrichtung erfolgt aus dem Admin-Bereich, Block System über den

Punkt SMIME. Falls die generelle S/MIME-Unterstützung in OTRS noch nicht aktiviert wur-

de, weist die Maske den OTRS-Administrator beim Aufruf darauf hin und bietet einen bequemen Link zur Einrichtung.

With the SysConfig group "Crypt::SMIME", you can also enable and configure the general

S/MIME support.

Hier können sie S/MIME-Unterstützung aktivieren, und die Pfade zum OpenSSL-Kommando und zu den Zertifikaten angeben. Die vorhin erzeugte Schlüsseldatei muss in diesem

Verzeichnis gespeichert werden, sonst kann OpenSSL sie nicht verwenden.

104

Im nächsten Schritt geht es (zurück) zur S/MIME-Konfiguration im Administrationsbereich.

Dort können nun sowohl der private Schlüssel(Key) bzw. die privaten Schlüssel des OTRS-

Systems, als auch die öffentlichen Schlüssel anderer Kommunikationspartner ins System importiert werden. Tragen Sie hier den öffentlichen Schlüssel ein, der zu Beginn dieses

Abschnitts erzeugt und dann in OTRS hinzugefügt wurde.

Selbstverständlich können aber auch alle öffentlichen S/MIME-Schlüssel der Kommunika-

tionspartner über das Modul zur Kundenverwaltung beim Anlegen/Bearbeiten des jewei-

ligen Kunden in das System importiert werden.

5. Einbinden externer Backends

5.1. Kundenbenutzerdaten

OTRS ist in der Lage, mit verschiedenen Kundendaten (insbesondere Login, E-Mail, Telefon) umzugehen. Diese Informationen können im Agenten-Interface angezeigt und für das Kunden-Interface verwendet werden. Weiterhin werden die Daten für die Authentifizierung der Kunden am System benötigt.

Die benutzten/angezeigten Kundendaten sind frei konfigurierbar, es gibt jedoch folgende benötigte Optionen die unbedingt vorhanden sein müssen, damit OTRS ordnungsgemäß funktioniert:

• Benutzer-Login

• E-Mail-Adresse

• Benutzer-Kunden-ID

Verwenden Sie die folgenden SysConfig-Parameter, wenn Sie die Kundeninformationen im Agenten-Interface angezeigen wollen.

# Ticket::Frontend::CustomerInfo*

# (show customer info on Compose (Phone and Email), Zoom and

# Queue view)

$Self->{'Ticket::Frontend::CustomerInfoCompose'} = 1;

$Self->{'Ticket::Frontend::CustomerInfoZoom'} = 1;

Skript: SysConfig Konfigurationsparameter.

5.2. Kundenbenutzer Backend

Es existieren zwei Kundenbenutzer Back-ends, DB und LDAP. Falls Sie bereits ein Kundenverzeichnis (z. B. SAP, ...) haben, ist es natürlich möglich, dafür ein eigenes Back-end zu schreiben.

5.2.1. Datenbank (Standard)

Beispiel 11-1 zeigt die Konfiguration eines Kundenbenutzer-Backends, welches die Kundendaten in der OTRS-Datenbank speichert.

Beispiel 4.6. Konfiguration eines Datenbank-Kunden-Backends

# CustomerUser (customer database backend and settings)

$Self->{CustomerUser} = {

Name => 'Database Datasource',

Module => 'Kernel::System::CustomerUser::DB',

Params => {

# if you want to use an external database, add the required settings

# DSN => 'DBI:odbc:yourdsn',

# Type => 'mssql', # only for ODBC connections

105

# DSN => 'DBI:mysql:database=customerdb;host=customerdbhost',

# User => '',

# Password => '',

Table => 'customer_user',

# if your frontend is unicode and the charset of your

# customer database server is iso-8859-1, use these options.

# SourceCharset => 'iso-8859-1',

# DestCharset => 'utf-8',

# CaseSensitive will control if the SQL statements need LOWER()

# function calls to work case insensitively. Setting this to

# 1 will improve performance dramatically on large databases.

CaseSensitive => 0,

# customer unique id

CustomerKey => 'login',

# customer #

CustomerID => 'customer_id',

CustomerValid => 'valid_id',

CustomerUserListFields => ['first_name', 'last_name', 'email'],

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

CustomerUserSearchPrefix => '',

CustomerUserSearchSuffix => '*',

CustomerUserSearchListLimit => 250,

CustomerUserPostMasterSearchFields => ['email'],

CustomerUserNameFields => ['title','first_name','last_name'],

CustomerUserEmailUniqCheck => 1,

# # show not own tickets in customer panel, CompanyTickets

# CustomerUserExcludePrimaryCustomerID => 0,

# # generate auto logins

# AutoLoginCreation => 0,

# AutoLoginCreationPrefix => 'auto',

# # admin can change customer preferences

# AdminSetPreferences => 1,

# # cache time to live in sec. - cache any database queries

# CacheTTL => 0,

# # just a read only source

# ReadOnly => 1,

Map => [

# note: Login, Email and CustomerID needed!

# var, frontend, storage, shown (1=always,2=lite), required, storage-type, httplink, readonly, http-link-target

[ 'UserTitle', 'Title', 'title', 1, 0, 'var', '', 0 ],

[ 'UserFirstname', 'Firstname', 'first_name', 1, 1, 'var', '', 0 ],

[ 'UserLastname', 'Lastname', 'last_name', 1, 1, 'var', '', 0 ],

[ 'UserLogin', 'Username', 'login', 1, 1, 'var', '', 0 ],

[ 'UserPassword', 'Password', 'pw', 0, 0, 'var', '', 0 ],

[ 'UserEmail', 'Email', 'email', 1, 1, 'var', '', 0 ],

# [ 'UserEmail', 'Email', 'email', 1, 1, 'var', '$Env{"CGIHandle"}?

Action=AgentTicketCompose&ResponseID=1&TicketID=$Data{"TicketID"}&ArticleID=

$Data{"ArticleID"}', 0 ],

[ 'UserCustomerID', 'CustomerID', 'customer_id', 0, 1, 'var', '', 0 ],

# [ 'UserCustomerIDs', 'CustomerIDs', 'customer_ids', 1, 0, 'var', '', 0 ],

[ 'UserPhone', 'Phone', 'phone', 1, 0, 'var', '', 0 ],

[ 'UserFax', 'Fax', 'fax', 1, 0, 'var', '', 0 ],

[ 'UserMobile', 'Mobile', 'mobile', 1, 0, 'var', '', 0 ],

[ 'UserStreet', 'Street', 'street', 1, 0, 'var', '', 0 ],

[ 'UserZip', 'Zip', 'zip', 1, 0, 'var', '', 0 ],

[ 'UserCity', 'City', 'city', 1, 0, 'var', '', 0 ],

[ 'UserCountry', 'Country', 'country', 1, 0, 'var', '', 0 ],

[ 'UserComment', 'Comment', 'comments', 1, 0, 'var', '', 0 ],

[ 'ValidID', 'Valid', 'valid_id', 0, 1, 'int', '', 0 ],

# default selections

Selections => {

UserTitle => {

'Mr.' => 'Mr.',

'Mrs.' => 'Mrs.',

106

};

Falls Sie die Kundendaten anpassen möchten, ändern Sie in der Datenbank die Tabellenspalten oder fügen Sie weitere hinzu (im folgenden Beispiel wird ein Feld für die Raumnummer hinzugefügt).

linux:~# mysql -p

Enter password:

Welcome to the MySQL monitor. Commands end with ; or \g.

Your MySQL connection id is 116 to server version: 5.0.18-Debian_7-log

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> use otrs;

Reading table information for completion of table and column names

You can turn off this feature to get a quicker startup with -A

Database changed mysql> ALTER TABLE customer_user ADD room VARCHAR (250);

Query OK, 1 rows affected (0.01 sec)

Records: 1 Duplicates: 0 Warnings: 0 mysql> quit

Bye linux:~#

Skript: Ein Feld zur Tabelle customer_user hinzufügen.

Danach fügen Sie Ihre eigenen Spalten dem MAP Array in der Datei Kernel/Config.pm

hinzu:

# var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link,

readonly

[...]

[ 'UserRoom', 'Room', 'room', 0, 1, 'var', '', 0 ],

Skript: Hinzufügen eines Feldes in Kernel/Config.pm file.

Es ist auch möglich, diese Kundeninformationen über den Kundenlink im Agent-Interface zu bearbeiten.

5.2.1.1. Kunden mit multiplen IDs (Firmen-Tickets)

Es ist möglich, einem Kunden mehr als nur eine Kundennummer zuzuweisen. Dies kann z. B. dann sinnvoll sein, wenn ein Kunde auf Tickets anderer Kunden zugreifen muss, z. B.

der Abteilungsleiter auf die Tickets der Mitarbeiter seiner Abteilung. Hat ein Kunde Zugriff auf Tickets anderer Kunden, verwendet man in OTRS das sog. Firmen Ticket Feature. Im

Kunden-Interface können diese Tickets über den "Firmen-Ticket" Link eingesehen werden.

Um Firmen-Tickets zu verwenden, muss die customer_user Tabelle in der OTRS Datenbank um eine Spalte erweitert werden, in die später die Kundennummern eingetragen werden, auf die ein Kunde zusätzlich zu den eigenen Tickets Zugriff haben soll.

linux:~# mysql -p

Enter password:

Welcome to the MySQL monitor. Commands end with ; or \g.

Your MySQL connection id is 124 to server version: 5.0.18-Debian_7-log

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> use otrs;

Reading table information for completion of table and column names

You can turn off this feature to get a quicker startup with -A

Database changed

107

mysql> ALTER TABLE customer_user ADD customer_ids VARCHAR (250);

Query OK, 1 rows affected (0.02 sec)

Records: 1 Duplicates: 0 Warnings: 0 mysql> quit

Bye linux:~#

Skript: Hinzufügen eines Feldes customer_ids zur Tabelle customer_user.

Danach fügen Sie die neue Spalte dem MAP Array in der Datei Kernel/Config.pm hinzu.

# var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link,

readonly

[...]

[ 'UserCustomerIDs', 'CustomerIDs', 'customer_ids', 1, 0, 'var', '', 0 ],

Skript: Hinzufügen des Feldes UserCustomerIDs zu Kernel/Config.pm.

Die Spalte für die Multi-Kundennummern kann ab nun über das Admin-Interface bzw. über die Kundenverwaltung gepflegt werden.

Um nun den Zugriff für einen Kunden auf die Tickets anderer Kunden zu ermöglichen, tragen Sie in die neue Spalte die IDs der Kunden ein, auf deren Tickets der Zugriff ermöglicht werden soll. Die einzelnen IDs trennen Sie durch ein Semikolon.

Beispiel 4.7. Firmen-Tickets mit einem Datenbank-Backend

Angenommen es sind die Kunden A, B und C im System angelegt. A soll mit Hilfe von

Firmen Tickets über das Kunden-Interface Zugriff auf die Tickets von B und C haben, B und C sollen jedoch jeweils nur ihre eigenen Tickets einsehen und bearbeiten können.

Um dieses Setup zu realisieren, ändern Sie wie oben beschrieben die customer_user Tabelle in der OTRS Datenbank und das Mapping inKernel/Config.pm. Anschließend laden Sie

über die Kundenverwaltung die Einstellungen des Kunden A und tragen bei "Kundennummern" die Werte "B;C;" ein.

5.2.2. LDAP

Falls Sie ein existierendes LDAP Verzeichnis mit Ihren Kundenbenutzern haben, können

Sie dieses auch mit OTRS nutzen.

Beispiel 4.8. Konfiguration eines LDAP Kunden-Backends

# CustomerUser

# (customer ldap backend and settings)

$Self->{CustomerUser} = {

Name => 'LDAP Data Source',

Module => 'Kernel::System::CustomerUser::LDAP',

Params => {

# ldap host

Host => 'bay.csuhayward.edu',

# ldap base dn

BaseDN => 'ou=seas,o=csuh',

# search scope (one|sub)

SSCOPE => 'sub',

# The following is valid but would only be necessary if the

# anonymous user does NOT have permission to read from the LDAP tree

UserDN => '',

UserPw => '',

# in case you want to add always one filter to each ldap query, use

# this option. e. g. AlwaysFilter => '(mail=*)' or AlwaysFilter =>

'(objectclass=user)'

AlwaysFilter => '',

# if both your frontend and your LDAP are unicode, use this:

108

SourceCharset => 'utf-8',

DestCharset => 'utf-8',

# if your frontend is unicode and the charset of your

# ldap server is iso-8859-1, use these options.

# SourceCharset => 'iso-8859-1',

# DestCharset => 'utf-8',

# Net::LDAP new params (if needed - for more info see perldoc Net::LDAP)

Params => {

port => 389,

timeout => 120,

async => 0,

version => 3,

# customer unique id

CustomerKey => 'uid',

# customer #

CustomerID => 'mail',

CustomerUserListFields => ['cn', 'mail'],

CustomerUserSearchFields => ['uid', 'cn', 'mail'],

CustomerUserSearchPrefix => '',

CustomerUserSearchSuffix => '*',

CustomerUserSearchListLimit => 250,

CustomerUserPostMasterSearchFields => ['mail'],

CustomerUserNameFields => ['givenname', 'sn'],

# show not own tickets in customer panel, CompanyTickets

CustomerUserExcludePrimaryCustomerID => 0,

# add an ldap filter for valid users (expert setting)

# CustomerUserValidFilter => '(!(description=locked))',

# administrator can't change customer preferences

AdminSetPreferences => 0,

# # cache time to live in sec. - cache any database queries

# CacheTTL => 0,

Map => [

# note: Login, Email and CustomerID are mandatory!

# var, frontend, storage, shown (1=always,2=lite), required, storage-type, httplink, readonly

[ 'UserTitle', 'Title', 'title', 1, 0, 'var', '', 0 ],

[ 'UserFirstname', 'Firstname', 'givenname', 1, 1, 'var', '', 0 ],

[ 'UserLastname', 'Lastname', 'sn', 1, 1, 'var', '', 0 ],

[ 'UserLogin', 'Username', 'uid', 1, 1, 'var', '', 0 ],

[ 'UserEmail', 'Email', 'mail', 1, 1, 'var', '', 0 ],

[ 'UserCustomerID', 'CustomerID', 'mail', 0, 1, 'var', '', 0 ],

# [ 'UserCustomerIDs', 'CustomerIDs', 'second_customer_ids', 1, 0, 'var', '', 0 ],

[ 'UserPhone', 'Phone', 'telephonenumber', 1, 0, 'var', '', 0 ],

[ 'UserAddress', 'Address', 'postaladdress', 1, 0, 'var', '', 0 ],

[ 'UserComment', 'Comment', 'description', 1, 0, 'var', '', 0 ],

};

Falls Sie in Ihrem LDAP Verzeichnis weitere Informationen zu Ihren Kunden gespeichert haben und mit OTRS darauf zugreifen möchten, erweitern Sie das MAP Array in Kernel/Config.pm

bzw. entfernen nicht gewünschte Einträge.

# var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link,

readonly

[...]

[ 'UserPhone', 'Phone', 'telephonenumber', 1, 0, 'var', '', 0 ],

Skript: Hinzufügen neuer Felder zu Kernel/Config.pm.

5.2.2.1. Kunden mit multiplen IDs (Firmen-Tickets)

Um Firmentickets mit einem LDAP zu nutzen, muss ein Feld zum LDAP-Verzeichnis hinzugefügt werden, welches die IDs enthält, die für einen Kunden zugänglich sein sollen.

Wenn das neue Feld erstellt wurde, muss es zum MAP Array in Kernel/Config.pm hinzugefügt werden.

109

# var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link,

readonly

[...]

[ 'UserCustomerIDs', 'CustomerIDs', 'customer_ids', 1, 0, 'var', '', 0 ],

Skript: Hinzufügen eines neuen Feldes in Kernel/Config.pm.

Das Feld muss direkt im LDAP-Verzeichnis bearbeitet werden, weil OTRS von LDAP nur lesen kann, nicht jedoch darauf schreiben.

Um nun den Zugriff für einen Kunden auf die Tickets anderer Kunden zu ermöglichen, tragen Sie in das neue LDAP-Feld die IDs der Kunden ein, auf deren Tickets der Zugriff ermöglicht werden soll. Die einzelnen IDs trennen Sie durch ein Semikolon.

Beispiel 4.9. Verwendung von Firmentickets mit einem LDAP-

Backend

Angenommen es sind die Kunden A, B und C im System angelegt. A soll mit Hilfe von

Firmen Tickets über das Kunden-Interface Zugriff auf die Tickets von B und C haben, B und C sollen jedoch jeweils nur ihre eigenen Tickets einsehen und bearbeiten können.

Um dieses Setup zu realisieren, ändern Sie wie oben beschrieben das LDAP Verzeichnis und das Mapping in Kernel/Config.pm. Anschließend tragen Sie im LDAP Verzeichnis innerhalb der Einstellungen für den Kunden A für CustomerIDs die Werte "B;C;" ein.

5.2.3. Gleichzeitige Einbindung mehrerer verschiedener Kunden Backends

Soll mehr als nur ein Back-end mit verschiedenen Kundendaten verwendet werden (z.

B. gleichzeitig DB und LDAP), so ist dies ebenfalls mit OTRS möglich. In einem solchen

Fall muss der CustomerUser Parameter für jedes Back-end um eine Nummer erweitert werden, z. B. "CustomerUser1", "CustomerUser2", usw.

Beispiel 4.10. Gleichzeitige Einbindung mehrerer verschiedener

Kunden Backends

In der folgenden KOnfiguration verwendet OTRS gleichzeitig ein Datenbank- und ein LDAP-

Kunden-Backend.

# 1. Customer user backend: DB

# (Kundendatenbank-Backend und Einstellungen)

$Self->{CustomerUser1} = {

Name => 'Customer Database',

Module => 'Kernel::System::CustomerUser::DB',

Params => {

# if you want to use an external database, add the

# required settings

# DSN => 'DBI:odbc:yourdsn',

# Type => 'mssql', # only for ODBC connections

# DSN => 'DBI:mysql:database=customerdb;host=customerdbhost',

# User => '',

# Password => '',

Table => 'customer_user',

# customer unique id

CustomerKey => 'login',

# customer #

CustomerID => 'customer_id',

CustomerValid => 'valid_id',

CustomerUserListFields => ['first_name', 'last_name', 'email'],

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

CustomerUserSearchPrefix => '',

CustomerUserSearchSuffix => '*',

CustomerUserSearchListLimit => 250,

110

CustomerUserPostMasterSearchFields => ['email'],

CustomerUserNameFields => ['title','first_name','last_name'],

CustomerUserEmailUniqCheck => 1,

# # show not own tickets in customer panel, CompanyTickets

# CustomerUserExcludePrimaryCustomerID => 0,

# # generate auto logins

# AutoLoginCreation => 0,

# AutoLoginCreationPrefix => 'auto',

# # admin can change customer preferences

# AdminSetPreferences => 1,

# # cache time to live in sec. - cache any database queries

# CacheTTL => 0,

# # just a read only source

# ReadOnly => 1,

Map => [

# note: Login, Email und CustomerID werden benötigt!

# var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link,

readonly, http-link-target

[ 'UserTitle', 'Title', 'title', 1, 0, 'var', '', 0 ],

[ 'UserFirstname', 'Firstname', 'first_name', 1, 1, 'var', '', 0 ],

[ 'UserLastname', 'Lastname', 'last_name', 1, 1, 'var', '', 0 ],

[ 'UserLogin', 'Username', 'login', 1, 1, 'var', '', 0 ],

[ 'UserPassword', 'Password', 'pw', 0, 0, 'var', '', 0 ],

[ 'UserEmail', 'Email', 'email', 1, 1, 'var', '', 0 ],

[ 'UserCustomerID', 'CustomerID', 'customer_id', 0, 1, 'var', '', 0 ],

[ 'UserPhone', 'Phone', 'phone', 1, 0, 'var', '', 0 ],

[ 'UserFax', 'Fax', 'fax', 1, 0, 'var', '', 0 ],

[ 'UserMobile', 'Mobile', 'mobile', 1, 0, 'var', '', 0 ],

[ 'UserStreet', 'Street', 'street', 1, 0, 'var', '', 0 ],

[ 'UserZip', 'Zip', 'zip', 1, 0, 'var', '', 0 ],

[ 'UserCity', 'City', 'city', 1, 0, 'var', '', 0 ],

[ 'UserCountry', 'Country', 'country', 1, 0, 'var', '', 0 ],

[ 'UserComment', 'Comment', 'comments', 1, 0, 'var', '', 0 ],

[ 'ValidID', 'Valid', 'valid_id', 0, 1, 'int', '', 0 ],

# Standard-Auswahl

Selections => {

UserTitle => {

'Mr.' => 'Mr.',

'Mrs.' => 'Mrs.',

};

# 2. Kundenbenutzer-Backend: LDAP

# (Kundenbackend LDAP und die Einstellungen)

$Self->{CustomerUser2} = {

Name => 'LDAP Datasource',

Module => 'Kernel::System::CustomerUser::LDAP',

Params => {

# ldap host

Host => 'bay.csuhayward.edu',

# ldap base dn

BaseDN => 'ou=seas,o=csuh',

# search scope (one|sub)

SSCOPE => 'sub',

# # Die folgenden 2 Zeilen sind gültig aber werden nur benötigt wenn

# # der anonyme Benutzer keinen Lesezugriff auf den LDAP-Tree hat

UserDN => '',

UserPw => '',

# Falls Sie einen Filter für die LDAP-Abfrage verwenden möchten benutzen Sie

# die Option. z.B.: AlwaysFilter => '(mail=*)' or AlwaysFilter => '(objectclass=user)'

AlwaysFilter => '',

# if both your frontend and your LDAP are unicode, use this:

# SourceCharset => 'utf-8',

# DestCharset => 'utf-8',

# if your frontend is e. g. iso-8859-1 and the character set of your

# ldap server is utf-8, use these options:

# SourceCharset => 'utf-8',

# DestCharset => 'iso-8859-1',

111

# Net::LDAP Parameter (Mehr Informationen unter perldoc Net::LDAP)

Params => { port => 389, timeout => 120, async => 0, version => 3,

# customer unique id

CustomerKey => 'uid',

# customer #

CustomerID => 'mail',

CustomerUserListFields => ['cn', 'mail'],

CustomerUserSearchFields => ['uid', 'cn', 'mail'],

CustomerUserSearchPrefix => '',

CustomerUserSearchSuffix => '*',

CustomerUserSearchListLimit => 250,

CustomerUserPostMasterSearchFields => ['mail'],

CustomerUserNameFields => ['givenname', 'sn'],

# show not own tickets in customer panel, CompanyTickets

CustomerUserExcludePrimaryCustomerID => 0,

# add a ldap filter for valid users (expert setting)

# CustomerUserValidFilter => '(!(description=locked))',

# admin can't change customer preferences

AdminSetPreferences => 0,

Map => [

# note: Login, Email und CustomerID werden benötigt!

# var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link,

readonly

[ 'UserTitle', 'Title', 'title', 1, 0, 'var', '', 0 ],

[ 'UserFirstname', 'Firstname', 'givenname', 1, 1, 'var', '', 0 ],

[ 'UserLastname', 'Lastname', 'sn', 1, 1, 'var', '', 0 ],

[ 'UserLogin', 'Username', 'uid', 1, 1, 'var', '', 0 ],

[ 'UserEmail', 'Email', 'mail', 1, 1, 'var', '', 0 ],

[ 'UserCustomerID', 'CustomerID', 'mail', 0, 1, 'var', '', 0 ],

# [ 'UserCustomerIDs', 'CustomerIDs', 'second_customer_ids', 1, 0, 'var', '', 0 ],

[ 'UserPhone', 'Phone', 'telephonenumber', 1, 0, 'var', '', 0 ],

[ 'UserAddress', 'Address', 'postaladdress', 1, 0, 'var', '', 0 ],

[ 'UserComment', 'Comment', 'description', 1, 0, 'var', '', 0 ],

};

Es können bis zu 10 Kunden Back-ends gleichzeitig eingebunden werden. Über die Kundenverwaltung in OTRS ist der Zugriff auf die verschiedenen Back-ends möglich.

5.2.4. Speichern der Kundenbenutzerdaten in dynamischen Feldern.

Sometimes it can be useful to also store CustomerUser data directly in dynamic fields of a ticket, for example to create special statistics on this data.

The dynamic field values are set when a ticket is created or when the customer of a ticket is changed. The values of the dynamic fields are taken from the customer data. This works for all backends, but is especially useful for LDAP-backends.

To activate this optional feature of OTRS, please activate the settings "Ticket::EventModulePost###930-DynamicFieldFromCustomerUser" and

"DynamicFieldFromCustomerUser::Mapping". The latter setting contains the configuration of which CustomerUser field entry should be stored in which ticket dynamic field. The fields must be present in the system and should be enabled for AgentTicketFreeText, so that they can be set manually. They mustn't be enabled for AgentTicketPhone, AgentTicketEmail and AgentTicketCustomer. If they were, they would have precedence over the automatically set values.

112

5.3. Backends für die Authentifizierung von

Agenten und Kunden

OTRS bietet die Möglichkeit Agenten und Kunden über verschiedene Back-ends zu authentifizieren.

5.3.1. Authentifizierungs-Backends für Agenten

5.3.1.1. Datenbank (Standard)

Das Backend für die Authentifizierung von Agenten, welches OTRS standardmäßig ver-

wendet, ist die OTRS-Datenbank. Die Agenten können innerhalb des Admin-Bereiches in der Benutzerverwaltung angelegt und bearbeitet werden.

Beispiel 4.11. Agentenauthentifizierung gegen ein Datenbank-

Backend

$Self->{'AuthModule'} = 'Kernel::System::Auth::DB';

5.3.1.2. LDAP

Falls ein LDAP Verzeichnis mit Ihren Agenten-Benutzerdaten verfügbar ist, können Sie das

LDAP Modul für die Authentifizierung Ihrer Agenten nutzen. Dieses Modul greift nur lesend auf die Daten im LDAP Verzeichnis zu, d.h. die Daten können nicht mit OTRS bearbeitet

werden, es können also keine Agenten mit Hilfe der Benutzerverwaltung von OTRS ange-

legt oder bearbeitet werden.

Beispiel 4.12. Agentenauthentifizierung gegen ein LDAP Backend

# This is an example configuration for an LDAP auth. backend.

# (Make sure Net::LDAP is installed!)

$Self->{'AuthModule'} = 'Kernel::System::Auth::LDAP';

$Self->{'AuthModule::LDAP::Host'} = 'ldap.example.com';

$Self->{'AuthModule::LDAP::BaseDN'} = 'dc=example,dc=com';

$Self->{'AuthModule::LDAP::UID'} = 'uid';

# Check if the user is allowed to auth in a posixGroup

# (e. g. user needs to be in a group xyz to use otrs)

$Self->{'AuthModule::LDAP::GroupDN'} = 'cn=otrsallow,ou=posixGroups,dc=example,dc=com';

$Self->{'AuthModule::LDAP::AccessAttr'} = 'memberUid';

# for ldap posixGroups objectclass (just uid)

# $Self->{'AuthModule::LDAP::UserAttr'} = 'UID';

# for non ldap posixGroups objectclass (with full user dn)

# $Self->{'AuthModule::LDAP::UserAttr'} = 'DN';

# The following is valid but would only be necessary if the

# anonymous user do NOT have permission to read from the LDAP tree

$Self->{'AuthModule::LDAP::SearchUserDN'} = '';

$Self->{'AuthModule::LDAP::SearchUserPw'} = '';

# in case you want to add always one filter to each ldap query, use

# this option. e. g. AlwaysFilter => '(mail=*)' or AlwaysFilter => '(objectclass=user)'

$Self->{'AuthModule::LDAP::AlwaysFilter'} = '';

# in case you want to add a suffix to each login name, then

# you can use this option. e. g. user just want to use user but

# in your ldap directory exists user@domain.

# $Self->{'AuthModule::LDAP::UserSuffix'} = '@domain.com';

# Net::LDAP new params (if needed - for more info see perldoc Net::LDAP)

$Self->{'AuthModule::LDAP::Params'} = {

113

port => 389,

timeout => 120,

async => 0,

version => 3,

};

Mit den folgenden Konfigurationsparametern können die Benutzerdaten der Agenten aus dem LDAP in die lokale OTRS Datenbank synchronisiert werden. Dies reduziert die Zugriffe auf ihr LDAP Verzeichnis, entlastet den Server mit den LDAP Daten und beschleunigt die

Anmeldung an OTRS. Die Synchronisierung der Daten findet bei der ersten Anmeldung des Agenten statt, trotz der synchronisierten Daten bleibt ihr LDAP Verzeichnis die letzte

Instanz bei der Anmeldung. D.h. wird ein User im LDAP Verzeichnis gelöscht oder deaktiviert, klappt die Anmeldung an OTRS nicht. Ebenfalls müssen die Daten für einen Agenten weiterhin direkt im LDAP Verzeichnis gepflegt werden.

# defines AuthSyncBackend (AuthSyncModule) for AuthModule

# if this key exists and is empty, there won't be a sync.

# example values: AuthSyncBackend, AuthSyncBackend2

$Self->{'AuthModule::UseSyncBackend'} = 'AuthSyncBackend';

# agent data sync against ldap

$Self->{'AuthSyncModule'} = 'Kernel::System::Auth::Sync::LDAP';

$Self->{'AuthSyncModule::LDAP::Host'} = 'ldap://ldap.example.com/';

$Self->{'AuthSyncModule::LDAP::BaseDN'} = 'dc=otrs, dc=org';

$Self->{'AuthSyncModule::LDAP::UID'} = 'uid';

$Self->{'AuthSyncModule::LDAP::SearchUserDN'} = 'uid=sys, ou=user, dc=otrs, dc=org';

$Self->{'AuthSyncModule::LDAP::SearchUserPw'} = 'some_pass';

$Self->{'AuthSyncModule::LDAP::UserSyncMap'} = {

# DB -> LDAP

UserFirstname => 'givenName',

UserLastname => 'sn',

UserEmail => 'mail',

};

[...]

# AuthSyncModule::LDAP::UserSyncInitialGroups

# (sync following group with rw permission after initial create of first agent

# login)

$Self->{'AuthSyncModule::LDAP::UserSyncInitialGroups'} = [

'users',

];

Skript: Synchronisation der Benutzerdaten aus dem LDAP-Verzeichnis in die OTRS-Datenbank.

5.3.1.3. HTTPBasicAuth für Agenten

Falls Sie eine "single sign on"-Lösung für Ihre Agenten implementieren möchten, benutzen

Sie http basic authentication (für alle Ihre Systeme) und aktivieren Sie das HTTPBasicAuth

Modul.

Beispiel 4.13. Agentenauthentifizierung über HTTPBasic

# This is an example configuration for an apache ($ENV{REMOTE_USER})

# auth. backend. Use it if you want to have a singe login through

# apache http-basic-auth

$Self->{'AuthModule'} = 'Kernel::System::Auth::HTTPBasicAuth';

# Note:

# If you use this module, you should use as fallback

# the following configuration settings if the user is not authorized

# apache ($ENV{REMOTE_USER})

$Self->{LoginURL} = 'http://host.example.com/not-authorised-for-otrs.html';

$Self->{LogoutURL} = 'http://host.example.com/thanks-for-using-otrs.html';

114

5.3.1.4. Radius

Mit den folgenden Einstellungen kann die Authentifizierung von Agenten gegen einen

Radius-Server realisiert werden.

Beispiel 4.14. Agentenauthentifizierung gegen ein Radius-

Backend

# This is example configuration to auth. agents against a radius server

$Self->{'AuthModule'} = 'Kernel::System::Auth::Radius';

$Self->{'AuthModule::Radius::Host'} = 'radiushost';

$Self->{'AuthModule::Radius::Password'} = 'radiussecret';

5.3.2. Authentifizierungs-Backends für Kunden

5.3.2.1. Datenbank (Standard)

Das Backend für die Authentifizierung von Kunden, welches OTRS standardmäßig verwendet, ist die OTRS-Datenbank. Die Kundendaten können über das Interface zur Verwaltung von Kunden angelegt und bearbeitet werden.

Beispiel 4.15. Kundenauthentifizierung gegen ein Datenbank-

Backend

# This is the auth. module against the otrs db

$Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::DB';

$Self->{'Customer::AuthModule::DB::Table'} = 'customer_user';

$Self->{'Customer::AuthModule::DB::CustomerKey'} = 'login';

$Self->{'Customer::AuthModule::DB::CustomerPassword'} = 'pw';

#$Self->{'Customer::AuthModule::DB::DSN'} =

"DBI:mysql:database=customerdb;host=customerdbhost";

#$Self->{'Customer::AuthModule::DB::User'} = "some_user";

#$Self->{'Customer::AuthModule::DB::Password'} = "some_password";

5.3.2.2. LDAP

Falls ein LDAP Verzeichnis mit Ihren Kundenbenutzern verfügbar ist, können Sie das LDAP

Modul für die Authentifizierung Ihrer Kunden nutzen. Dieses Modul greift nur lesend auf die

Daten im LDAP Verzeichnis zu, d.h. die Daten können nicht mit OTRS bearbeitet werden, es können also keine Kunden mit Hilfe der Kundenverwaltung von OTRS angelegt oder bearbeitet werden.

Beispiel 4.16. Kundenauthentifizierung gegen ein LDAP Backend

# This is an example configuration for an LDAP auth. backend.

# (make sure Net::LDAP is installed!)

$Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::LDAP';

$Self->{'Customer::AuthModule::LDAP::Host'} = 'ldap.example.com';

$Self->{'Customer::AuthModule::LDAP::BaseDN'} = 'dc=example,dc=com';

$Self->{'Customer::AuthModule::LDAP::UID'} = 'uid';

# Check if the user is allowed to auth in a posixGroup

# (e. g. user needs to be in a group xyz to use otrs)

$Self->{'Customer::AuthModule::LDAP::GroupDN'} =

'cn=otrsallow,ou=posixGroups,dc=example,dc=com';

$Self->{'Customer::AuthModule::LDAP::AccessAttr'} = 'memberUid';

# for ldap posixGroups objectclass (just uid)

$Self->{'Customer::AuthModule::LDAP::UserAttr'} = 'UID';

# for non ldap posixGroups objectclass (full user dn)

#$Self->{'Customer::AuthModule::LDAP::UserAttr'} = 'DN';

# The following is valid but would only be necessary if the

# anonymous user does NOT have permission to read from the LDAP tree

115

$Self->{'Customer::AuthModule::LDAP::SearchUserDN'} = '';

$Self->{'Customer::AuthModule::LDAP::SearchUserPw'} = '';

# in case you want to add always one filter to each ldap query, use

# this option. e. g. AlwaysFilter => '(mail=*)' or AlwaysFilter => '(objectclass=user)'

$Self->{'Customer::AuthModule::LDAP::AlwaysFilter'} = '';

# in case you want to add a suffix to each customer login name, then

# you can use this option. e. g. user just want to use user but

# in your ldap directory exists user@domain.

#$Self->{'Customer::AuthModule::LDAP::UserSuffix'} = '@domain.com';

# Net::LDAP new params (if needed - for more info see perldoc Net::LDAP)

$Self->{'Customer::AuthModule::LDAP::Params'} = {

port => 389,

timeout => 120,

async => 0,

version => 3,

};

5.3.2.3. HTTPBasicAuth für Kunden

Falls Sie eine "single sign on"-Lösung für Ihre Kunden implementieren möchten, benutzen Sie HTTPBasic Authentication (für alle Ihre Systeme) und aktivieren Sie das HTTPBasicAuth Modul (kein OTRS-Login mehr benötigt).

Beispiel 4.17. Kundenauthentifizierung über HTTPBasic

# This is an example configuration for an apache ($ENV{REMOTE_USER})

# auth. backend. Use it if you want to have a singe login through

# apache http-basic-auth

$Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::HTTPBasicAuth';

# Note:

# If you use this module, you should use the following

# config settings as fallback, if user isn't login through

# apache ($ENV{REMOTE_USER})

$Self->{CustomerPanelLoginURL} = 'http://host.example.com/not-authorised-for-otrs.html';

$Self->{CustomerPanelLogoutURL} = 'http://host.example.com/thanks-for-using-otrs.html';

5.3.2.4. Radius

Mit den folgenden Einstellungen kann die Authentifizierung von Kunden gegen einen Radius-Server realisiert werden.

Beispiel 4.18. Kundenauthentifizierung gegen ein Radius-Backend

# This is a example configuration to auth. customer against a radius server

$Self->{'Customer::AuthModule'} = 'Kernel::System::Auth::Radius';

$Self->{'Customer::AuthModule::Radius::Host'} = 'radiushost';

$Self->{'Customer::AuthModule::Radius::Password'} = 'radiussecret';

5.4. Kunden-Selbstregistrierung anpassen

Es ist möglich, die Kunden-Selbstregistrierung für neue Kunden über "customer.pl" anzupassen. Somit können Sie mehr optionale oder benötigte Felder (z. B. Adresse, Ort, Telefonnummer) hinzufügen.

In folgenden Beispiel wird ein benötigtes Feld für die Raumnummer hinzugefügt.

5.4.1. Anpassen der Weboberfläche

Damit im Webinterface das zusätzliche Feld für die Raumnummer angezeigt wird, muss die zuständige dtl-Datei angepasst werden. Editieren Sie Kernel/Output/HTML/Standard/CustomerLogin.dtl

und fügen Sie das gewünschte Feld hinzu.

116

[...]

<label for="Room">$Text{"Room{CustomerUser}"}</label>

<input title="$Text{"Room Number"}" name="Room" type="text" id="UserRoom"

maxlength="50" />

</div>

[...]

Skript: Anzeigen eines neuen Feldes in der Weboberfläche.

5.4.2. Kunden-Mapping

Zusätzlich muss das Kunden-Mapping um den Eintrag für die Raumnummer erweitert werden. Dazu werden zuerst die Einstellungen für "CustomerUser" aus der Datei Kernel/Config/Defaults.pm

in die Datei Kernel/Config.pm übertragen. Anschließend wird das Kunden-Mapping um das Raumnummer-Feld erweitert.

# CustomerUser

# (customer database backend and settings)

$Self->{CustomerUser} = {

Name => 'Database Backend',

Module => 'Kernel::System::CustomerUser::DB',

Params => {

# if you want to use an external database, add the

# required settings

# DSN => 'DBI:odbc:yourdsn',

# Type => 'mssql', # only for ODBC connections

# DSN => 'DBI:mysql:database=customerdb;host=customerdbhost',

# User => '',

# Password => '',

Table => 'customer_user',

# customer unique id

CustomerKey => 'login',

# customer #

CustomerID => 'customer_id',

CustomerValid => 'valid_id',

CustomerUserListFields => ['first_name', 'last_name', 'email'],

# CustomerUserListFields => ['login', 'first_name', 'last_name', 'customer_id', 'email'],

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

CustomerUserSearchPrefix => '',

CustomerUserSearchSuffix => '*',

CustomerUserSearchListLimit => 250,

CustomerUserPostMasterSearchFields => ['email'],

CustomerUserNameFields => ['title', 'first_name', 'last_name'],

CustomerUserEmailUniqCheck => 1,

# # show not own tickets in customer panel, CompanyTickets

# CustomerUserExcludePrimaryCustomerID => 0,

# # generate auto logins

# AutoLoginCreation => 0,

# AutoLoginCreationPrefix => 'auto',

# # admin can change customer preferences

# AdminSetPreferences => 1,

# # cache time to live in sec. - cache database queries

# CacheTTL => 0,

# # just a read only source

# ReadOnly => 1,

Map => [

# note: Login, Email and CustomerID needed!

# var, frontend, storage, shown (1=always,2=lite), required, storage-type, httplink, readonly, http-link-target

[ 'UserTitle', 'Title', 'title', 1, 0, 'var', '', 0 ],

[ 'UserFirstname', 'Firstname', 'first_name', 1, 1, 'var', '', 0 ],

[ 'UserLastname', 'Lastname', 'last_name', 1, 1, 'var', '', 0 ],

[ 'UserLogin', 'Username', 'login', 1, 1, 'var', '', 0 ],

[ 'UserPassword', 'Password', 'pw', 0, 0, 'var', '', 0 ],

[ 'UserEmail', 'Email', 'email', 1, 1, 'var', '', 0 ],

117

[ 'UserCustomerID', 'CustomerID', 'customer_id', 0, 1, 'var', '', 0 ],

[ 'UserPhone', 'Phone', 'phone', 1, 0, 'var', '', 0 ],

[ 'UserFax', 'Fax', 'fax', 1, 0, 'var', '', 0 ],

[ 'UserMobile', 'Mobile', 'mobile', 1, 0, 'var', '', 0 ],

[ 'UserRoom', 'Room', 'room', 1, 0, 'var', '', 0 ],

[ 'UserStreet', 'Street', 'street', 1, 0, 'var', '', 0 ],

[ 'UserZip', 'Zip', 'zip', 1, 0, 'var', '', 0 ],

[ 'UserCity', 'City', 'city', 1, 0, 'var', '', 0 ],

[ 'UserCountry', 'Country', 'country', 1, 0, 'var', '', 0 ],

[ 'UserComment', 'Comment', 'comments', 1, 0, 'var', '', 0 ],

[ 'ValidID', 'Valid', 'valid_id', 0, 1, 'int', '', 0 ],

# default selections

Selections => {

UserTitle => {

'Mr.' => 'Mr.',

'Mrs.' => 'Mrs.',

};

Skript: Anpassung des MAP-Arrays.

5.4.3. Anpassen der Kunden-Tabelle in der OTRS-

Datenbank

Abschließend muss eine neue Spalte zur "customer_user" Tabelle in der OTRS Datenbank hinzugefügt werden, in der die Raumnummer gespeichert werden kann.

linux:~# mysql -p

Enter password:

Welcome to the MySQL monitor. Commands end with ; or \g.

Your MySQL connection id is 6 to server version: 5.0.18-Debian_7-log

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> use otrs;

Reading table information for completion of table and column names

You can turn off this feature to get a quicker startup with -A

Database changed mysql> ALTER TABLE customer_user ADD room VARCHAR (200);

Query OK, 3 rows affected (0.01 sec)

Records: 3 Duplicates: 0 Warnings: 0 mysql> quit

Bye linux:~#

Skript: Hinzufügen einer neuen Spalte zur Tabelle customer_user.

Now the new field for the room should be displayed in the Customer Information panel if filled, and in the Customer User administration screens. Also, new customers should have to insert their room number if they register a new account. If you use OTRS on Microsoft

IIS, you should restart the web server to activate the changes made in Config.pm.

6. Ticket-Einstellungen

6.1. Ticket Status

6.1.1. Vordefinierte Ticket-Status

OTRS erlaubt es Ihnen, die Ticket-Status zu verändern oder neue Status hinzuzufügen.

Hierbei gibt es zwei wichtige Optionen: den Namen des Status und Typ des Status.

118

Die standardmäßig voreingestellten Status lauten: 'neu', 'offen', 'erfolgreich geschlossen',

'erfolglos geschlossen', 'merged', 'entfernt', 'warten auf erfolgreich schließen', 'warten auf erfolglos schließen' und 'warten zur Erinnerung'.

6.1.1.1. Neu

Tickets sind normalerweise nur in diesem Status, wenn sie von eingehenden E-Mails neu erzeugt werden.

6.1.1.2. Öffnen

Der Standardstatus für Tickets, die Queues und Agents zugeordnet sind.

6.1.1.3. Warten zur Erinnerung

Nachdem die Wartezeit abgelaufen ist, erhält der Ticketbesitzer eine E-Mail zu dem Ticket.

Wenn es nicht gesperrt ist, wird die Erinnerung an alle Agenten der Queue verschickt.

Erinnerungs-Benachrichtigungen werden nur innerhalb der Arbeitszeiten versendet, und werden alle 24 Stunden wiederholt, bis der Status des Tickets vom Agenten verändert wird. Die Zeit, die dieses Ticket in diesem Status verbringt, wird dennoch bei der Berechnung der Eskalationszeiten einbezogen.

6.1.1.4. Warten auf erfolglos schließen

Wenn die Wartezeit abgelaufen ist, wird das Ticket auf "erfolglos geschlossen" gesetzt.

Die Zeit, die dieses Ticket in diesem Status verbringt, wird dennoch bei der Berechnung der Eskalationszeiten einbezogen.

6.1.1.5. Warten auf erfolgreich schließen

Wenn die Wartezeit abgelaufen ist, wird das Ticket auf "erfolgreich geschlossen" gesetzt.

Die Zeit, die dieses Ticket in diesem Status verbringt, wird dennoch bei der Berechnung der Eskalationszeiten einbezogen.

6.1.1.6. Zusammengefügt

Status von Tickets, die mit anderen Tickets zusammengefügt wurden.

6.1.1.7. Erfolgreich geschlossen

Endstatus für Tickets, die erfolgreich gelöst werden konnten. Je nach Konfiguration kann es unmöglich sein, geschlossene Tickets wieder zu eröffnen.

6.1.1.8. Erfolglos geschlossen

Endstatus für Tickets, die NICHT erfolgreich gelöst werden konnten. Je nach Konfiguration kann es unmöglich sein, geschlossene Tickets wieder zu eröffnen.

6.1.2. Anpassen von Ticket-Status

Jeder Status besteht aus einem Namen ("state-name") und einem Typen ("state-type").

Der Name ist frei wählbar und kann über das Admin-Interface von OTRS angepasst werden, die Statustypen müssen direkt in der Datenbank geändert werden. Letzteres wird jedoch nicht empfohlen und kann zu unerwarteten Ergebnissen führen. Z. B. hängen die

Berechnung der Eskalationszeiten und auch die Funktion zum automatischen Entsperren von Tickets von bestimmten Statustypen ab.

Im Admin-Interface können Sie innerhalb der Einstellungen für "Status" neue Status für die vorhandenen Statustypen hinzufügen oder ändern. Beachten Sie, dass Sie bei Änderungen am Status "neu - new" auch die entsprechenden Änderungen in der Konfigura-

119

tionsdateiKernel/Config.pm bzw. mit Hilfe des grafischen Konfigurations-Front-End vornehmen müssen. Folgende Änderungen müssen für einen geänderten "neu"-Status vorgenommen werden:

[...]

# PostmasterDefaultState

# (The default state of new tickets.) [default: new]

$Self->{PostmasterDefaultState} = 'new';

# CustomerDefaultState

# (default state of new customer tickets)

$Self->{CustomerDefaultState} = 'new';

[...]

Skript: Anpassung der Einstellungen von Kernel/Config.pm.

Möchten Sie einen neuen Statustyp hinzufügen, müssen Sie zuerst die ticket_status-type-

Tabelle in der OTRS Datenbank mit Hilfe eines entsprechenden Datenbankclient anpassen.

linux:~# mysql -p

Enter password:

Welcome to the MySQL monitor. Commands end with ; or \g.

Your MySQL connection id is 23 to server version: 5.0.16-Debian_1-log

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> use otrs;

Reading table information for completion of table and column names

You can turn off this feature to get a quicker startup with -A

Database changed mysql> insert into ticket_state_type (name,comments) values ('own','Own state type');

Query OK, 1 row affected (0.00 sec) mysql> quit

Bye linux:~#

Skript: Anpassung der Statustypen.

Nun können Sie den neuen Statustyp verwenden. Nachdem ein Status mit diesem Statustyp verknüpft wurde, muss auch die OTRS-Konfiguration angepasst werden, damit der neue Status korrekt verwendet werden kann. Passen Sie die Folgenden Optionen in der

SysConfig an:

Ticket -> Frontend::Agent::Ticket::ViewPhoneNew > AgentTicketPhone###StateDefault

- um den vorgegebenen nächsten Status für neue Telefon-Tickets zu definieren.

Ticket -> Frontend::Agent::Ticket::ViewPhoneNew > AgentTicketPhone###StateType -

um die verfügbaren nächsten Status für neue Telefon-Tickets zu definieren.

Ticket -> Frontend::Agent::Ticket::ViewEmailNew > AgentTicketEmail###StateDefault -

um den standardmäßigen 'Nächsten Status des Tickets' für E-Mailtickets zu definieren.

Ticket -> Frontend::Agent::Ticket::ViewEmailNew > AgentTicketEmail###StateType -

um die verfügbaren 'Nächsten Status' für neue E-Mailtickets zu definieren.

Ticket -> Frontend::Agent::Ticket::ViewPhoneOutbound >

AgentTicketPhoneOutbound###State - um den standardmäßigen 'Nächsten Status des

Tickets' für neue Artikel in Telefontickets zu definieren.

Ticket -> Frontend::Agent::Ticket::ViewEmailNew > AgentTicketEmail###StateType -

um die verfügbaren 'Nächsten Status' für neue Artikel in Telefontickets zu definieren.

120

Ticket -> Frontend::Agent::Ticket::ViewMove > AgentTicketMove###State - um den

Standard-Status für Tickets zu definieren, wenn ein Ticket verschoben wird.

Ticket -> Frontend::Agent::Ticket::ViewMove > AgentTicketMove###StateType - um die

verfügbaren nächsten Status eines Tickets zu definieren, wenn ein Ticket verschoben wird.

Ticket -> Frontend::Agent::Ticket::ViewBounce > StateDefault - um den Standard-Status

für Tickets zu definieren, wenn ein Ticket weitergeleitet wird.

Ticket -> Frontend::Agent::Ticket::ViewBounce > StateType - um die verfügbaren nächs-

ten Status eines Tickets zu definieren, wenn ein Ticket weitergeleitet wird.

Ticket -> Frontend::Agent::Ticket::ViewBulk > StateDefault - um den Standard-Status für

Tickets zu definieren, wenn eine Sammelaktion durchgeführt wird.

Ticket -> Frontend::Agent::Ticket::ViewBulk > StateType - um die verfügbaren nächsten

Status eines Tickets zu definieren, wenn eine Sammelaktion durchgeführt wird.

Ticket -> Frontend::Agent::Ticket::ViewClose > StateDefault - um den Standard-Status

für Tickets zu definieren, wenn ein Ticket geschlossen werden soll.

Ticket -> Frontend::Agent::Ticket::ViewClose > StateType - um die verfügbaren nächsten

Status eines Tickets zu definieren, wenn ein Ticket geschlosen werden soll.

Ticket -> Frontend::Agent::Ticket::ViewCompose > StateDefault - um den Standard-Sta-

tus für Tickets zu definieren, wenn auf ein Ticket geantwortet (AgentTicketCompose) werden soll.

Ticket -> Frontend::Agent::Ticket::ViewCompose > StateType - um die verfügbaren

nächsten Status eines Tickets zu definieren, wenn auf ein Ticket gewantwortet (AgentTicketCompose) werden soll.

Ticket -> Frontend::Agent::Ticket::ViewForward > StateDefault - um den Standard-Status

für Tickets zu definieren, wenn ein Ticket weitergeleitet werden soll.

Ticket -> Frontend::Agent::Ticket::ViewForward > StateType - um die verfügbaren nächs-

ten Status eines Tickets zu definieren, wenn ein Ticket weitergeleitet werden soll.

Ticket -> Frontend::Agent::Ticket::ViewForward > StateDefault - um den Standard-Status

für Tickets in der Oberfläche 'Freie Felder' zu definieren,

Ticket -> Frontend::Agent::Ticket::ViewForward > StateType - um die verfügbaren nächs-

ten Status eines Tickets in der Oberfläche 'Freie Felder' zu definieren.

Ticket -> Core::PostMaster > PostmasterDefaultState - um den Status von Tickets zu

definieren, die aus E-Mails erstellt wurden.

Ticket -> Core::PostMaster > PostmasterFollowUpState - um den Status von Tickets fest-

zulegen, nachdem ein Follow-Up eingegangen ist.

Ticket -> Core::PostMaster > PostmasterFollowUpStateClosed - um den Status von

bereits geschlossenen Tickets festzulegen, nachdem ein Follow-Up eingegangen ist.

Ticket -> Core::Ticket > ViewableStateType - um die Statustypen festzulegen, die in

verschiedenen Bereichen des Systems angezeigt werden, z. B. in der Queue-Ansicht.

Ticket -> Core::Ticket > UnlockStateType - um die verfügbaren Statustypen für entsperrte

Tickets zu definieren.

Ticket -> Core::Ticket > PendingReminderStateType - um den Statustyp für Erinnerungsti-

ckets festzulegen.

121

Ticket -> Core::Ticket > PendingAutoStateType - um den Statustyp für Tickets mit "War-

ten Auto" festzulegen.

Ticket -> Core::Ticket > StateAfterPending - um den Status zu definieren, auf welchen

Tickets, deren "Warten Auto"-Timer des eingestellten Status abgelaufen ist, gesetzt werden.

6.2. Ticket Prioritäten

OTRS enthält 5 vordefinierte Ticketprioritäten, die mit dem "Prioritäten"-Modul im Administrationsbereich verwaltet werden können. Wenn Sie eine angepasste Prioritätenliste erstellen, bedenken Sie bitte, dass diese in der Prioritätsauswahl-Liste alphabetisch sortiert dargestellt werden. In der Queue-Ansicht ordnet OTRS die Prioritäten nach internen

Datenbank-IDs.

Anmerkung

In OTRS können Prioritäten deaktiviert, aber nicht gelöscht werden. Wenn Sie eine

Priorität deaktivieren wollen, setzen Sie den Wert für "Gültig" auf "ungültig" oder

"ungültig-temporär".

Wichtig

Wenn eine Priorität hinzugefügt oder geändert wurde, müssen Sie ggf. einige Werte in der SysConfig anpassen:

• Ticket:Core::Postmaster::PostmasterDefaultPriority - definiert die Standard-Prio-

rität für alle eingehenden E-Mails.

• Ticket:Frontend::Agent:Ticket::ViewPhoneNew:Priority - definiert die Stan-

dard-Priorität in der Oberfläche 'Neues Telefonticket' für Agenten.

• Ticket:Frontend::Agent:Ticket::ViewEmailNew:Priority - definiert die Stan-

dard-Priorität in der Oberfläche 'Neues E-Mailticket' für Agenten.

• Ticket:Frontend::Customer:Ticket::ViewNew:PriorityDefault - definiert die Stan-

dard-Priorität in der Oberfläche 'Neues Ticket' im Kunden-Interface.

6.3. Ticket-Verantwortlicher und Beobachten von Tickets

Seit OTRS 2.1 kann zusätzlich zum Besitzer ein Verantwortlicher für das Ticket festgelegt werden. Zudem können alle Aktivitäten rund um das Ticket auch von jemand anderem als dem Besitzer beobachtet werden. Diese beiden Funktionalitäten sind mit den TicketResponsible- und dem TicketWatcher-Funktionen implementiert, und erleichtern das Zuweisen von Aufgaben und die Arbeit in hierarchischen Teamstrukturen.

6.3.1. Ticket-Verantwortlicher

Die Funktion "Verantwortlicher" eines Tickets macht es möglich, das Ticket einem anderen als dem aktuellen Besitzer zur Bearbeitung zu übergeben. Ein Benutzer, der ein Ticket gesperrt hat, kann es einem anderen Agenten, der nicht der Ticketbesitzer ist, zur Beantwortung übergeben. Nach der Bearbeitung kann der erste Benutzer die Ticketverantwortung vom zweiten wieder entfernen.

Mit dem Konfigurationsparameter Ticket::Responsible kann die Funktion TicketRespon-

sible aktiviert werden. Dadurch werden 3 neue Icons in ihrer Toolbar erscheinen.

122

Die Ticketverantwortung kann übergeben werden, indem das Ticket aufgerufen und die

Funktion "Verantwortlicher" in der Aktionsleiste genutzt wird.

Abb.: Verantwortlichen eines Tickets ändern.

Nach dem Klick auf "Verantwortlicher" öffnet sich ein Popup-Fenster, in dem die Änderung durchgeführt werden kann. Damit kann auch dem neuen verantwortlichen Benutzer eine

Nachricht geschickt werden.

Abb.: Popup-Dialog zum Ändern des Ticket-Verantwortlichen.

Die Liste aller Tickets, für die ein Benutzer verantwortlich ist, kann durch die Ansicht "Verantwortliche Tickets" eingesehen werden. Diese kann über 3 Icons in der Toolbar aufgerufen werden, sobald das TicketResponsible-Feature aktiviert wird.

6.3.2. Tickets beobachten

Sollen innerhalb des Ticket-Systems lediglich bestimmte Tickets z. B. von einem Abteilungsleiter beobachtet und nicht selbst bearbeitet werden, so kann dies seit OTRS 2.1 mit

Hilfe des TicketWatcher-Features realisiert werden.

The TicketWatcher feature can be activated with the configuration parameter

Ticket::Watcher which adds new links to your actions toolbar. Using Ticket::WatcherGroup,

one or more user groups with permission to watch tickets can also be defined.

Um ein Ticket zu beobachten, muss der Inhalt des Tickets aufgerufen und im Menü für die verschiedenen Aktionen für das Ticket der "Beobachten"-Schalter betätigt werden.

123

Abb.: Ticket beobachten.

Die Beobachtung eines Tickets wird aufgehoben, indem in der Inhaltsanzeige eines Tickets im Menü für die möglichen Aktionen der "Nicht beobachten"-Schalter gedrückt wird.

Abb.: Ticket nicht mehr beobachten.

Die Liste aller zur Beobachtung ausgewählten Tickets wird über die Ansicht "Beobachtete

Tickets" erreicht. Diese kann über 3 Icons in der Toolbar aufgerufen werden, sobald das

TicketWatcher-Feature aktiviert wird.

124

Abb.: Ansicht "Beobachtete Tickets".

7. Zeitabhängige Funktionen in OTRS

7.1. Arbeitszeiten, Feiertage und Zeitzonen für das System festlegen

Some functions in OTRS, like escalations and automatic unlocking of tickets, depend on

a proper configuration of business hours, time zones and holidays. You can define these

via the SysConfig interface, in Framework > Core::Time. You can also specify different

sets of business hours, holidays and time zones as separate 'Calendars' in Framework

> Core::Time::Calendar1 through Framework > Core::Time::Calendar9. Calendars can be

defined by queue settings, or on SLA levels. This means that, for example, you can spe-

cify a calendar with 5 x 8 business hours for your 'standard' SLA, but create a separate calendar with 7 x 24 support for your 'gold' SLA; as well as set a calendar for your 'Support-USA' queue with a different time window than your 'Support-Japan' queue. OTRS can handle up to 99 different calendars.

7.1.1. Arbeitszeiten

Set up the working hours for your system in SysConfig Framework >

Core::Time::TimeWorkingHours, or for your specific calendar in the calendar's configura-

tion. OTRS can handle a granularity of one hour. Checking the marks in the boxes 8, 9,

10 ... 17 corresponds with business hours of 8 AM - 6 PM.

Nur während dieser Stunden können Tickets eskalieren, Benachrichtigungen zu Erinnerungs-Tickets versendet oder Tickets automatisch freigegeben werden. Weiterhin werden auch nur diese Stunden in die Berechnung der Eskalationszeit und der Zeit für die automatische Freigabe mit einbezogen.

7.1.2. Feiertage mit festem Datum

Holidays that are on a fixed date every year, such as New Year's Day or the Fourth of July,

can be specified in TimeVacationDays, or in the corresponding section for the calendars

1-9.

Während der hier festgelegten Tage werden keine zeitabhängigen Aktionen oder Berechnungen auf Tickets im system ausgeführt.

125

Anmerkung

In OTRS sind die deutschen Feiertage voreingestellt.

7.1.3. TimeVacationDaysOneTime

Holidays such as Easter that do not have a yearly fixed date but instead vary each year,

can be specified in TimeVacationDaysOneTime.

Während der hier festgelegten Tage werden keine zeitabhängigen Aktionen oder Berechnungen auf Tickets im system ausgeführt.

Anmerkung

OTRS hat für diese Feiertage keine Voreinstellung. Sie müssen diese, wie z. B.

Ostern, dem System also selbst bekannt machen.

7.2. Automatische Ticket-"Freigabe" (unlock)

Gesperrte Tickets können automatisch vom System freigegeben werden. Diese Funktion kann z. B. dann nützlich sein, wenn sich ein Agent im Urlaub befindet und noch Tickets gesperrt hat, die bearbeitet werden sollen / müssen. Dieses Feature entsperrt Tickets nach einer bestimmten Zeit, um sicherzustellen, dass gesperrte Tickets nicht vergessen werden und andere Agenten darauf zugreifen können.

Die Zeit, nach der gesperrte Tickets automatisch freigegeben werden, kann in

den Einstellungen jeder Queue festgelegt werden. Mit Hilfe des Moduls bin/

otrs.UnlockTickets.pl

, das als cron-Job regelmäßig ausgeführt werden sollte, wird die automatische Freigabe von Tickets umgesetzt.

Benachrichtigungen für entsperrte Tickets werden nur zu den Benutzern versendet, die die jeweilige Queue in "Meine Queues" eingetragen und die Benachrichtigung für ent-

sperrte Tickets in ihren persönlichen Einstellungen aktiviert haben.

Tickets werden entsperrt wenn folgende Bedingungen zutreffen:

• In der Queue des Tickets ist ein Freigabe-Zeitintervall definiert.

• Das Ticket ist gesperrt.

• Der Status des Tickets is offen".

Die Freigabezeit wird zurückgesetzt, wenn ein Agent einen neuen externen Artikel zum

Ticket hinzufügt. Das kann einer der folgenden Artikeltypen sein: email-external, phone,

fax, sms, or note-external.

Die Freigabezeit wird auch zurückgesetzt, wenn der letzte Artikel von einem Agent stammt und dann der Kunde einen hinzufügt, per E-Mail oder Weboberfläche.

Zuletzt wird die Freigabezeit auch dann zurückgesetzt, wenn das Ticket einem anderen

Agenten zugewiesen wird.

8. Anpassen der PDF-Ausgabe

Dieser Abschnitt behandelt die Einstellungen für die PDF-Druckausgabe von OTRS.

If you use the Print action from anywhere within the OTRS interface, it will generate a

formatted PDF file. You can deactivate this by modifying the configuration parameter PDF

to create HTML output instead.

126

You can adjust the look of the files generated by OTRS by creating your own logo and

adding it to PDF::LogoFile. You can use PDF::PageSize to define the standard page size of the generated pdf file (DIN-A4 or Letter), and also PDF::MaxPage to specify the maximum

number of pages for a pdf file, which is useful if a user generates a huge output file by mistake.

Für die Generierung von PDF-Dateien müssen die CPAN-Module PDF::API2 und

Compress::Zlib installiert werden. Bei vielen Distributionen sind diese als Paket verfügbar und können bequem über den jeweiligen Paketmanager installiert werden, falls dies jedoch nicht möglich ist muss der direkte Weg über CPAN gewählt werden. Das Kapitel

Installation der für OTRS benötigten Perl-Module beschreibt, wie die Installation der Perl-

Module durchzuführen ist.

9. Statistikmodul

The OTRS stats module holds features to track operational statistics and generates custom reports associated with OTRS usage. The OTRS system uses the term "stat" generically to refer to a report presenting various indicators.

Eine sinnvolle Konfiguration des OTRS-Statistikmoduls ist verbunden mit einer Vielzahl von Anforderungen und Überlegungen. Darin eingeschlossen sind die auszuwertenden

Module von OTRS, Benutzerrechte, zu berechnende Indikatoren und ihre Komplexitätsgrade, eine einfache Konfiguration des Statistikmoduls, Geschwindigkeit und Effizienz der

Berechnungen, und die Unterstützung verschiedener Ausgabevarianten.

Um komplexe Statistiken abzubilden, besteht ferner die Möglichkeit statische Elemente zu integrieren (Dateien, die die Funktionalität des Statistik-Moduls um ganz spezifische

Anforderungen ergänzen).

9.1. Bedienung des Moduls durch den Agent

When signed on as an agent, the navigation bar displays the link "Statistics", with various submenu options, as shown in Figure.

Abb.: Statistikmenü.

Folgende Optionen sind im Statistikmenü verfügbar:

• Übersicht. Zeigt eine Liste vorkonfigurierter Reports an.

127

• Neu. Benötigt "rw"-Rechte.

• Importieren. Benötigt "rw"-Rechte.

9.1.1. Übersicht

Die Auswahl von "Statistik" und des Unterpunktes "Übersicht" ruft den Übersichtsbildschirm auf. Hier wird dem Agenten eine Liste von vorkonfigurierten Reports präsentiert, die er verwenden kann.

Abb.: Übersicht der Standardstatistiken.

Folgende Informationen sind den in der Übersicht aufgelisteten Statistiken zu entnehmen:

• Stat#. Eindeutige Statistiknummer.

• Titel. Titel der Statistik.

• Objekt. Objekt, das für die Generierung der Statistik verwendet wird. Wenn es sich um eine statische Statistik handelt, wird kein Objekt angezeigt, da kein dynamisches Objekt zur Generierung verwendet wird.

• Beschreibung. Ein Auszug aus der Beschreibung der Statistik.

Wenn das Statistikmodul installiert ist, enthält es einige vorkonfigurierte Reports. Diese können in der Übersicht aufgerufen werden. Wenn die Liste zu lang für eine Seite wird, kann der Agent durch die verschiedenen Seiten blättern. Die Liste kann durch klick auf den

Spaltenkopf wie gewünscht geordnet werden. Um einen bestimmten Report zu erzeugen, klicken Sie auf die Statistiknummer des Reports in der Übersicht. Dadurch gelangen Sie in die Ansichtsseite des Reports.

9.1.2. Ansehen und Generieren von Statistiken

Aufgabe der "Ansehen"-Oberfläche ist es, dem Agent einen Überblick über die Vorkonfiguration der Statistik zu ermöglichen.

128

Abb.: Ansicht einer Statistik.

Konfigurationseinstellungen für einen Report können in den Optionen der Ansichtsseite eingestellt werden. Der Ersteller des Reports und jeder Agent mit den benötigten Rechten kann diese Einstellungen vornehmen.

Konkret wird auf dieser Seite folgendes angezeigt:

• Verfügbare Aktionen:

• Zurück zur Übersicht. Zurück zur Übersichtsliste der Reports.

• Bearbeiten. Die aktuelle Statistik bearbeiten (benötigt "rw"-Rechte).

• Löschen. Die aktuelle Statistik löschen (benötigt "rw"-Rechte).

• Konfiguration exportieren. Exportieren einer Statistikkonfiguration mittels Dateidownload ("rw"-Rechte erforderlich).

Verwendung: Mittels der Export- und Importfunktionen können Statistiken bequem auf Testsystemen entworfen und getestet werden, um dann anschließend einfach in das Produktivsystem integriert zu werden.

• Report-Details:

• Statistik-Nr.. Die Nummer der Statistik.

• Titel. Titel der Statistik.

• Objekt. Objekt, das für die Generierung der Statistik verwendet wird.

• Beschreibung. Ein Auszug aus der Beschreibung der Statistik.

• Format. Ausgabeformat der Statistik. Hierbei stehen je nach Konfiguration folgende

Ausgabeformate zur Verfügung:

• CSV.

• Drucken.

• Liniendiagramm.

• Balkendiagramm.

129

• Balkendiagramm (horizontal).

• Punktdiagramm

• Linienpunktdiagramm.

• Flächendiagramm.

• Tortendiagramm.

• Grafikgröße. Mögliche Größe der Grafik bzw. des Diagramms. Diese Auswahl bzw.

Anzeige erscheint nur, wenn die Statistikvorkonfiguration ein Diagramm vorsieht bzw.

ermöglicht. Alle generell verwendbaren Grafikgrößen werden durch den otrs-Admin in der SysConfig definiert. Beim Konfigurieren der Statistiken kann dann der Ersteller alle relevanten Formate vorselektieren.

• Zeilensummierung. Gibt an, ob die Statistik durch eine Spalte ergänzt wird, deren

Zellen die Summe der jeweiligen Zeile darstellt.

• Spaltensummierung. Angabe, ob die Statistik durch eine Zeile ergänzt wird, deren

Zellen die Summe der jeweiligen Spalte beinhaltet.

• Cache. Gibt an, ob die errechneten Statistiken im Dateisystem gecacht werden.

• Gültig. Ist eine vorkonfigurierte Statistik erst im Entstehen oder darf sie aus bestimmten Gründen temporär nicht mehr ausgeführt werden so wird das Element "Gültig" auf "ungültig" gesetzt. Ferner wird dadurch die Schaltfläche "Start" rechts unten am

Ende des Block ausgeblendet. Ein Generieren der Statistik ist somit nicht möglich.

• Erstellt. Erstellungszeit der Statistik.

• Erstellt von. Agent, der die Statistik erstellt hat.

• Geändert. Letzte Änderungszeit der Statistik.

• Geändert von. Agent, der die Statistik zuletzt geändert hat.

• X-Achse. Diese Option erlaubt es dem Agenten, die X- und Y-Achsen zu vertauschen

(Diese Funktion muss vom OTRS-Administrator freigeschaltet werden).

• Nach den allgemeinen Angaben sieht der Agent die Angaben zur eigentlichen Statistik. Hierbei kommen grundsätzlich zwei verschiedene Anzeigen zum Einsatz:

• Anzeige statischer Statistiken. Statische Report-Generatoren können in die Statistik integriert werden (siehe unten).

130

Abb.: Ansicht der statischen Statistik.

• Anzeige dynamischer Statistiken Dynamische Statistiken können auf zweierlei Weise angezeigt werden:

• Unveränderbare Einstellungen. In diesem Fall hat der Ersteller der Statistik dem

Agent, der eine Statistik generieren will, keinen Freiraum für Veränderungen gelassen.

• Veränderbare Einstellungen. Bei derartigen Statistiken ist es dem Agent noch erlaubt die vorkonfigurierte Statistik zu verändern.

Um eine Statistik zu generieren, muss abschließend lediglich der "Start"-Button am rechten unteren Ende des Blocks gedrückt werden. Sollte einmal der "Start"-Button nicht sichtbar sein, kann dies zwei Ursachen haben:

1. die Statistik wurde auf ungültig gesetzt und damit deaktiviert.

2. die Statistik wurde nicht sauber konfiguriert und ist noch nicht lauffähig. Ist dies der

Fall, findet man die nötigen Informationen im Notification-Bereich von OTRS (unterhalb der Navigationsleiste).

Bei falschen Einstellungen auf der Ansichtsseite wird nach Drücken des "Start"-Button wieder die Ansichtseite gezeigt und im Notificationbereich darauf hingewiesen, welche

Eingaben falsch waren.

9.1.3. Bearbeiten / Neu

Agenten mit Schreibrechten können existierende Report-Konfigurationen bearbeiten, indem sie die Bearbeitungsmaske des Statistikmoduls aufrufen. Altertativ können sie einen neuen Report erstellen. Die zugehörigen Masken können folgendermaßen aufgerufen werden:

1. Durch den Knopf "Bearbeiten" in der Statistikansicht.

2. Durch den "Neu"-Link im Statistikmenü der Navigationsleiste, oder durch den Knopf

"Hinzufügen" in der Übersichtsseite.

Das Bearbeiten der Statistiken erfolgt in vier Schritten mit Hilfe eines Assistenten bzw.

Wizards:

1. Allgemeine Angaben zur Statistik.

131

2. Festlegen des Elements für die X-Achse.

3. Festlegen der Wertereihen.

4. Festlegen der Einschränkungen des Reports.

Die Punkte 2-4 werden nur für dynamisch zusammengestellte Statistiken benötigt.

Benutzt man eine statische Statistik ist man mit dem Einfügen der allgemeinen Angaben in Punkt 1. bereits fertig.

Für alle Eingabeoberflächen des Statistik-Moduls gilt: Im Anschluss an das jeweilige Eingabeformular findet der Benutzer Informationen zur Bedienung der Seite.

Sollte es dennoch zu fehlerhaften Eingaben kommen, wird die zuvor bearbeitete Oberfläche wieder geladen. Dabei wird die Seite um Informationen zur fehlerhaften Eingabe ergänzt. Diese Informationen findet man im Notificationbereich von OTRS. Erst nachdem ein Formular korrekt ausgefüllt wurde, gelangt man zur nächsten Eingabeoberfläche.

1. Allgemeine Angaben. Dies ist die erste Seite des Assistenten.

Abb.: Allgemeine Angaben zur Statistik bearbeiten.

Folgende allgemeine Angaben und Einstellungen der Statistik können geändert werden:

• Titel. Er sollte kurz und prägnant die Aufgabe der Statistik wiedergeben.

• Beschreibung. Hier werden Informationen eingetragen, die einen tieferen Einblick in die Aufgabenstellung, Art der Konfigurationsparameter, usw. erlauben.

• Dynamisches Objekt. Sollte die OTRS-Installation über mehrere dynamische Objekte verfügen, kann hier das gewünschte Objekt ausgewählt werden. Die Objekte sind jeweils auf die Anforderungen des entsprechenden Moduls ausgelegt.

• Statische Datei. An dieser Stelle kann eine gewünschte statische Datei ausgewählt werden. Diese Auswahl wird für gewöhnlich nicht erscheinen, da nur die statischen

Dateien angezeigt werden, die noch keiner Statistik zugeordnet wurden! Wenn der

Punkt "Statische Datei" angezeigt wird, ist es wichtig im Formular durch die Auswahl des Optionsfelds die gewünschte Generierungsart auszuwählen (Dynamisch durch ein dynamisches Objekt oder statisch durch eine Datei). Wird eine statische Datei ausgewählt entfallen die Eingabeoberflächen 2-4, da die statische Datei die nötigen

Konfigurationen bereits mitbringt.

• Rechtevergabe. Durch die Rechtevergabe kann man regeln, welche Gruppen (und dadurch welche Agents) die vorkonfigurierten Statistiken später ansehen und gene-

132

rieren können. So können die verschiedenen Statistiken auf die verschiedenen Abteilungen und Arbeitsgruppen aufgeteilt werden, die diese benötigen. Eine Mehrfachauswahl ist dabei möglich.

Beispiel 1: Die Gruppe "stats" wurde ausgewählt. Der Report kann von allen Nutzern verwendet werden, die mindestens "ro"-Rechte für die Gruppe "stats" haben. Diese

Berechtigung ist die Voreinstellung.

Beispiel 2: Es wurde eine Gruppe namens "sales" selektiert. Alle Benutzer die ro-

Rechte in der Gruppe "sales" haben können nun diese Statistik im Ansichtsmodus sehen und generieren. Anderen Benutzern, die in der Lage sind Statistiken zu generieren wird dann diese Statistik nicht angeboten.

• Format. Ausgabeformat der Statistik. Hierbei stehen je nach Konfiguration folgende

Ausgabeformate zur Verfügung:

• CSV.

• Drucken.

• Liniendiagramm.

• Balkendiagramm.

• Balkendiagramm (horizontal).

• Punktdiagramm.

• Linienpunktdiagramm.

• Flächendiagramm.

• Tortendiagramm.

• Grafikgröße. Hier kann ausgewählt werden, in welchen Größen (Pixel) die Diagramme ausgegeben werden dürfen. Diese Auswahl ist nur sinnvoll, wenn unter dem Punkt

"Format" ein grafisches Ausgabeformat ausgewählt wurde. Alle generell verwendbaren Grafikgrößen werden durch den OTRS-Admin in der SysConfig definiert. Bei der

Konfiguration der Statistiken kann der Ersteller alle relevanten Formate vorselektieren.

• Zeilensummierung. Wird im "Ja" ausgewählt, wird die Statistik durch eine Spalte ergänzt, deren Zellen die Summe der jeweiligen Zeile darstellt.

• Spaltensummierung. Angabe, ob die Statistik durch eine Zeile ergänzt wird, deren

Zellen die Summe der jeweiligen Spalte beinhaltet.

• Cache. Wird im "Ja" ausgewählt, werden die errechneten Statistiken im Dateisystem gecacht. Dies spart Rechenleistung und Zeit, sollte genau diese Statistik wieder aufgerufen werden. Diese Funktion ist jedoch nur sinnvoll, wenn sichergestellt ist, dass sich der Inhalt der Statistik nicht mehr ändert. Dies ist genau zu prüfen, bevor man die Cachingfunktion nutzt.

Caching wird automatisch verhindert, wenn die Statistik keinerlei Zeitangaben enthält (es kommen laufend neue Daten hinzu) oder wenn eine Zeitangabe in der

Zukunft liegt.

Sollte eine Statistik zwischenzeitlich wieder bearbeitet werden, werden alle gecachten Daten wieder gelöscht.

133

Ende des Block ausgeblendet. Ein Generieren der Statistik ist somit nicht möglich.

2. Definition des Elements für die X-Achse. Hier wird eingestellt welches Element für die

Darstellung der X-Achse verwendet wird, bzw. bei Tabellen, welche Spaltenbezeichnung die Statistik bekommt.

Abb.: Definition des Elements für die X-Achse.

Als erstes wählt man ein Element per Optionsfeld aus. Anschließend müssen zwei oder mehr Attribute des Elements selektiert werden. Werden keine Attribute des Elements ausgewählt, werden alle Attribute verwendet, auch solche die nach der Konfiguration der Statistik hinzukommen.

Entfernt man den Haken "Fixiert" in der Checkbox, kann der Agent, der die Statistik erstellt, die Attribute des entsprechenden Elements in der "Ansehen"-Oberfläche ver-

ändern.

Eine Besonderheit stellen Zeitelemente dar, hier ist die Zeitspanne und die Skalierung anzugeben. Die Art und Anzahl der Elemente ergibt sich durch das verwendete dynamische Objekt und ist von Objekt zu Objekt verschieden.

Wurden alle Eingaben richtig getätigt, gelangt man nach der Auswahl des "Weiter"

Schalters zu dem Formular "Wertereihen". Ebenfalls gibt es die Möglichkeit, einen Bearbeitungsschritt zurück zu gehen und nochmals die Oberfläche "Allgemeine Angaben" zu bearbeiten.

3. Wertereihen.

Im dritten Schritt der Vorkonfiguration einer Statistik werden die Wertereihen der Statistik festgelegt. Sie bilden später die einzelnen Grafen des Diagramms (grafische Darstellung) oder die einzelnen Reihen (tabellarische Darstellung).

134

Abb.: Festlegen der Wertereihen.

Wird ein Element selektiert, entspricht jedes ausgewählte Attribut einer Wertereihe.

Beispiel 4.19. Festlegen einer Wertereihe bei einem Element

Element Queue:

• Wertereihe 1 = Raw

• Wertereihe 2 = Junk

• ....

Werden zwei Elemente selektiert, wird jedes ausgewählte Attribut des ersten Elements kombiniert mit einem Attribut des zweiten Elements zu einer Wertereihe.

Beispiel 4.20. Festlegen einer Wertereihe bei zwei Elementen

Element 1 Queue, Element 2 Status:

• Wertereihe 1 = Raw - offen

• Wertereihe 2 = Raw - erfolgreich geschlossen

• Wertereihe 3 = Junk - offen

• Wertereihe 4 = Junk - erfolgreich geschlossen

Die Auswahl von drei oder mehr Elementen ist nicht sinnvoll und wird deshalb durch eine Fehlermeldung verhindert.

Ferner gelten noch die gleichen Bedingungen zur Auswahl der Attribute und zur "Fixiert"

Checkbox wie bei der "X-Achsen" Auswahl.

• Werden keine Attribute des Elements ausgewählt, werden alle Attribute verwendet, auch solche die nach der Konfiguration der Statistik hinzukommen.

• Entfernt man den Haken "Fixiert" in der Checkbox, kann der Agent der die Statistik erstellt, die Attribute des entsprechenden Elements verändern.

135

4. Festlegen der Einschränkungen. Vierter und letzter Schritt bei der Vorkonfiguration ist das Festlegen der Einschränkungen. Hier ist es möglich die Ergebnisse einer Statistik durch die Angabe von Bedingungen einzuschränken. Vergleichbar ist dies mit Eingaben in eine Such-Oberfläche.

Abb.: Festlegen der Einschränkungen.

Nachdem man alle Einschränkungen getätigt hat, drückt man den Button "Abschlie-

ßen". Dadurch beendet man die Vorkonfiguration der Statistik und gelangt in die "Ansehen" Oberfläche.

9.1.4. Importieren

Durch die Auswahl des "Import"-Menüpunkts im Statistikmenü der Navigationsleiste oder durch den "Import"-Knopf in der Übersichtsmaske gelangt man in die Importoberfläche

("rw"-Rechte erforderlich).

Abb.: Die Import-Oberfläche.

Durch sie können Statistiken importiert werden. Dies ist im Zusammenhang mit der

Exportfunktion des Moduls eine sehr hilfreiche Funktionalität. So können Statistiken bequem auf Testsystemen entworfen und getestet werden, um sie später auf dem Produktivsystem zu importieren.

136

Der Import geschieht dabei ganz einfach durch einen Dateiupload. Anschließend gelangt man automatisch in die Detailansicht der importierten Statistik.

9.2. Verwaltung des Statistik-Moduls durch den OTRS-Administrator

In diesem Abschnitt werden die Aufgaben und Möglichkeiten des OTRS-Administrators in

Bezug auf das Statistikmodul angesprochen.

9.2.1. Rechte, Gruppen und Queues

Durch die Installation des Statistikmoduls werden keine neuen Queues oder/und Gruppen angelegt.

Durch die Standardkonfiguration der Modulregistrierung haben alle Agenten, die Rechte in der "stats"-Gruppe haben, Zugriff auf das Statistikmodul.

Zugangsmöglichkeiten aufgrund der Rechte:

• rw. Darf Statistiken konfigurieren.

• ro. Darf vorkonfigurierte Statistiken generieren.

Ob nun dem jeweiligen Agenten, der später vorkonfigurierte Statistiken generieren darf, ro-Rechte in der "stats" Gruppe zugewiesen werden oder in der Modulregistrierung der

SysConfig die dem Agent entsprechenden Gruppen ergänzt werden, bleibt dem OTRS-

Administrator und dessen Anforderungen überlassen.

9.2.2. Die SysConfig (Verwaltung der Systemkonfiguration)

The SysConfig groups Framework:Core::Stats, Framework:Core::Stats::Graph and

Framework:Frontend::Agent::Stats contain all configuration parameters for the basic

set-up of the statistics module. Moreover, the configuration parameter $Self-

>{'Frontend::Module'}->{'AgentStats'} controls the arrangement and registration of the

modules and icons within the statistics module.

9.3. Verwaltung des Statistik-Moduls durch den System-Administrator

Grundsätzlich ist bei der Bedienung, Konfiguration und Wartung des Statistikmoduls kein

System-Administrator notwendig. An dieser Stelle sollen nur einige Hintergrundinformationen für den System-Administrator gegeben werden.

Anmerkung

Pfadangaben beziehen sich auf Unterverzeichnisse des OTRS-Homeverzeichnisses

(meist /opt/otrs).

9.3.1. Datenbanktabelle

Alle Statistikkonfigurationen werden in XML umgesetzt und verwaltet. Dies bedeutet unter anderem, dass alle Statistikkonfigurationen in der Datenbanktabelle "xml_storage" gespeichert werden. Diese Tabelle wird auch von anderen Modulen benutzt, deren Inhalte im XML-Format dargestellt werden.

137

9.3.2. Auflistung aller Dateien

Folgende Dateien sind für die fehlerfreie Funktion des Statistikmoduls notwendig.

• Kernel/System/Stats.pm

• Kernel/Modules/AgentStats.pm

• Kernel/System/CSV.pm

• Kernel/Output/HTML/Standard/AgentStatsOverview.dtl

• Kernel/Output/HTML/Standard/AgentStatsDelete.dtl

• Kernel/Output/HTML/Standard/AgentStatsEditSpecification.dtl

• Kernel/Output/HTML/Standard/AgentStatsEditRestrictions.dtl

• Kernel/Output/HTML/Standard/AgentStatsEditXaxis.dtl

• Kernel/Output/HTML/Standard/AgentStatsEditValueSeries.dtl

• Kernel/Output/HTML/Standard/AgentStatsImport.dtl

• Kernel/Output/HTML/Standard/AgentStatsPrint.dtl

• Kernel/Output/HTML/Standard/AgentStatsView.dtl

• Kernel/System/Stats/Dynamic/Ticket.pm

• bin/otrs.GenerateStats.pl

9.3.3. Caching

Bei der Vorkonfiguration von Statistiken kann eingestellt werden, ob die Ergebnisse einer

Statistik gecachet werden oder nicht. Statistikergebnisse, die in den Cache geschrieben werden sollen, werden als Datei im Verzeichnis var/tmp der OTRS-Installation gespeichert

(meist /opt/otrs/var/tmp).

Alle gecacheten Statistiken sind dabei durch das Präfix "Stats" zu erkennen.

Sollten diese Dateien verloren gehen, ist dies nicht weiter schlimm. Beim nächsten Aufruf dieser Statistik kann das Statistikmodul diese Datei nicht mehr finden und muss deshalb die Statistik neu errechnen, was etwas Zeit beanspruchen kann.

9.3.4. otrs.GenerateStats.pl

Diese Datei befindet sich im Verzeichnis bin/. Durch sie ist es möglich, Statistiken auf der Kommandozeile zu generieren.

Exemplarisch soll hierzu folgender Kommandozeilenaufruf angegeben werden: bin> perl otrs.GenerateStats.pl -n 10004 -o /output/dir

Skript: Generieren einer Statistik auf der Kommandozeile.

Dabei wird eine Statistik aus der Statistikkonfiguration "Stat# 10004" generiert und als csv in das Verzeichnis /output/dir gespeichert.

138

Ferner kann die generierte Statistik auch per Email versandt werden. Mehr Informationen erhält man wie im Skript geschildert.

bin> perl otrs.GenerateStats.pl --help

Skript: Aufruf der Hilfe von otrs.GenerateStats.pl.

9.3.5. Automatisiertes Generieren von Statistiken -

Cron

Sinnvoll ist das Generieren von Statistiken per Hand über die Kommandozeile natürlich nicht unbedingt, da das Statistikmodul eine geeignete grafische Oberfläche bietet. Interessant wird die Generierung von Statistiken per Kommandozeile aber in Kombination mit einem Cronjob.

Folgendes Szenario ist denkbar: Ein Abteilungsleiter wünscht pünktlich zum ersten eines

Monats eine Statistik zum abgelaufenen Monat. Durch die Kombination Cronjob und Kommandozeilenaufruf ist man in der Lage automatisiert zu Beginn eines Monats dem Abteilungsleiter die gewünschte Statistik per Email zukommen zu lassen.

9.3.6. Statische Statistiken

Das Statistikmodul bietet die Möglichkeit statische Statistiken zu generieren. Für jede statische Statistik gibt es eine Datei, in der die Inhalte der Statistik genau definiert sind.

Vorteil dieser Art von Statistik ist, dass dadurch sehr komplexe Statistiken erzeugt werden können. Der Nachteil ist wiederum die mangelnde Flexibilität dieser Statistiken.

Gespeichert werden diese Dateien unter folgendem Pfad: Kernel/System/Stats/Static/ .

9.3.7. Wiederverwerten alter statischer Statistiken

Bereits OTRS 1.3 und 2.0 boten die Möglichkeit Statistiken zu generieren. Eine Vielzahl der Statistiken, die für OTRS-Versionen 1.3 und 2.0 speziell auf Kundenwunsch entwickelt wurden, können wiederverwendet werden.

Diese Dateien müssen hierzu lediglich aus dem Pfad Kernel/System/Stats/ in den Pfad

Kernel/System/Stats/Static/ verschoben werden. Ferner muss die Paketangabe des jeweiligen Skripts um "::Static" ergänzt werden.

Das folgende Beispiel zeigt die Erweiterung des Paketnamens.

package Kernel::System::Stats::AccountedTime;

package Kernel::System::Stats::Static::AccountedTime;

9.3.8. Standardstatistiken

"Man muss das Rad nicht immer neu erfinden."

Deshalb liefert das Statistikmodul automatisch Standardstatistiken mit. Statistiken, die für alle OTRS-Benutzer interessant sind, werden zukünftig als Defaultstatistik im Statistik-Modul-Paket ergänzt. Gespeichert werden die Defaultstatistiken im XML-Format des

Statistikmoduls im Verzeichnis scripts/test/sample/.

139

10. Dynamische Felder

10.1. Einführung

Ein dynamisches Feld ist ein ein spezielles Feld in OTRS um die am Ticket oder Artikel gespeicherten Informationen zu erweitern. Diese Felder werden nicht fix im System festgelegt und sind nur in bestimmten Oberflächen sichtbar, sie können verpflichtend sein oder nicht und ihre Darstellung in Oberflächen ist abhängig vom Feldtyp, der während der

Erstellung gewählt wurde. Zum Beispiel gibt es Felder, um einen Text, ein Datum, usw.

eine Auswahl zu erfassen.

Dynamische Felder sind eine Weiterentwicklung der Felder TicketFreeText, TicketFreeKey,

TicketFreeTime, ArticleFreeText und ArticleFreeKey welche in OTRS 3.0 und früher genutzt wurden. Die Limitierung dieser "FreeFields" war, dass lediglich bis 16 (Text oder Einfachauswahl) Felder definiert werden konnten und 6 Zeitfelder für ein Ticket und 3 (Text oder

Dropdown) Felder für einen Artikel, nicht mehr.

Now with dynamic fields the limitation in the number of fields per ticket or article is removed, you can create as many dynamic fields you like either for ticket or articles. And beyond that, the framework behind the dynamic fields is prepared to handle custom fields for other objects rather than just ticket and articles.

This new framework that handles the dynamic fields is build using a modular approach, where each kind of dynamic field can be seen as a plug-in module for the framework. This means that the variety of dynamic fields can be easily extended by public OTRS modules,

OTRS Feature Add-ons, OTRS custom developments, and other custom developments.

Die folgenden dynamischen Feldtypen sind in diesem Release inbegriffen:

• Text (eine Zeile)

• Textfeld (mehrere Zeilen Text)

• Kontrollkästchen

• Einfachauswahl (eine Auswahl, mehrere Auswahlmöglichkeiten)

• Mehrfachauswahl (mehere Auswahlmöglichkeiten)

• Datum

• Datum / Zeit

10.2. Konfiguration

Standardmäßig enthält eine Neu-Installation von OTRS keine dynamische Felder. Wenn

Sie solche Felder in Tickets oder Artikel verwenden möchten, müssen Sie dynamische

Felder erstellen.

Die Konfiguration dynamischer Felder teilt sich in zwei Bereiche auf. Um ein dynamisches

Feld hinzuzufügen oder ein bereits existierendes zu editieren navigieren Sie im Admin-

Interface auf den Link "Dynamische Felder". Um ein dynamisches Feld als verpflichtend zu setzen oder um es in den Oberflächen zu verstecken, müssen Sie die benötigten Einstellungen in der "Sysconfig" vornehmen.

10.2.1. Hinzufügen eines dynamischen Feldes

Klicken Sie auf die Schaltfläche "Admin" in der Navigationsleiste, dann auf den Link "Dynamische Felder" im Bereich "Ticketeinstellungen". Die Übersicht der dynamischen Felder sieht wie folgt aus:

140

Abbildung.: Leere Übersichtsseite der dynamischen Felder.

Beachten Sie das sich diese Übersicht ändern wird, wenn Sie dynamische Felderhinzufügen. Diese Übersicht könnte bereits einige dynamische Felder anzeigen, wenn die Installation von einer älteren OTRS Version geupdatet wurde.

Die Aktionen in der linken Seitenleiste zeigt zwei Möglichkeiten an: Artikel und Ticket, jede

Möglichkeit hat seine eigene Dropdown-Auswahl für dynamische Felder.

Anmerkung

Die Installation eines OTRS-Paketes kann mehrere Objekte zur SideBar hinzufügen.

Der allgemeine Ablauf um dynamische Felder zu erstellen ist:

• Klicken Sie auf den gewünschten Typ des dynamischen Feldes in der Aktionen-SideBar.

• Klicken Sie auf den Typ des dynamischen Feldes, den Sie aus der Liste hinzufügen wollen.

• füllen der Konfiguration.

• Speichern.

Der Konfigurationsdialoge für die dynamischen Felder sind in zwei Bereiche unterteilt. Der obere Teil ist für alle Felder gleich und der untere Teil ist für jeden Feldtyp unterschiedlich.

Allgemeine Einstellungen für dynamische Felder:

• Name: verpflichtend, einmalig, es sind nur Buchstaben und Zahlen erlaubt.

Das ist der interne Name des Feldes um zum Beispiel ein Feld in einer Oberfläche anzeigen oder verstecken zu lassen. Jede Veränderung eines Feldnamens (nicht empfohlen)

141

benötigt ebenfalls einen manuellen Eingriff in den "Sysconfig"-Einstellungen, in denen das Feld referenziert wird.

• Bezeichnung: verpflichtend.

Dieser Name wird auf den Bildschirmen angezeigt, auf denen dieses Feld aktiv ist, es werden Übersetzungen unterstützt.

Anmerkung

Übersetzungen der Beschriftungen müssen Sie manuell zu den Übersetzungsdateien hinzufügen.

• Feldreihenfolge: verpflichtend.

Definiert die relative Reihenfolge, in der das Feld in Oberflächen angezeigt wird. Standardmäßig werden neue Felder an der letzten Position angezeigt. Wird diese Einstellung geändert, betrifft das ebenfalls die Reihenfolge anderer dynamischen Felder.

• Gültigkeit: verpflichtend.

Ein ungültiges dynamisches Feld wird in keiner Oberfläche angezeigt, gan egal ob es als sichtbar konfiguriert ist.

• Feldtyp: verpflichtet, nur lesend.

Zeigt den aktuell ausgewählten Feldtyp an.

• Objekttyp: verpflichtend, nur lesend.

Zeigt den Geltungsbereich des Feldes.

Anmerkung

Um die spezifischen Feldeinstellungen zu verdeutlichen, werden einige dynamische Felder in unserem Beispiel hinzugefügt. Diese neuen dynamischen Felder werden in späteren Abschnitten referenziert.

Für das folgende Beispiel werden alle dynamischen Felder für das Ticketobjekt hinzugefügt. Möchten Sie dynamische Felder für das Artikelobjekt hinzufügen, wählen

Sie die Felder einfach im Artikel-Dropdownliste aus.

Tabelle 4.6. Die folgenden Felder werden zu dem System hinzugefügt:

Name

Feld1

Feld2

Feld3

Feld4

Feld5

Feld6

Feld7

Beschriftung

Mein Feld 1

Mein Feld 2

Mein Feld 3

Mein Feld 4

Mein Feld 5

Mein Feld 6

Typ

Text

Textfeld

Kontrollkästchen

Einfachauswahl

Mehrfachauswahl

Datum

Datum / Zeit

10.2.2. Konfiguration der Textzeilen in dynamischen

Feldern

dynamische Felder vom Typ Text wird benutzt und Einfachzeilen zu speichern.

142

Einstellungen für Texte in dynamischen Feldern:

• Standardwert: Optional

Dieser Wert wird standardmäßig in den Editieroberflächen angezeigt (wie Neues Telefonticket oder Verfassen).

• Link anzeigen: Optional.

Wenn gesetzt, wird der Feldwert in einen klickbaren Link in den Oberflächen konvertiert

(wie TicketZoom oder Übersichten).

Zum Beispiel, wenn "Show link" auf "http://www.otrs.com" gesetzt ist, wird ein klick auf diesen Wert die OTRS-Webseite in Ihrem Browser aufrufen.

Anmerkung

Das Verwenden von $LQData{"NameX"} im Wert, wobei NameX der Name des

Feldes ist, wird den Feldwert als Teil des Links hinzufügen.

Abbildung: Konfigurationsdialog für Textfelder in dynamischen Feldern.

10.2.3. Konfiguration von Textfeldern in dynamischen

Feldern

dynamische Felder vom Typ Textbereich werden verwendet um Mehrfachzeilen zu speichern.

Einstellungen für Textfelder in dynamischen Feldern:

• Anzahl der Zeilen: Optional, Zahl.

Verwendet, um die Höhe des Feldes in den Editier-Oberflächen (wie Neues Telefonticket oder TicketCompose) zu definieren.

143

• Anzahl der Spalten: Optional, Integer.

Dieser Wert wird verwendet, um die Breite des Feldes in den Editier-Oberflächen zu definieren.

• Standardwert: Optional

Dies ist der Wert, der standardmäßig in den Editier-Oberflächen angezeigt wird (kann ein mehrzeiliges Textfeld sein).

Abbildung: Konfigurationsdialog für Textfelder in dynamischen Feldern.

10.2.4. Konfiguration von Checkboxen in dynamischen

Feldern

Checkbox in dynamischen Feldern werden verwendet, um wahre oder falsche Werte, dargestellt durch ein aktiviertes oder deaktiviertes Kontrollkästchen, zu speichern.

Einstellungen für Checkboxen in dynamischen Feldern:

• Standardwert: Verpflichtend.

Dies ist der Wert, der standardmäßig in den Editier-Oberflächen angezeigt wird (kann ein mehrzeiliges Textfeld sein), der Standard-Wert für dieses Feld kann 'Aktiviert' oder

'Deaktiviert' sein.

144

Abbildung: Konfigurationsdialog für Checkboxen in dynamischen Feldern.

10.2.5. Konfiguration von Einfachauswahlen in dynamischen Feldern

Dynamische Felder vom Typ Einfachauswahl werden verwendet um einen einfachen Wert, aus einer Liste, zu speichern.

Einstellungen für Einfachauswahl in dynamischen Feldern:

• Mögliche Werte: Verbindlich.

Liste aus Werten, die ausgewählt werden können. Soll ein zusätzliches Listen-Item hinzugefügt werden, ist es nötig den Key (interner Wert) und den Wert (angezeigter Wert) anzugeben.

• Standardwert: Optional

Dies ist der Wert, der standardmäßig in den Editier-Oberflächen angezeigt wird (wie

Neues Telefonticket oder Verfassen), der Standard-Wert für dieses Feld kann kann aus den definierten Werten vorgegeben werden.

• Hinzufügen eines leeren Wertes: Verpflichtend, (Ja / Nein).

Wenn diese Option aktiviert ist, wird ein extra Wert hinzugefügt, der als "-" in der Liste der möglichen Werte angezeigt wird. Dieser spezielle Wert ist intern als leer gekennzeichnet.

• Wertübersetzung: Verpflichtend, (Ja / Nein).

Diese Einstellung wird verwendet um die möglichen Werte dieses Feldes zu übersetzen.

Es werden jedoch nur die angezeigten Werte übersetzt, die internen Werte sind nicht davon betroffen. Die Übersetzung der Werte müssen manuell in den Übersetzungsdateien hinzugefügt werden.

145

• Link anzeigen: Optional.

Wenn gesetzt, wird der Feldwert in einen klickbaren Link in den Oberflächen konvertiert

(wie TicketZoom oder Übersichten).

Zum Beispiel, wenn "Show link" auf "http://www.otrs.com" gesetzt ist, wird ein klick auf diesen Wert die OTRS-Webseite in Ihrem Browser aufrufen.

Anmerkung

Das Verwenden von $LQData{"NameX"} im Wert, wobei NameX der Name des

Feldes ist, wird den Feldwert als Teil des Links hinzufügen.

Abbildung: Konfigurationsdialog für Einfachauswahl in dynamischen Feldern.

10.2.6. Konfiguration der Mehrfachauswahl in dynamischen Feldern

Dynamische Felder vom Typ Mehrfachauswahl werden verwendet um mehrere Werte aus einer definierten Liste zu speichern.

Einstellungen für dynamische Felder vom Typ Mehrfachauswahl:

• Mögliche Werte: Verbindlich.

Liste aus Werten, die ausgewählt werden können. Soll ein zusätzliches Listen-Item hinzugefügt werden, ist es nötig den Key (interner Wert) und den Wert (angezeigter Wert) anzugeben.

• Standardwert: Optional

Dies ist der Wert, der standardmäßig in den Editier-Oberflächen angezeigt wird (wie

Neues Telefonticket oder Verfassen), der Standard-Wert für dieses Feld kann kann aus den definierten Werten vorgegeben werden.

146

• Hinzufügen eines leeren Wertes: Verpflichtend, (Ja / Nein).

Wenn diese Option aktiviert ist, wird ein extra Wert hinzugefügt, der als "-" in der Liste der möglichen Werte angezeigt wird. Dieser spezielle Wert ist intern als leer gekennzeichnet.

• Wertübersetzung: Verpflichtend, (Ja / Nein).

Diese Einstellung wird verwendet um die möglichen Werte dieses Feldes zu übersetzen.

Es werden jedoch nur die angezeigten Werte übersetzt, die internen Werte sind nicht davon betroffen. Die Übersetzung der Werte müssen manuell in den Übersetzungsdateien hinzugefügt werden.

Abbildung: Konfigurationsdialog für Mehrfachauswahlen in dynamischen Feldern.

10.2.7. Konfiguration von Datumsfeldern in dynamischen Feldern

Dynamische Felder vom Typ Datum werden verwendet um ein Datum zu speichern. (Tag,

Monat und Jahr).

Einstellungen für Datumsfelder in dynamischen Feldern:

• Standard-Datumsunterschied: Optional, Integer.

Sekunden (positiv oder negativ) zwischen dem aktuellen Datum und dem gewählten

Datum, dass standardmäßig in Editieroberflächen gewählt sein soll (wie Neues Telefonticket oder Verfassen).

• Definiert den Jahresbereich: Verpflichtend (Ja / Nein).

Wird verwendet, um eine bestimmte Anzahl von Jahren in der Vergangenheit und in der Zukunft, basierend auf dem aktuellen Datum zu wählen, der für dieses Feld gesetzt wird, wenn es auf Ja gesetzt ist, sind folgende Optionen verfügbar:

147

• Jahre in der Vergangenheit: Optional, positive Zahlen.

Definiert die Anzahl der Jahre in der Vergangenheit die angezeigt werden sollen, ausgehend vom aktuellen Datum.

• Jahre in der Zukunft: Optional, positive Zahlen

Definiert die Anzahl der Jahre in derZukunft die angezeigt werden sollen, ausgehend vom aktuellen Datum.

• Link anzeigen: Optional.

Wenn gesetzt, wird der Feldwert in einen klickbaren Link in den Oberflächen konvertiert

(wie TicketZoom oder Übersichten).

Zum Beispiel, wenn "Show link" auf "http://www.otrs.com" gesetzt ist, wird ein klick auf diesen Wert die OTRS-Webseite in Ihrem Browser aufrufen.

Anmerkung

Das Verwenden von $LQData{"NameX"} im Wert, wobei NameX der Name des

Feldes ist, wird den Feldwert als Teil des Links hinzufügen.

Abbildung: Konfigurationsdialog für Datumsfelder in dynamischen Feldern.

10.2.8. Konfiguration von Datum / Zeit in dynamischen

Feldern

Dynamische Felder vom Typ Datum / Zeit werden verwendet um ein Datum und eine Zeit zu speichern. (Minute, Stunde, Tag, Monat und Jahr).

Einstellung für Datum- / Zeitfelder in dynamischen Feldern:

148

• Standard-Datumsunterschied: Optional, Integer.

Sekunden (positiv oder negativ) zwischen dem aktuellen Datum und dem gewählten

Datum, dass standardmäßig in Editieroberflächen gewählt sein soll (wie Neues Telefonticket oder Verfassen).

• Definiert den Jahresbereich: Verpflichtend (Ja / Nein).

• Jahre in der Vergangenheit: Optional, positive Zahlen.

Definiert die Anzahl der Jahre in der Vergangenheit die angezeigt werden sollen, ausgehend vom aktuellen Datum.

• Jahre in der Zukunft: Optional, positive Zahlen

Definiert die Anzahl der Jahre in derZukunft die angezeigt werden sollen, ausgehend vom aktuellen Datum.

• Link anzeigen: Optional.

Wenn gesetzt, wird der Feldwert in einen klickbaren Link in den Oberflächen konvertiert

(wie TicketZoom oder Übersichten).

Zum Beispiel, wenn "Show link" auf "http://www.otrs.com" gesetzt ist, wird ein klick auf diesen Wert die OTRS-Webseite in Ihrem Browser aufrufen.

Anmerkung

Das Verwenden von $LQData{"NameX"} im Wert, wobei NameX der Name des

Feldes ist, wird den Feldwert als Teil des Links hinzufügen.

149

Abbildung: Konfigurationsdialog für Datum / Zeit in dynamischen Feldern.

10.2.9. Editieren eines dynamischen Feldes

Eine gefüllte Übersichtsseite der dynamischen Feldern (mit den vorherigen Beispielen) sollte so aussehen:

Abbildung.: Übersichtsseite der dynamischen Felder gefüllt mit Beispieldaten.

Um ein dynamisches Feld zu ändern oder zu editieren, muss mindestens ein dynamisches

Feld definiert sein. Wählen Sie ein bereits bestehendes Feld aus der Übersichtsseite aus und aktualisieren Sie die Einstellungen.

Anmerkung

Nicht alle Einstellungen von dynamischen Feldern können geändert werden. Der

Feld- und Objekttyp können nicht verändert werden.

Es wird nicht empfohlen, den internen Feldnamen zu ändern, aber die Beschriftung kann jederzeit geändert werden. Wenn der interne Feldname geändert wird, müssen alle Einstellungen in der "SysConfig", die auf dieses Feld verweisen ebenfalls aktualisiert werden, genauso wie die Benutzereinstellungen (falls definiert).

10.2.10. Anzeigen eines dynamischen Feldern

Um ein dynamisches Feld auf einer Oberfläche anzuzeigen, sind zwei zwingende Vorraussetzungen nötig:

1. Das dynamische Feld muss gültig sein.

2. Das dynamische Feld muss in der Konfiguration der Oberfläche auf 1 oder 2 gesetzt sein.

150

Folgen Sie diesen Schritten um ein dynamisches Feld in einer Oberfläche anzuzeigen

• Vergewissern Sie sich, dass das dynamische Wert auf gültig gesetzt ist. Sie sehen die

Gültigkeit in der Übersichtsseite der dynamischen Felder. Setzen Sie, wenn nötig, das dynamische Feld auf gültig.

• Öffnen Sie die "Sysconfig" und wählen Sie in der Dropdownliste in der linken Aktionen-Sidebar "Ticket".

Anmerkung

Ebenfalls können Sie nach "DynamicField" oder nach dem Sysconfig-Schlüssel direkt suchen.

• Suchen Sie nach der Untergruppe für die Oberfläche, die Sie editieren wollen und klicken

Sie darauf. Zum Beispiel: "Frontend::Agent::Ticket::ViewPhoneNew".

• Suchen Sie nach der Einstellung, die mit "###DynamicField" endet. Zum Beispiel:

"Ticket::Frontend::AgentTicketPhone###DynamicField".

• Wenn die Einstellung leer ist oder nicht den benötigten Feldnamen besitzt, klicken Sie auf "+" um einen neuen Eintrag hinzuzufügen. Zum Beispiel: Field1, Content: 1.

Wenn diese Einstellung bereits das dynamische Feld anzeigt, vergewissern Sie sich das es auf "1" gesetzt ist, damit es angezeigt wird oder das es auf "2" gesetzt ist, damit es verpflichtend ist.

• Speichern Sie die Konfiguration durch klicken auf "Aktualisieren" am Ende der Oberfläche und navigieren Sie anschließend zu der Oberfläche, wo das dynamische Feld angezeigt werden soll.

10.2.10.1. Beispiele

Die folgenden "SysConfig" Konfigurationen sind Beispiele um zu zeigen, wie dynamische

Felder angezeigt oder versteckt werden können.

Beispiel 4.21. Feld1 im Dialog NewPhoneTicket anzeigen

• Gruppe: Ticket

• Untergruppe: Frontend::Agent::Ticket::ViewPhoneNew

• Einstellung: Ticket::Frontend::AgentTicketPhone###DynamicField

• Wert:

Schlüssel

Feld1

Inhalt

151

Abbildung: Feld1 in NewPhoneTicket Dialog.

Beispiel 4.22. Activate Field1 in New Phone Ticket Screen as mandatory. Feld1 als verpflichtend in Dialog NewPhoneTicket setzen.

• Gruppe: Ticket

• Untergruppe: Frontend::Agent::Ticket::ViewPhoneNew

• Einstellung: Ticket::Frontend::AgentTicketPhone###DynamicField

• Wert:

Schlüssel

Feld1

Inhalt

152

Abbildung: Feld1 in der Oberfläche 'Neues Telefonticket' als verpflichtendes Feld.

Beispiel 4.23. Aktivieren von verschiedenen Feldern in der

Oberfläche 'Neues Telefonticket'.

• Gruppe: Ticket

• Untergruppe: Frontend::Agent::Ticket::ViewPhoneNew

• Einstellung: Ticket::Frontend::AgentTicketPhone###DynamicField

• Wert:

Schlüssel

Feld1

Feld2

Feld3

Feld4

Feld5

Feld6

Feld7

Inhalt

153

Abbildung: Verschiedene Felder in der Oberfläche 'Neues Telefonticket' als verpflichtende

Felder.

Beispiel 4.24. Deaktivieren von Feldern in der Oberfläche 'Neues

Telefonticket'.

• Gruppe: Ticket

• Untergruppe: Frontend::Agent::Ticket::ViewPhoneNew

• Einstellung: Ticket::Frontend::AgentTicketPhone###DynamicField

• Wert:

Schlüssel

Feld1

Feld2

Feld3

Feld4

Feld5

Feld6

Feld7

Inhalt

154

Abbildung: Einige deaktivierte Felder in der Oberfläche 'Neues Telefonticket' als verpflichtendes Feld.

Beispiel 4.25. Aktiviert Feld1 in der TicketZoom-Oberfläche.

• Gruppe: Ticket

• Untergruppe: Frontend::Agent::Ticket::ViewZoom

• Einstellung: Ticket::Frontend::AgentTicketZoom###DynamicField

• Wert:

Schlüssel

Feld1

Inhalt

155

Abbildung: Feld1 in der TicketZoom-Oberfläche.

Beispiel 4.26. Aktiviert Feld1 in der kleinen Ticketübersicht.

• Gruppe: Ticket

• Untergruppe: Frontend::Agent::TicketOverview

• Einstellung: Ticket::Frontend::OverviewSmall###DynamicField

• Wert:

Schlüssel

Feld1

Inhalt

156

Abbildung: Feld1 in der kleinen Ticketübersicht.

Diese Einstellung betrifft: Eskalationsübersichten, Übersicht über gesperrte Tickets,

Queue-Übersichten, Übersicht über Verantwortlichkeiten, Status-Übersichten und Beobachten-Übersichten.

10.2.11. Setzen eines Standard-Wertes durch ein

TicketEvent-Module

Ein Ticket-Event (z.B.: TicketCreate) kann einen Wert für ein bestimmtes Feld triggern, wenn das Feld noch keinen Wert besitzt.

Anmerkung

Bei Verwendung dieser Methode ist der Standard-Wert nicht sichtbar in der Editieroberfläche (z.B.: Neues Telefonticket), weil der Wert nach der Erstellung des

Tickets gesetzt wird.

Um diese Funktion zu aktivieren ist es notwendig die folgende Einstellung zu aktivieren:

"Ticket::EventModulePost###TicketDynamicFieldDefault".

Beispiel 4.27. Aktiviert Feld1 im Event TicketCreate.

• Gruppe: Ticket

• Untergruppe: Core::TicketDynamicFieldDefault

• Einstellung: Ticket::TicketDynamicFieldDefault###Element1

Anmerkung

Diese Konfiguration kann in jeder der 16

Ticket::TicketDynamicFieldDefault###Element Einstellungen getätigt werden.

157

Werden mehr als 16 Felder benötigt, müssen Sie sich eine eigene XML erstellen und diese im Verzeichnis $OTRS_HOME/Kernel/Config/files ablegen, um dieses

Feature zu erweitern.

• Wert:

Schlüssel

Ereignis

Name

Wert

Inhalt

TicketCreate

Feld1

Ein neuer Wert

10.2.12. Setzt die Standard-Einstellung abhängig von den Benutzereinstellungen

Der Standardwert der dynamischen Felder kann mit einem benutzerspezifischen Wert, der in den Benutzereinstellungen definiert ist, überschrieben werden

Bei Verwendung, wird der Standardwert des Feldes in jeder Oberfläche angezeigt, in der das Feld aktiviert ist (solange das Feld nicht bereits einen unterschiedlichen Wert besitzt).

Die "Sysconfig"-Einstellung "PreferencesGroups###DynamicField"ist in der Untergruppe "Frontend::Agent::Preferences" zu finden. Diese Einstellung ist ein Beispiel, wie man einen Eintrag in den Benutzereinstellungen erstellt, um einen exklusiven Standardwert des dynamisches Feldes für den ausgewählten Benutzer zu setzen. Die Einschränkung dieser Einstellung ist, dass nur die Verwendung ein dynamischen Feldes erlaubt ist. Wenn zwei oder mehr Felder dieses Feature verwenden, ist es notwendig eine benutzerdefinierte XML-Konfigurationsdatei zu erstellen, um weitere ähnliche Einstellungen wie diese hinzu zufügen.

Anmerkung

Beachten Sie, wenn mehrere Einstellungen in einer neuen XML-Datei hinzugefügt werden, muss jeder Feldname eindeutig und ein anderer als in "PreferencesGroups###DynamicField" sein. Zum Beispiel: PreferencesGroups###101-DynamicField-Field1, PreferencesGroups###102-DynamicField-Field2, PreferencesGroups###My-Field1, PreferencesGroups###My-

Field2, etc.

Beispiel 4.28. Aktiviert Field1 in den Benutzereinstellungen

• Gruppe: Ticket

• Untergruppe: Frontend::Agent::Preferences

• Einstellung: PreferencesGroups###101-DynamicField-Field1

• Wert:

Schlüssel

Ereignis

Aktiv

Block

Spalte

Inhalt

TicketCreate

Eingabe

Andere Einstellungen

158

Schlüssel

Daten:

Schlüssel:

Beschriftung:

Modul:

PrefKey:

Priorität:

Inhalt

$Env{"UserDynamicField_Field1"}

Mein Feld 1

Standardwert für: Mein Feld 1

Kernel::Output::HTML::PreferencesGeneric

UserDynamicField_Field1

7000

Abildung: Feld1 in Benutzereinstellungen.

11. Generic Interface

The OTRS Generic Interface consists of a multiple layer framework that lets OTRS communicate with other systems via a web service. This communication could be bi-directional:

• OTRS as Provider: OTRS acts as a server listening to requests from the External System, processing the information, performing the requested action, and answering the request.

• OTRS as Requester: OTRS acts as a client collecting information, sending the request to the Remote System, and waiting for the response.

11.1. Generische Schnittstellenebenen

Generic Interface is build based on a layer model, to be flexible and easy to customize.

A layer is a set of files, which control how the Generic Interface performs different parts of a web service. Using the right configuration, one can build different web services for different External Systems without creating new modules.

159

Anmerkung

If the Remote System does not support the current bundled modules of the Generic

Interface, special modules need to be developed for that specific web service.

The list of provided Generic Interface modules shipped with OTRS will be updated and increased over time.

Abbildung: Die grafischen Interface Schichten.

11.1.1. Netzwerk-Transport

This layer is responsible for the correct communication with the Remote System. It receives requests and generates responses when acting as provider, and generates requests and receives responses when acting as requester.

Provider communication is handled by a new web server handle called "nphgenericinterface.pl".

Requester communication could be initiated during an event triggered by a Generic Interface module or any other OTRS module. This event is catched by the event handler and depending on the configuration the event will be processed directly by the requester object or delegated to the Scheduler (a separated deamon designed to process tasks asynchronously).

11.1.2. Daten-Mapping

This layer is responsible for translating data structures between OTRS and the Remote

System (data internal and data external layers). Usually Remote Systems have different data structures than OTRS (including different values and names for those values), and

160

here resides the importance of the layer to change the received information into something that OTRS can understand and on the opposite way send the information to each

Remote System using their data dictionaries.

Example: "Priority" (OTRS) might be called "Prio" in a remote system and it could be that value "1 Low" (OTRS) should be mapped to "Information" on the remote system.

11.1.3. Controller

Controllers are collections of similar Operations or Invokers. For example, a Ticket controller might contain several standard ticket operations. Custom controllers can be implemented, for example a "TicketExternalCompany" controller which may contain similar functions as the standard Ticket controller, but with a different data interface, or function names (to adapt to the Remote System function names) or complete different code.

One application for Generic Interface could be to synchronize information with one Remote System that only can talk with another Remote System of the same kind. In this case new controllers needs to be developed and the Operations and Invokers has to emulate the Remote System behavior in such way that the interface that OTRS exposes is similar to the Remote System's interface.

11.1.4. Operation (OTRS als Provider)

An Operation is a single action that can be performed within OTRS. All operations have the same programming interface, they receive the data into one specific parameter, and return a data structure with a success status, potential error message and returning data.

Normally operations uses the already mapped data (internal) to call core modules and perform actions in OTRS like: Create a Ticket, Update a User, Invalidate a Queue, Send a

Notification, etc. An operation has full access to the OTRS API to perform the action.

11.1.5. Invoker (OTRS als Requester)

An Invoker is an action that OTRS performs against a Remote System. Invokers use the

OTRS Core modules to process and collect the needed information to create the request.

When the information is ready it has to be mapped to the Remote System format in order to be sent to the Remote System, that will process the information execute the action and send the response back, to either process the success or handle errors.

11.2. Generic Interface Kommunikationsfluss

Das Generic Interface hat einen definierten Fluss um Aktionen als Provider und Requester auszuführen.

Diese Flüsse sind wie folgt beschrieben:

11.2.1. OTRS als Provider

11.2.1.1. Entfernte Anfrage:

1. HTTP-Anfrage

• OTRS empfängt HTTP-Anfragen und leitet sie durch die verschiedenen Schichten weiter.

• Die Provider-Modul ist für die Ausführung und Kontrolle dieser Maßnahmen vorhanden.

2. Netzwerk-Transport

161

• Das Netzwerktransportmodul dekodiert den Daten-Payload und trennt den Operationsnamen aus dem Rest der Daten.

• Der Operationsname und die Betriebsdaten werden an den Provider zurückgegeben

3. externe Daten

• Daten die vom Remote-System gesendet wurden (Das ist kein Modulbasierter Layer).

4. Mapping

• Die Daten wird aus dem Fremdsystem-Format in das interne OTRS Format, wie in der

Mapping-Konfiguration für diesen Vorgang (Mapping für eingehende Anforderungsdaten) spezifiziert, umgewandelt.

• Die bereits transformierten Daten werden an den Provider zurückgegeben.

5. interne Daten

• Sobald die Daten, transformiert und aufbereitet wurden, werden diese an die Operation weitergeleitet. (Das ist kein Modulbasierter Layer).

6. Operation

• Empfängt und prüft Daten

• Führt eine Benutzerzugangskontrolle durch.

• Führt die Aktion aus.

11.2.1.2. OTRS-Antwort:

1. Operation

• Liefert das Ergebnis an den Provider.

2. interne Daten

• Von der Operation zurückgegebene Daten.

3. Mapping

• The data is transformed back to the Remote system format as specified in the mapping configuration (Mapping for outgoing response data).

• Die bereits transformierten Daten werden an den Provider zurückgegeben.

4. externe Daten

• Data as transformed and prepared to be passed to Network Transport as response.

5. Netzwerk-Transport

• Empfängt die Daten im Format des Remote-Systems.

• Constructs a valid response for this network transport type.

6. HTTP-Antwort

• The response is sent back to the web service client.

• In the case of an error, an error response is sent to the remote system (e.g. SOAP fault, HTTP error, etc).

162

11.2.2. OTRS als Requester

11.2.2.1. OTRS Anfrage:

1. Event-Trigger-Steuerungsprogramm

• Basierend auf der Konfiguration des Webservices wird entschieden ob der Request synchron oder asynchron ist.

• synchron

• A direct call to the Requester is made in order to create a new request and to pass it through the layers.

• asynchron

• Create a new Generic Interface (Requester) task for the OTRS Scheduler (by delegating the request execution to the Scheduler, the user experience could be highly improved, otherwise all the time needed to prepare the request and the remote execution will be added to the OTRS Events that trigger those requests).

• In its next cycle the Scheduler process reads the new task and creates a call to the

Requester that will create a new request and then passes it through the layers.

2. Invoker

• Empfängt Daten von dem Event.

• Überprüft empfangene Daten (wenn benötigt).

• Call core modules to complement the data (if needed).

• Return the request data structure or send a Stop Communication signal to the requester, to gracefully cancel the request.

3. interne Daten

• Data as passed from the invoker (This is not a module based layer).

4. Mapping

• The data is transformed to the Remote system format as specified in the mapping configuration (Mapping for outgoing response data).

• The already transformed data is returned to the requester.

5. externe Daten

• Data as transformed and prepared for sending to the remote system.

6. Netzwerk-Transport

• Receives the remote operation name and the data already transformed to the Remote

System format from the requester.

• Konstruiert eine gültige Anfrage für die Netzwerkübertragung.

• Sendet die Anfrage zum Remote-System und wartet auf eine Antwort

11.2.2.2. Remote Antwort:

1. Netzwerkübertragung

163

• Empfängt die Antwort und dekodiert den Daten-Payload.

• Sendet die Daten zurück zu dem Requester.

2. externe Daten

• Daten, die vom Remote-System empfangen wurden

3. Mapping

• Die Daten wird aus dem Fremdsystem-Format in das interne OTRS Format, wie in der

Mapping-Konfiguration für diesen Vorgang (Mapping für eingehende Anforderungsdaten) spezifiziert, umgewandelt.

• The already transformed data is returned to the requester.

4. interne Daten

• Sobald die Daten, transformiert und aufbereitet wurden, werden diese an die Requester zurückgeschickt.

5. Invoker

• Empfängt die zurückgegebenen Daten.

• Verarbeitet die Daten als speziell von jedem Invoker benötigt werden (inklusive Fehlerbehandlung falls vorhanden).

• Gibt das Ergebnis und die Daten des Invokers an den Requester.

6. Event-Steuerungsprogramm oder Scheduler

• Empfängt die Daten vom Requester, im Falle des Schedulers beinhalten die Daten

Informationen darüber ob der Task sofort oder in der Zukunft wieder ausgeführt werden soll.

11.3. Web-Services

A Web Service is a communication method between two systems, in our case OTRS and a Remote System.

The heart of the Web Service is its configuration, where it is defined what actions the web service can perform internally (Operation), what actions the OTRS request can perform

Remote System (Invokers), how data is converted from one system to the other (Mapping), and over which protocol the communication will take place (Transport)

The Generic Interface is the framework that makes it possible to create Web Services for

OTRS in a pre-defined way, using already made building blocks that are independent from each other and interchangeable.

11.4. Web Service - Grafische Oberfläche

Die grafische Benutzeroberfläche (GUI) des Webservice ist ein Werkzeug, dass es erlaubt komplexe Webservice-Konfigurationen mit einer benutzerfreundlichen und komfortablen

Oberfläche zu erstellen. Es erlaubt folgendes:

• Erstellen und Löschen von Webservices

• Importieren und Exportieren von Konfigurationen (im YAML Dateiformat) für existierende Webservices.

164

• Zeige, exportiere und setze alte Konfigurationen für existierende Webservices in der

Web Service History - Anzeige zurück.

• Verfolge alle Kommunikations-Protokolle für alle Webservices in der Debugger-Anzeige.

11.4.1. Webservice-Übersicht

Der "Web-Services"-Link im Hauptbildschirm der Admin-Oberfläche (in der "System Administration"-Box) führt zum Webservices-Überblick-Bildschirm, wo alle Webservice-Konfigurationen verwaltet werden können. Neue Webservices können hinzugefügt oder schon vorhandene Konfigurationen geändert werden.

Jede Webservice-Konfigurationsanzeige hat im oberen Teil des Bildschirms einen Navigationspfad im "Brotkrumen"-Stil. Dieser Navigationspfad ist nützlich um genau zu wissen, in welchem Teil der Webservice-Konfiguration man sich befindet und erlaubt dem Nutzer jederzeit zu irgendeinem Teil des Konfigurationsprozesses zurückzuspringen (jegliche

Änderungen werden nicht gespeichert).

Anmerkung

Drücken Sie den Knopf "Webservice hinzufügen" um einen neuen Webservice zu erstellen, und geben Sie die erforderlichen Informationen an.

Abbildung: Überblick Webservices

11.4.2. Webservice hinzufügen

The only required field in this part is the web service "Name" that needs to be unique in the system and can not be left empty. Other fields are also necessary for the configuration like the "Debug Threshold" and "Validity" but these fields are already populated with the default value for each list.

165

The default value for "Debug Threshold" is "debug". When configured in this manner all communication logs are registered in the database. Each subsequent Debug Threshold value is more restrictive and discards communication logs of lower order than the one set in the system.

Schwellenwerte der Fehlersuche (von niedrig nach hoch)

• Fehlersuche

• Info

• Notiz

• Error

Es ist ebenfalls möglich das Netzwerkübertragungsprotokoll für "OTRS als Provider" und

"OTRS als Requester" zu definieren.

Klicken Sie auf "Speichern" um den neuen Webservice in der Datenbank zu registrieren oder klicken Sie auf "Abbrechen" um die Änderungen zu verwerfen. Anschließend werden

Sie auf die Übersichtsseite der Webservices weitergeleitet.

Wenn Sie bereits eine Webservice Konfigurationsdatei im YAML Format haben, können sie auf der linken Seite den "Webservice importieren"-Button klicken. Weitere Informationen

über das importieren von Werbservices finden Sie im nächsten Abschnitt "Webservice

ändern".

Anmerkung

To change or add more details to a web service, click on the web service name in the web service overview screen.

Abbildung: Webservice hinzufügen.

166

11.4.3. Webservice ändern

On this screen you have a complete set of functions to handle every part of a web service.

On the left side in the action column you can find some buttons that allows you to perform all possible actions on a web service:

• Webservice kopieren

• Webservice exportieren

• Webservice importieren.

• Konfigurationschronik.

• Webservice löschen

• Debugger.

Anmerkung

"Configuration history" and "Debugger" will lead you to different screens.

11.4.3.1. Webservice kopieren

To clone a web service, you need to click on the "Clone web service" button. A dialog will be shown where you can use the default name or set a new name for the (cloned) web service.

Anmerkung

Remember that the name of the web service must be unique within the system.

Click on "Clone" button to create the web service clone or "Cancel" to close the dialog.

167

Abbildung: Webservice kopieren.

11.4.3.2. Webservice exportieren

The "Export web service" button gives you the opportunity to dump the configuration of the current web service into a YAML file, to download it and to store it on your file system.

This can be specially useful if you want to migrate the web service from one server to another, for example from a testing environment to a production system.

Warnung

Alle in der Webservice-Konfiguration gespeicherten Passwörter werden im Klartext exportiert.

Right after clicking the "Export web service" button a save dialog of your browser will appear, just like when you click on a file download link on a web page.

Anmerkung

Jeder Browser auf den verschiedenen Betriebssystemen hat seinen eigenen Speicher-Dialog und -Stil. Je nachdem welcher Browser mit welcher Konfiguration vorhanden ist, kann es sein, dass überhaupt kein Dialog angezeigt wird und die Datei direkt im Standard-Verzeichnis auf Ihrem Dateisystem gespeichert wird. Bitte überprüfen Sie Ihre Browser-Anleitung wenn Sie genauere Anweisungen benötigen.

Abbildung: Webservice exportieren.

11.4.3.3. Webservice importieren

A valid web service configuration YAML file is required to use the import web service feature. Click on the "Import web service" button, browse for the configuration file or provide the complete path in the input box.

168

Click "Import" button to create a new web service from a file or "Cancel" to close the dialog.

Anmerkung

The web service name will be taken from the configuration file name (e.g. if the file name is MyWebservice.yml the resulting web service will be named MyWebservice). If a web service is registered in the system with the same name as the web service that you want to import, the system will lead you to the web service change screen to let you change the name of the imported web service.

Abbildung: Webservice importieren.

11.4.3.4. Webservice Historie

Every change to the web service configuration creates a new entry in the web service history (as a journal). The web service history screen displays a list of all configuration versions for a web service. Each row (version) in the "Configuration History List" represents a single revision in the web service history.

Click on one of the rows to show the whole configuration as it was on that particular date / time. The configuration will be shown in the "History details" section of this screen. Here you are also able to export the selected web service configuration version or to restore that version into the current web service configuration.

The "Export web service configuration" behaves exactly as the "Export web service" feature in the web service change screen. For more information refer to that section.

If changes to the current web service configuration do not work as expected and it is not easy to revert the changes manually, you can click on the "Revert web service configuration" button. This will open a dialog to ask you if you are sure to revert the web service

169

configuration. Click "Revert web service configuration" in this dialog to replace the current configuration with the selected version, or click "Cancel" to close the dialog.

Warnung

Remember that any passwords stored in the web service configuration will be exported in plain text format.

Bitte seien Sie vorsichtig, wenn Sie eine Konfiguration wiederherstellen, dieser

Prozess ist unumkehrbar.

Abbildung: Webservice Historie.

11.4.3.5. Webservice löschen

Sometimes it is necessary to delete a web service completely. To do this you can press on the "Delete web service" button and a new dialog will appear asking for confirmation.

Click on "Delete" to confirm the removal of the web service or on "Cancel" to close the dialog.

Warnung

Deleting a web service can't be undone, please be careful when deleting a web service.

170

Abbildung: Webservice löschen.

11.4.3.6. Webservice Debugger

The Debugger stores the log of a web service. In the debugger screen you can track all the web service communications for either provider or requester types.

When this screen is shown the request list starts to load. After the list is fully filled you can choose one of the rows (that means a communication sequence) to check its details.

This details will appear in a box below.

You can narrow the communication list using the filter on the right part of the screen.

You can filter by:

• Kommunikationstyp (Provider oder Requester)

• Date: before and / or after a particular date

• Die Remote-IP-Adresse

• Eine Kombination von allem.

After filter settings are set, push the "Refresh" button and a new list will be displayed meeting your search criteria.

Anmerkung

Depending on the search criteria for the filters the new list could return no results.

On the left part of the screen under the action column you can select "Go back to the web service" or clear the debugger log by pushing the "Clear" button. This will open a dialog that ask you to confirm erasing of the log. Click "Clear" in the dialog button to perform the action or click on "Cancel" to close this dialog.

171

In the "Request details" section you can see all the details for the selected communication.

Here you can track the complete flow and check for possible errors or confirm success responses.

Abbildung: Webservice Debugger.

11.4.3.7. Ändern der Webservice Konfiguration

Returning to the web service change screen, now we are going to review the right side of it. Here we have the possibility to modify all the general data for a web service such as name, description, debug threshold, etc. Also there are two more sections below that allows us to modify specific parameters for communication types "OTRS as Provider" and

"OTRS as Requester".

The web service configuration needs to be saved on each level. This means that if a setting is changed, links to other, deeper parts of the configuration will be disabled forcing you to save the current configuration level. After saving the disabled links will be re-enabled again allowing you to continue with the configuration.

On the "OTRS as provider" section it is possible to set or configure the network transport protocol. Only network transport back-ends that are registered are shown on the list. To configure the network transport click on the "Configure" button. It is also possible to add new operations in this box. To do this select one of the available operations from the "Add

Operation" list. This will lead you to the operation configuration screen. After saving the new operation it will be listed in the table above.

"OTRS as requester" is very similar to the previous one, but instead of "operations" you can add invokers here.

Click the "Save" button to save and continue configuring the web service, "Save and finish" to save and return to the web service overview screen, or "Cancel" to discard current configuration level changes and return to web service overview screen.

172

Abbildung: Webservice ändern.

Anmerkung

Like the other Generic Interface configuration screens such as Network Transport,

Operation, Invoker and Mapping, the initial configuration (add) screen will only present two options: "Save" and "Cancel". If the configuration is re-visited, a new option "Save and Finish" will appear. The behavior of this feature is defined below.

"Save" will store the current configuration level in the database and it will return to the previous screen to review your changes or to configure deeper settings.

"Save and Finish" will store the current configuration level in the database and it will return to the previous screen in the configuration hierarchy (to the immediate upper configuration level).

"Cancel" will discard any configuration change to the current configuration level and will return to the previous screen in the configuration hierarchy.

11.4.3.7.1. Webservice Requester Übertragung

In future the list of available network transports will be increased. Currently only the

"HTTP::SOAP" transport is available. Each transport has different configuration options to setup and they might use different frontend modules to configure it, but mostly they should look similar to the "HTTP::SOAP" transport configuration module.

173

It is quite simple to configure the "HTTP::SOAP" protocol as provider. There are only two settings: "Namespace" and "Maximum message length". These fields are required. The first one is a URI to give SOAP methods a context, reducing ambiguities, and the second one is a field where you can specify the maximum size (in bytes) for SOAP messages that

OTRS will process.

Abbildung: Webservice Provider Übertragung.

11.4.3.7.2. Webservice-Operation

The actions that can be performed when you are using OTRS as a provider are called

"Operations". Each operation belongs to a controller. Controllers are collections of operations or invokers, normally operations from the same controller need similar settings and share the same configuration dialog. But each operation can have independent configuration dialogues if needed.

Name, Description, Backend, and Mappings are fields that normally appear on every operation, other special fields can appear in non default configuration dialogues to fulfill specific needs of the operation.

Normalerweise gibt es zwei Mapping-Konfigurationsabteilungen bei jeder Operation, eine für die ankommenden Daten und eine für die ausgehenden Daten. Sie können verschiedene Mapping-Arten (Backends) für jede Mapping-Richtung auswählen, da deren Konfiguration unabhängig voneinander und unabhängig vom Operations-Backend ist. Die normale und am meisten übliche Praxis ist es, dass die Operation in beiden Fällen die gleiche

Mapping-Art nutzt (mit umgekehrter Konfiguration). Die komplette Mapping-Konfiguration wird in einer extra Anzeige, die auf die Mapping-Art drauf ankommt, gemacht.

The operation backend is pre-populated and is not editable. You will see this parameter when you choose the operation on the web service edit screen. The field is only informative.

174

Im linken Teil der Anzeige in der Aktionen-Spalte haben Sie die Optionen: "Gehe zurück zum Webservice" (alle Änderungen seit dem letzten Speichern werden verworfen) und

"Löschen". Wenn Sie letzteres wählen wird sich ein Dialogfenster öffnen, in dem Sie das

Löschen der Operation bestätigen sollen. Klicken Sie auf "Löschen" um die Entfernung der

Operation und ihrer Konfiguration zu bestätigen oder "Abbrechen" um den Lösch-Dialog zu schließen.

Abbildung: Webservice Operation.

11.4.3.7.3. Webservice Requester Übertragung

The network transport configuration for the requester is similar to the configuration for the provider. For the Requester "HTTP::SOAP" network transport there are more fields to be set.

Apart from the "Endpoint" (URI of the Remote System web service interface to accept requests) and "Namespace" which are required fields, you can also specify:

• Verschlüsselung (z. B. utf-8, latin1, iso-8859-1, cp1250, usw.) für die SOAP-Nachricht.

• SOAPAction Header: you can use this to send an empty or filled SOAPAction header. Set to "No" and the SOAPAction header on the SOAP message will be an empty string, or set to "Yes" to send the soap action in Namespace#Action format and define the separator

(typically "/" for .Net web services and "#" for the rest).

• Authentication: to set the authentication mechanism, set to "-" to not use any authentication or select one from the list and the detail fields will appear.

Anmerkung

Currently only the "BasicAuth" (HTTP) authentication mechanism is implemented.

You can decide whether or not to use it depending on the Remote System confi-

175

guration. If used, you must provide the User Name and the Password to access the remote system.

Warnung

If you supply a password for authentication and after you export the web service to a YAML file this password will be revealed and will be written into a plain text string inside the YAML file. Be aware of it and take precautions if needed.

Abbildung: Webservice Requester Übertragung.

11.4.3.7.4. Webservice Invoker

The actions that can be performed when you are using OTRS as a requester are called

"Invokers". Each invoker belongs to a controller (controllers are collections of operations or invokers). Usually invokers from the same controller need similar settings and share the same configuration dialogues. Each invoker can have independent configuration dialogues if needed.

Name, Description, Backend, and Mappings are fields that normally appear on every invoker. Additionally the list of event triggers and other special fields can appear on non default configuration dialogues to fulfill special needs of the invoker.

Normally there are two mapping configuration sections for each invoker, one for the incoming data and another one for the outgoing data. You can choose different mapping types

(backends) for each mapping direction, since their configuration is independent from each other and also independent from the invoker backend. The normal and most common practice is that the invoker uses the same mapping type in both cases, with inverted configuration. The complete mapping configuration is done in a separate screen, which depends on the mapping type.

176

The invoker backend is pre-populated and can not be edited. You will see this parameter when you choose the invoker on the web service edit screen. The field is only informative.

Event triggers are events within OTRS such as "TicketCreate", "ArticleSend", etc. These can act as triggers to execute the invoker. Each invoker needs to have at least one event trigger registered, or the invoker will be useless, because it will never be called. The asynchronous property of the event triggers define if the OTRS process will handle the invoker or if it will be delegated to the Scheduler.

Anmerkung

The OTRS Scheduler is a separate process that executes tasks in the background.

Using this the OTRS process itself will not be affected if the Remote System takes a long time to respond, if it is not available or if there are network problems. If you don't use the scheduler using web services can make OTRS slow or non-responsive.

Therefore it is highly recommend to use asynchronous event triggers as often as possible.

To add an Event trigger, first select the event family from the first list, then the event name from the second list, then set the asynchronous property (if unchecked means that the event trigger will not be asynchronous) and finally click on the plus button. A new event trigger will be created and it will be listed on the invoker "Event Triggers" list.

To delete an Event trigger, simply locate the event trigger to be deleted in the "Event

Triggers" list and click on the trash icon at the end of the row. This will open a dialog that asks you if you are sure to delete the event trigger. Click "Delete" to remove the event trigger from the list, or "Cancel" to close the dialog.

In the left part of the screen on the action column you have the options: "Go back to web service" (discarding all changes since the last save) and "Delete". If you click on the last one, a dialog will emerge and ask you if you like to remove the invoker. Click on the

"Delete" button to confirm the removal of the invoker and its configuration or "Cancel" to close the delete dialog.

177

Abbildung: Webservice Invoker.

11.4.3.7.5. Webservice Mapping

There are cases where you need to transform the data from one format to another (map or change data structure), because normally a web service is used to interact with a

Remote System, that is highly probable that is not another OTRS system and / or could not understand the OTRS data structures and values. In these cases some or all values have to be changed, and sometimes even the names of the values (keys) or even the complete structure, in order to match with the expected data on the other end. To accomplish this task the Generic Interface Mapping Layer exists.

Each Remote System has it own data structures and it is possible to create new mapping modules for each case (e.g. there is a customized mapping module for SAP Solution

Manager shipped with OTRS), but it is not always necessary. The module Mapping::Simple should cover most of the mapping needs.

Anmerkung

When Mapping::Simple does not cover all mapping needs for a web service, a new mapping module should be created. To learn more about how to create new mapping modules please consult the OTRS Development Manual.

This module gives you the opportunity to set default values to map for each key or value for the whole communication data.

At the beginning of the screen you will see a general section where you can set the default rules that will apply for all the unmapped keys and values. There are three options available, these options are listed below:

• Keep (leave unchanged): doesn't touch the keys or values in any way.

178

• Ignore (drop key/value pair): when this is applied to the key it deletes the key and value, because when a key is deleted then in consequence its associated value is deleted too.

When this is applied to the value, only the value is deleted, keeping the key, that now will be associated to an empty value.

• MapTo (use provided key or value as default): all keys and / or values without a defined map rule, will use this as default, when you select this option a new text field will appear to set this default.

Clicking on the "+" button for new key map, will display a new box for a single mapping configuration. You can add as many key mappings as needed. Just click on the "+" button again and a new mapping box will appear below the existing one. From this mapping boxes you can define a map for a single key, with the next options:

• Exact value(s): the old key string will be changed to a new one if the old key matches exactly.

• Regular expression: The key string will be replaced following a regular expression rule.

Pressing the new value map "+" button will display a new row for a value map. Here it is also possible to define rules for each value to be mapped with the same options as for the key map (Exact value and Regular expression). You can add as many values to map as needed, and if you want to delete one of them, just click on the "-" button for each mapping value row.

Deleting the complete key mapping section (box) is possible, just push on the "-" button located on the up right corner of each box that you want to delete.

If you need to delete a complete mapping configuration: go back to the corresponding operation or invoker screen, look for the mapping direction that you select before and set its value to "-", and save the configuration to apply changes.

179

Abbildung: Webservice-Mapping.

11.5. Webdienst-Befehlszeilenoberfläche

The Command Line Interface (CLI) is a fast way to work with the web services. It consists of a set of tools that can be use to perform basic operations like:

• Create, Update, Read, List and Delete web services based on YAML files.

• Lesen der Debugger-Logdatei, mit gesetzten Filtern.

Anmerkung

You don't need to use the CLI to work with web services. Integrated into the Admin interface there is a complete set of screens to interact with every part of the web services. Please read the web service GUI section included in this manual.

11.5.1. Webservice Konfiguration

The "WebserviceConfig.pl" was developed in order to create basic, but fast and powerful tool to work with web service configurations. It gives you the ability to perform the following actions:

• Add: Um einen Webservice mit einer YAML-Datei als Konfigurationsquelle zu erstellen.

• Update: to change an existing web service, the configuration can be changed using a different or modified YAML file.

• Read: to get the current web service configuration displayed on the screen.

• List: to get a complete list of all the web services registered in system.

• Delete: to delete a web service from the system. Be careful when you use it, because this action can't be undone.

Warnung

A web service READ operation will display all the configuration as plain text on the screen, including any stored passwords. Please be aware of this and take the needed precautions!

Beispiel: Eine neue Webservice-Konfiguration erstellen: shell> OTRS_HOME/bin/otrs.WebserviceConfig.pl -a write -n <webservice_name> -f /pfad/zur/ yaml/datei

Ebenso können Sie 'otrs.WebserviceConfig.pl' mit den folgenden Optionen benutzen:

• -a read -i <webservice_id> - um eine gespeicherte Konfiguration einzulesen.

• -a write -n <webservice_name> -f /path/to/yaml/file - um einen neuen Webservice zu erstellen.

• -a write -i <webservice_id> -f /path/to/yaml/file - um einen Webservice upzudaten.

• -a list - um alle verfügbaren Webservices anzuzeigen.

• -a delete -i <webservice_id> - Um einen Webservice zu löschen.

180

11.5.2. Webservice Debugger

Another available tool via the command line interface is the

"otrs.GenericInterfaceDebugRead.pl" script, which is an interface to search for web service debugger log entries.

Beispiel: Suche nach Debugger-Logeinträgen:

shell> bin/otrs.GenericInterfaceDebugRead.pl

Optional parameters can be used for the "otrs.GenericInterfaceDebugRead.pl" script:

• -c - Um nach der Kommunikations-ID zu filtern (md5sum-Format).

• -t - Um nach dem Kommunikationstyp zu filtern ('Provider' or 'Requester').

• -a - Um nach einem Datum zu filtern ('bestimmtes Datum' oder 'Nach einem bestimmten Datum').

• -b - Um nach einem Datum zu filtern ('bestimmtes Datum' oder 'Vor einem bestimmten

Datum').

• -i - Um nach einer IP-Adresse zu filtern (muss eine gültige IPv4 oder IPv6 Adresse sein).

• -w - Um nach der Webservice ID zu filtern.

• -d - Um die detailierten Kommunikationsdaten anzufügen.

Beispiel: Suche nach Debugger-Logeinträgen mit allen Parametern:

shell> ./otrs.GenericInterfaceDebugRead.pl -c a7cc4d9f5c70387a9bfbe1351bc88966 -t Provider

-a '2011-07-22 00:00:00' -b '2011-07-26 00:00:00' -i 127.0.0.1 -w 123 -d 1

Anmerkung

It is highly recommended to include at least one of the filter options listed above, and even more if the "-d" option is selected, because a lot of information can be retrieved from the data base and displayed on the screen, this could result in slow response times and much more information than what you really needed.

11.6. Webservice Konfiguration

From its design the web services were conceived to be portable from one OTRS system to another, e.g. from a test or development environment to a production system. Therefore it was needed to have an easy way to extract the web service configuration from the database, and import it to another. To accomplish this task the Generic Interface uses

YAML files as the web services configuration basis.

Why YAML? YAML is a markup language designed to be human friendly to read and write

(it is easier to understand than JSON), it does not have some of the limitations of XML like numeric tags, it is open, standardized, and is complete enough to store the whole web service configuration.

Anmerkung

To learn more about YAML please visit http://www.yaml.org/ .

181

The following is a web service configuration file example in YAML format:

---

Debugger:

DebugThreshold: debug

Description: This an example of a web service configuration

Provider:

Operation:

CloseIncident:

Description: This is a test operation

MappingInbound: {}

MappingOutbound: {}

RemoteSystemGuid: ''

Type: Test::Test

Test:

Description: This is a test operation

MappingInbound:

Config:

KeyMapDefault:

MapTo: ''

MapType: Keep

KeyMapExact:

Prio: Priority

ValueMap:

Priority:

ValueMapExact:

Critical: 5 Very High

Information: 1 Very Low

Warning: 3 Normal

ValueMapDefault:

MapTo: 3 Normal

MapType: MapTo

Type: Simple

MappingOutbound:

Config:

KeyMapDefault:

MapTo: ''

MapType: Ignore

KeyMapExact:

Priority: Prio

ValueMap:

Prio:

ValueMapExact:

1 Very Low: Information

3 Normal: Warning

5 Very High: Critical

ValueMapDefault:

MapTo: ''

MapType: Ignore

Type: Simple

Type: Test::Test

Transport:

Config:

MaxLength: 10000000

NameSpace: http://www.example.com/actions

Type: HTTP::SOAP

RemoteSystem: remote.system.description.example.com

Requester:

Invoker:

Test:

Description: This is a test invoker

Events:

- Asynchronous: 1

Event: TicketCreate

- Asynchronous: 0

Event: ArticleUpdate

MappingInbound:

Type: Simple

MappingOutbound:

Type: Simple

Type: Test::Test

182

Transport:

Config:

Authentication:

Password: '*******'

Type: BasicAuth

User: otrs

Encoding: utf-8

Endpoint: http://www.example.com:8080/endpoint

NameSpace: http://www.example.com/actions

SOAPAction: Yes

SOAPActionSeparator: '#'

Type: HTTP::SOAP

11.6.1. Konfigurationsdetails

11.6.1.1. Allgemein

• Beschreibung: ein kurzer Text, der den Webservice beschreibt.

• RemoteSystem: eine kurze Beschreibung des Remote-Systems.

• Debugger: ein Behälter für die Debugger-Einstellungen.

• Provider: ein Behälter für die Anbieter-Einstellungen.

• Requester: ein Behälter für die Anforderer-Einstellungen.

11.6.1.2. Debugger

• DebugThreshold: das Debugger-Level

mögliche Werte

• debug: alle Protokolle werden in der Datenbank gespeichert.

• info: info, notice und error level - Protokolle werden in der Datenbank gespeichert.

• notice: notice und error level - Protokolle werden in der Datenbank gespeichert.

• error: nur error level - Protokolle werden in der Datenbank gespeichert.

11.6.1.3. Provider

• Operation: ein Behälter für alle Operations-Einstellungen.

• Transport: ein Behälter für Provider-Netzwerk-Transport-Einstellungen.

11.6.1.3.1. Operation

• <OperationName>: eindeutiger Name für die Operation, eigener Container für eigene

Operationseinstellungen (Kardinalität 0 ..n, aber nicht mehrfach).

11.6.1.3.1.1. <Operationsname>

Dieser Abschnitt basiert auf Operationen vom Typ "Test::Test" andere Operationen können unterschiedliche Einstellungen beinhalten.

• Beschreibung: ein kurzer Text, der die Operation beschreibt.

• MappingInbound: Ein Container für die Mapping-Einstellung für eingehende Anfragen.

• MappingOutbound: Ein Container für die Mapping-Einstellung für ausgehende Anfragen.

• Type: Das Operation-Backend, im Format Controller::Operation.

183

11.6.1.3.1.1.1. eingehendes Mapping

Dieser Abschnitt basiert auf Mappings vom Typ "Simple". Andere Mappings können eventuell mehr oder andere Einstellungen beinhalten.

• Config: Ein Container für diese Mapping-Einstellungen.

• Type: Das Mapping-Backend.

11.6.1.3.1.1.1.1. Konfiguration

• KeyMapDefault: Ein Container für alle nicht gemappten Key-Einstellungen.

• ValueMapDefault: Ein Container für alle nicht gemappten Wert-Einstellungen.

• KeyMapExact: Ein Container für alle exakten Key-Mappings (Kardinalität 0 .. 1).

• KeyMapRegEx: Ein Container für alle regulären Regular Expression Key-Mappings (Kardinalität 0 .. 1).

• ValueMap: Ein Contanier für alle Werte-Mappings (Kardinalität 0 .. 1).

11.6.1.3.1.1.1.1.1. KeyMapDefault

• MapTo: Der neue Wert welcher benutzt werden soll (nur anwendbar wenn der MapType auf MapTo gesetzt ist).

• MapType: Die Regel für das Mapping.

mögliche Werte

• Keep: unverändert lassen.

• Ignore: verwerfen.

• MapTo: Ändern auf den MapTo-Wert.

11.6.1.3.1.1.1.1.2. ValueMapDefault

Ähnlich zu KeyMapDefault.

11.6.1.3.1.1.1.1.3. KeyMapExact

• <alterKey>: <neuerKey> (Kardinalität 0 .. n aber nicht mehrfach).

11.6.1.3.1.1.1.1.4. KeyMapRegEx

• <oldkey(RegEx)>: <newkey> ( Kardinalität 0 .. n, aber nicht mehrfach).

11.6.1.3.1.1.1.1.5. ValueMap

• <newkey>: Ein Container für das Werte-Mapping für diesen neuen Key (Kardinalität hängt von den neuen Keys aus KeyMapExact und KeyMapRegEx ab).

11.6.1.3.1.1.1.1.5.1. <newkey>

• ValueMapExact: Ein Container für alle exakten Werte-Mappings (Kardinalität 0 .. 1).

• ValueMapRegEx: Ein Container für alle Regular Expression Werte-Mappings (Kardinalität

0 .. 1).

11.6.1.3.1.1.1.1.5.1.1. valueMapExact

• <oldvalue>: <newvalue> ( Kardinalität 0 .. n, aber nicht mehrfach).

184

11.6.1.3.1.1.1.1.5.1.2. ValueMapRegEx

• <oldvalue(RegEx)>: <newvalue> (Kardinalität 0 .. n, aber nicht mehrfach).

11.6.1.3.1.1.2. ausgehendes Mapping

Das gleiche wie beim eingehenden Mapping

11.6.1.3.1.1.3. Transport

Dieser Abschnitt basiert auf Provider-Übertragungsart HTTP::SOAP, andere Übertragungsarten können unterschiedliche Einstellungen beinhalten.

• Config: Ein Container für die spezifischen Netzwerk-Transport-Einstellungen.

• Type: Netzwerk-Transport-Backend des Providers.

11.6.1.3.1.1.3.1. Konfiguration

• MaxLength: Die maximale Länge in Bytes die in SOAP-Nachrichten von OTRS gelesen werden.

• NameSpace: eine URI die eine Zusammenfassung aller möglichen Operationen liefert, die zu diesem Webservice gehören.

11.6.1.4. Requester

• Invoker: ein Container für jede 'Invoker'-Einstellung.

• Transport: ein Container für Netzwerk-Transport-Einstellungen für Requester.

11.6.1.4.1. Invoker

• <InvokerName>: eindeutiger Name für den Invoker, Container für eigene Invoker-Einstellungen (Kardinalität 0..n, aber nicht mehrfach).

11.6.1.4.1.1. <InvokerName>

Dieser Abschnitt basiert auf Invoker vom Typ "Test::Test" andere Operationen können unterschiedliche Einstellungen beinhalten.

• Beschreibung: ein kurzer Text, der den Aufrufer beschreibt

• Events: ein Container für Eventtrigger-Einstellungen, die keinen Namen besitzen.

• MappingInbound: Ein Container für die Mapping-Einstellung für eingehende Anfragen.

• MappingOutbound: Ein Container für die Mapping-Einstellung für ausgehende Anfragen.

• Type: Das Invoker-Backend, im Format Controller::Invoker

11.6.1.4.1.1.1. Ereignisse

• Auflistung der Elemente: (Kardinalität 0 .. n)

• Asynchron: bestimmt ob die Invoker-Ausführung an den Scheduler delegiert werden

mögliche Werte

• 0: nicht vom Scheduler verarbeitet

• 1: vom Scheduler verarbeitet.

• Event: Der Name des Event-Triggers.

185

Mögliche Werte (für TicketEvents)

• TicketCreate

• TicketDelete

• TicketTitleUpdate

• TicketUnlockTimeoutUpdate

• TicketQueueUpdate

• TicketTypeUpdate

• TicketServiceUpdate

• TicketSLAUpdate

• TicketCustomerUpdate

• TicketFreeTextUpdate

• TicketFreeTimeUpdate

• TicketPendingTimeUpdate

• TicketLockUpdate

• TicketArchiveFlagUpdate

• TicketStateUpdate

• TicketOwnerUpdate

• TicketResponsibleUpdate

• TicketPriorityUpdate

• HistoryAdd

• HistoryDelete

• TicketAccountTime

• TicketMerge

• TicketSubscribe

• TicketUnsubscribe

• TicketFlagSet

• TicketFlagDelete

• TicketSlaveLinkAdd

• TicketSlaveLinkDelete

• TicketMasterLinkDelete

186

Mögliche Werte (für Artikel-Events)

• Article Events

• ArticleCreate

• ArticleFreeTextUpdate

• ArticleUpdate

• ArticleSend

• ArticleBounce

• ArticleAgentNotification

• ArticleCustomerNotification

• ArticleAutoResponse

• ArticleFlagSet

• ArticleFlagDelete

• ArticleAgentNotification

• ArticleCustomerNotification

11.6.1.4.1.1.2. eingehendes Mapping

Das gleiche wie bei der Operation MappingInbound

11.6.1.4.1.1.3. ausgehendes Mapping

Das gleiche wie bei der Operation MappingInbound

11.6.1.4.1.1.4. Transport

Dieser Abschnitt basiert auf Requester-Übertragungsart HTTP::SOAP, andere Übertragungsarten können unterschiedliche Einstellungen beinhalten.

• Config: Ein Container für die spezifischen Netzwerk-Transport-Einstellungen.

• Type: Netzwerk-Transport-Backend des Requesters.

11.6.1.4.1.1.4.1. Konfiguration

• Authentifizierung: ein Behälter für die Authentifizierungs-Einstellungen.

• Enkodieren: die SOAP-Nachrichtenanfrage enkodieren

• Endpoint: the URI of the Remote Server web service to accept OTRS requests

• NameSpace: an URI that gives a context to all invokers that belongs to this web service.

• SOAPAction: to send an empty or filled SOAPAction header in the SOAP Message (in

"<NameSpace> <Separator> <Action>" format).

mögliche Werte

• JA: um einen befüllten SOAPAction-Header zu senden.

• Nein: um einen leeren SOAPAction-Header zu senden.

187

• SOAPActionSeparator: Für das setzen eines <Separator> eines SOAPAction Headers.

mögliche Werte

• '/': genutzt für .net-Webservices.

• '#': genutzt für alle anderen Webservices.

11.6.1.4.1.1.4.1.1. Authentifizierung

• User: der vertrauliche Benutzername, der Zugang zu dem entfernten Webservice hat.

• Passwort: das Passwort für den vertraulichen Benutzer im Klartext.

• Type: der Typ der Authentifizierung.

11.7. Verbinder

A Connector is in essence a set of actions that are either called Operations if OTRS acts as a web service provider or Invokers if OTRS acts as a web service requester. But it can also include special Mappings or Transports.

One Connector can either have only Operations, Only Invokers or both. A connector can even use parts of other connectors like the Mappings or Transports if they are not to specific for the Connector that is trying to implement them.

In other words a Connector is not limited to just the Controller layer but it can be extended to Data Mapping or Network Transport layers if needed.

Due to the modular design of the Generic Interface a Connector can be seen as a plugin; this means that by adding Connectors the capabilities of the generic interface can be extended using: OTRS Feature add ons, OTRS Custom modules, 3rd Party modules, and so on.

11.7.1. gebündelte Verbinder

In dieser OTRS Version sind die folgenden Verbinder verfügbar.

• Sitzung

• Ticket

11.7.1.1. Session-Connector

This connector is capable to create a valid SessionID that can be used in any other operation.

Liefert:

• Operationen:

• SessionCreate

11.7.1.1.1. Operationen

11.7.1.1.1.1. SessionCreate

Creates a new new valid SessionID to be used in other operations from other connectors like TicketCreate.

Anmerkung

To use the SessionID in other operations from other connectors it is necessary that the operation implements authentication by SessionID. All the rest of the bund-

188

led operations are capable of accepting a valid SessionID as an authentication method.

Mögliche Attribute:

</SessionCreate>

11.7.1.2. Ticket Connector

Dieser Connector liefert die Basisfunktionalität um mit Tickets zu interagieren.

Liefert:

• Operationen:

• TicketCreate

• TicketUpdate

• TicketGet

• TicketSearch

11.7.1.2.1. Operationen

11.7.1.2.1.1. TicketCreate

Provides an interface to create a ticket in OTRS. A ticket must contain an Article and can contain several attachments, all defined Dynamic Fields can be also set on TicketCreate operation.

Mögliche Attribute:

189

</PendingTime>

</Ticket>

190

</Article>

</DynamicField>

</Attachment>

</TicketCreate>

11.7.1.2.1.2. TicketUpdate

TicketUpdate operation adds the capability to modify attributes from an existing ticket or to add a new article, including attachments and all defined dynamic fields for the ticket and the new article.

Anmerkung

It is not necessary to create a new article to modify a ticket attribute.

Mögliche Attribute:

191

</PendingTime>

</Ticket>

192

</Article>

</DynamicField>

</Attachment>

</TicketUpdate>

11.7.1.2.1.3. TicketGet

This operation is used to get all the attributes of a ticket including the dynamic fields, all articles and all of the attachments that belong to the ticket.

Mögliche Attribute:

</TicketGet>

11.7.1.2.1.4. TicketSearch

Die Operation TicketSearch liefert eine Liste mit TicketIDs die auf die eingegebenen Suchkriterien passen.

Mögliche Attribute:

193

194

195

</DynamicFields>

</Ticketflag>

196

197

</TicketSearch>

11.7.2. Beispiele:

11.7.2.1. Webservice Konfiguration

The following is a basic but complete web service configuration file in YAML format to use all the Ticket Connector operations. In order to use it in OTRS you need to copy the content, save it into a file called GenericTicketConnector.yml, and import it into OTRS in the Web Services screen in the Admin panel by clicking in the "Add web service" action from the overview screen and then clicking in the "Import web service" action in the add screen.

---

Debugger:

DebugThreshold: debug

TestMode: 0

198

Description: Ticket Connector Sample

FrameworkVersion: 3.2.x CVS

Provider:

Operation:

SessionCreate:

Description: Creates a Session

MappingInbound: {}

MappingOutbound: {}

Type: Session::SessionCreate

TicketCreate:

Description: Creates a Ticket

MappingInbound: {}

MappingOutbound: {}

Type: Ticket::TicketCreate

TicketUpdate:

Description: Updates a Ticket

MappingInbound: {}

MappingOutbound: {}

Type: Ticket::TicketUpdate

TicketGet:

Description: Retrieve Ticket data

MappingInbound: {}

MappingOutbound: {}

Type: Ticket::TicketGet

TicketSearch:

Description: Search for Tickets

MappingInbound: {}

MappingOutbound: {}

Type: Ticket::TicketSearch

Transport:

Config:

MaxLength: 100000000

NameSpace: http://www.otrs.org/TicketConnector/

Type: HTTP::SOAP

RemoteSystem: ''

Requester:

Transport:

Type: ''

11.7.2.2. Perl SOAP Requester

The following code is a Perl script that can connect to OTRS via the generic interface.

In order to perform the operations provided by the Ticket Connector, it uses two Perl

CPAN modules SOAP::Lite and Data::Dumper. Please make sure that your environment is capable to use these modules before you try to run the scipt.

#!/usr/bin/perl -w

# --

# otrs.SOAPRequest.pl - sample to send a SOAP request to OTRS Generic Interface Ticket

Connector

# --

# This program is free software; you can redistribute it and/or modify

# it under the terms of the GNU AFFERO General Public License as published by

# the Free Software Foundation; either version 3 of the License, or

# any later version.

# This program is distributed in the hope that it will be useful,

# but WITHOUT ANY WARRANTY; without even the implied warranty of

# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the

# GNU General Public License for more details.

# You should have received a copy of the GNU Affero General Public License

# along with this program; if not, write to the Free Software

# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

# or see http://www.gnu.org/licenses/agpl.txt.

# --

199

use strict; use warnings;

# use ../ as lib location use File::Basename; use FindBin qw($RealBin); use lib dirname($RealBin); use SOAP::Lite; use Data::Dumper;

# ---

# Variables to be defined.

# this is the URL for the web service

# the format is

# <HTTP_TYPE>:://<OTRS_FQDN>/nph-genericinterface.pl/Webservice/<WEB_SERVICE_NAME>

# or

# <HTTP_TYPE>:://<OTRS_FQDN>/nph-genericinterface.pl/WebserviceID/<WEB_SERVICE_ID> my $URL = 'http://localhost/otrs/nph-genericinterface.pl/Webservice/GenericTicketConnector';

# this name space should match the specified name space in the SOAP transport for the web

service.

my $NameSpace = 'http://www.otrs.org/TicketConnector/';

# this is operation to execute, it could be TicketCreate, TicketUpdate, TicketGet,

TicketSearch

# or SessionCreate. and they must to be defined in the web service.

my $Operation = 'TicketCreate';

# this variable is used to store all the parameters to be included on a request in XML

format. Each

# operation has a determined set of mandatory and non mandatory parameters to work

correctly. Please

# check the OTRS Admin Manual in order to get a complete list of parameters.

my $XMLData = '

<UserLogin>some user login</UserLogin>

<Password>some password</Password>

<Title>some title</Title>

<CustomerUser>some customer user login</CustomerUser>

<Queue>some queue</Queue>

<State>some state</State>

<Priority>some priority</Priority>

</Ticket>

<Subject>some subject</Subject>

<ContentType>text/plain; charset=utf8</ContentType>

</Article>

# ---

# create a SOAP::Lite data structure from the provided XML data structure.

my $SOAPData = SOAP::Data

->type( 'xml' => $XMLData ); my $SOAPObject = SOAP::Lite

->uri($NameSpace)

->proxy($URL)

->$Operation($SOAPData);

# check for a fault in the soap code.

if ( $SOAPObject->fault ) {

print $SOAPObject->faultcode, " ", $SOAPObject->faultstring, "\n";

}

# otherwise print the results.

else {

200

# get the XML response part from the SOAP message.

my $XMLResponse = $SOAPObject->context()->transport()->proxy()->http_response()-

>content();

# deserialize response (convert it into a perl structure).

my $Deserialized = eval {

SOAP::Deserializer->deserialize($XMLResponse);

};

# remove all the headers and other not needed parts of the SOAP message.

my $Body = $Deserialized->body();

# just output relevant data and no the operation name key (like TicketCreateResponse).

for my $ResponseKey ( keys %{$Body} ) {

print Dumper( $Body->{$ResponseKey} );

}

12. OTRS Scheduler

The OTRS Scheduler is an independent system process that executes tasks in background.

These kind of processes are know as daemons in Unix / Linux systems or as services on

Windows environments. It is independent but that doesn't mean that the Scheduler does everything alone, it is fully integrated into OTRS and can use any OTRS module as needed to complete each task.

For sanity reasons the Scheduler process needs to be restarted from time to time. This is done automatically by the scheduler process itself once a day, but it can be adjusted as needed using the SysConfig by editing the "Scheduler::RestartAfterSeconds" setting.

The OTRS Scheduler is a fully automated process, the only needed human interaction is to check its status periodically and start or stop it as needed.

Anmerkung

If the Scheduler is stopped for any reason, all pending tasks and new tasks registered when the Scheduler is stopped will be executed as soon as the Scheduler starts again (unless the tasks are set to be executed in the future).

12.1. Scheduler - Grafisches Interface

Der Scheduler ist nicht sichtbar in der grafischen Oberfläche von OTRS solange er läuft.

12.1.1. Benachrichtigung: Scheduler läuft nicht.

There are two different types of notifications if the system detects that the scheduler is not running. This detection is based on the update frequency of the Scheduler process.

If the difference between current time and the last process update time is 2 times the process update frequency a warning message will be displayed in the OTRS notification area. If it is over 4 times the process frequency then an alert will be displayed instead.

The Scheduler process update time can be configured via the SysConfig in the

"Scheduler::PIDUpdateTime" setting.

If you see a warning message it is not always necessary to take an action, but it is highly recommended to check if the scheduler process is running. If you see an alert, then there is a high chance that the scheduler is in fact not running and should be started.

By default the Scheduler not running notification is enabled, if there is a valid web service registered in the database, and is only displayed to the users in the "admin" group.

201

To disable the notification (not recommended) or to change or add the notification groups, please edit the "Frontend::NotifyModule###800-Scheduler-Check" setting in the SysConfig.

Abbildung: Scheduler Benachrichtigung.

12.1.2. Scheduler starten

By clicking on the Scheduler not running notification link (either warning or alert) a dialog box will open to let you start the Scheduler process again. The Scheduler can be started normally or forced to start, by clicking on the appropriate check box in the dialog.

Anmerkung

A forced Scheduler start is only necessary if previous Scheduler process was terminated abnormally and the Process ID is still registered in the database.

To have full control of the Scheduler process and to check it real status please use the command line tools described below.

Abbildung: Start Scheduler.

202

12.2. Scheduler-Befehlszeilenoberfläche

The Scheduler command line tools let you control the Scheduler process (Start / Stop) or query it status. There are also tools to register the process to be controlled by the operating system.

Included with OTRS there are two sets of CLI tools, one for Unix / Linux and another for

Microsoft Windows.

12.2.1. Unix / Linux

12.2.1.1. Scheduler init.d Dateien

Init.d files are special scripts that are called by the operating system at startup and shutdown.

OTRS provides init.d scripts to start / stop the OTRS Scheduler process automatically by the operating system. These scripts are located under OTRS_HOME/scripts.

The init.d scripts need to be copied to the correct location for your operating system.

They need to have the proper permissions and some internal variables need to be set to work properly. If you used the OTRS RPMs to set up the system, this is taken care of automatically.

interne Werte des Init.d Skript

• OTRS_HOME - Der Installationspfad von OTRS.

• User - Der Benutzer unter dem Apache ausgeführt wird.

• Group - Die Gruppe unter dem Apache ausgeführt wird.

Anmerkung

Zur Zeit bietet OTRS init.d-Skripte nur für Linux-Plattformen an.

Tabelle 4.7. Liste der init-Skripte und der unterstützten

Betriebssysteme

Init-Skript

OTRS Scheduler Linux otrs-scheduler-gentoo-init.d, otrs-scheduler-gentoo-conf.d

Unterstützte Betriebssysteme

Red Hat, Fedora, CentOS, SUSE, openSUSE,

Debian, Ubuntu

Gentoo

Beispiel 4.29. Ein Beispiel wie der OTRS Scheduler unter Linux gestartet wird.

shell> /etc/init.d/otrs-scheduler-linux start

Verfügbare Aktionen

• start startet den OTRS Scheduler

• stop stoppt den OTRS Scheduler.

• restart startet den OTRS Scheduler neu.

203

• status Statusabfrage des OTRS Schedulers

Der Scheduler benötigt die Datenbank um die Prozess ID zu registrieren. Aus diesem

Grund sind folgende Dinge notwendig:

• Execute the Scheduler init.d script to start the Scheduler process after the database process is up and running.

• Execute the Scheduler init.d script to stop the Scheduler before the database process shuts down.

Anmerkung

If you want the Scheduler to run at system startup, please read the documentation of the operating system to find out the right location to place the init.d scripts, how to configure them to run automatically and how to set the run order.

12.2.1.2. Zeitplaner-Hitergrunddatei

This is the part of the Scheduler that stays running in the background checking for tasks to execute. It also provides the main functions to control the process.

Alle Unix / Linux Betriebsysteme nutzen die Datei OTRS_HOME/bin/otrs.Scheduler.pl.

Beispiel 4.30. Ein Beispiel wie der OTRS Scheduler gestartet wird.

shell> OTRS_HOME/bin/otrs.Scheduler.pl -a start

Verfügbare Optionen

• -a Aktion.

mögliche Werte

• start- startet den Scheduler.

• stop- stoppt den Scheduler.

• status- fragt den Status des Scheduler ab.

• -f erzwingt das starten oder stoppen des Scheduler.

Beispiel 4.31. Beispiel für das erzwungene stoppen des OTRS

Scheduler.

shell> OTRS_HOME/bin/otrs.Scheduler.pl -a stop -f 1

Anmerkung

Das erzwungene stoppen des Schedulers wird verwendet um die Prozess ID aus der Datenbank zu entfernen wenn der Scheduler nicht läuft, aber der Prozess registriert ist

Das erzwungene starten des Schedulers wird verwendet wenn der Scheduler nicht läuft, aber der Prozess registriert ist

Force start or stop are only necessary if the start of the process is needed to be done before the process update time expires. Otherwise an expired entry in the database is discarded by normal start.

204

12.2.2. Windows

12.2.2.1. Schedu

On Windows, the OTRS Scheduler is registered as a Service via the Windows Service

Control Manager (SCM). In order to have the OTRS Scheduler process to be controlled by the SCM is necessary to register this service. If you used the Windows Installer this is taken care of by the installer, and there are no manual actions required.

OTRS provides the script OTRS_HOME/bin/otrs.Scheduler4WinInstaller.pl to register or unregister the OTRS Scheduler into the SCM.

Anmerkung

Registering and de-registering can only be performed by members of the Administrator group on Windows. You might need to right-click on cmd.exe and select

'Run as Administrator' before you can register the service correctly.

Beispiel 4.32. Ein Beispiel wie der OTRS Scheduler unter Windows als Service registriert wird.

shell> perl OTRS_HOME/bin/otrs.Scheduler4WinInstaller.pl -a install

Verfügbare Optionen

• -a Aktion.

mögliche Werte

• install- um den Scheduler in den Windows ServiceManager zu installieren.

• remove- um den Scheduler vom Windows ServiceManager zu entfernen.

After installing into the Windows SCM the OTRS Scheduler process can be used like any other service on Windows. It can be started, stopped and restarted and can be configured to be started manually or automatic.

Anmerkung

To learn more about Windows Services and the Windows SCM please read the

Windows documentation, and Microsoft online help.

12.2.2.2. Zeitplaner-Dienstdatei

This is the part of the Scheduler that stays running in the background checking for tasks to execute. It also provides the main functions to control the process.

Microsoft Windows verwendet die Datei OTRS_HOME/bin/otrs.Scheduler4Win.pl.

Beispiel 4.33. Ein Beispiel wie der OTRS Scheduler unter Windows gestartet wird.

shell> OTRS_HOME/bin/otrs.Scheduler4Win.pl -a start

Verfügbare Optionen

• -a Aktion.

205

mögliche Werte

• start- startet den Scheduler.

• stop- stoppt den Scheduler.

• status- fragt den Status des Scheduler ab.

• -f erzwingt das starten oder stoppen des Scheduler.

Beispiel 4.34. Beispiel für das erzwungene stoppen des OTRS

Scheduler unter Windows.

shell> OTRS_HOME/bin/otrs.Scheduler4Win.pl -a stop -f 1

Anmerkung

Force stopping the Scheduler is used to remove the process ID from the database when the scheduler is not running and the process is still registered.

Force starting the Scheduler is used to start the Scheduler process if the scheduler is not running and the process is still registered.

Force start or stop are only necessary if starting the process is needed to be done before the process update time expires. Otherwise an expired entry in the database would be discarded by a normal start.

206

Kapitel 5. Anpassung

1. Access Control Lists (ACLs)

1.1. Einführung

Seit OTRS 2.0 können Access Control Lists (ACLs) verwendet werden, um den Zugriff auf

Tickets, Module, Queues, usw. zu steuern bzw. um in bestimmten Situationen Aktionen auf Tickets (schließen, verschieben, usw.) zu beeinflussen. ACLs können als Ergänzung

zum bestehenden Berechtigungssystem der Rollen und Gruppen verwendet werden. Mit

ACLs lassen sich, basierend auf Ticket-Attributen, rudimentäre Workflows innerhalb des

Systems abbilden.

As yet, ACLs cannot be created using the SysConfig interface. They must be directly ent-

ered into the Kernel/Config.pm file. This chapter has some ACL examples which will walk you trough the process of defining ACL definitions, and a reference of all possible important ACL settings.

1.2. Beispiele

Beispiel 5.1. ACL, die das Verschieben von Tickets in eine Queue nur bei einer Ticket-Priorität von 5 erlaubt.

This example shows you the basic structure of an ACL. First, it needs to have a name.

In this case, it is "ACL-Name-2". Note that the ACLs will be numerically sorted before execution, so you should use the names carefully.

Secondly, you have a "Properties" section which is a filter for your tickets. All the criteria defined here will be applied to a ticket to determine if the ACL must be applied or not. In our example, a ticket will match if it is in the queue "Raw" and has priority "5 very high".

This is also affected by changes in the form (e.g. if the ticket is the queue "raw" and had a priority "3 normal", but then priority drop-down is selected and the priority is changed now to "5 very high" will also match).

Lastly, a section "Possible" defines modifications to the screens. In this case, from the available queues, only the queue "Alert" can be selected in a ticket screen.

# ticket acl

$Self->{TicketAcl}->{'100-Example-ACL'} = {

# match properties

Properties => {

# current ticket match properties

Ticket => {

Queue => ['Raw'],

Priority => ['5 very high'],

}

# return possible options (white list)

Possible => {

# possible ticket options (white list)

Ticket => {

Queue => ['Alert'],

};

207

Beispiel 5.2. ACL, die das Verschieben von Tickets in eine Queue nur bei einer Ticket-Priorität von 5 erlaubt.

This example is very similar to the last one, but in this case only tickets in the queue "Raw" and with a priority "5 very high", both stored in the database will match. This kind of ACLs does not consider changes in the form before the ticket is really updated in the database.

# ticket acl

$Self->{TicketAcl}->{'100-Example-ACL'} = {

# match properties

PropertiesDatabase => {

# current ticket match properties

Ticket => {

Queue => ['Raw'],

Priority => ['5 very high'],

}

# return possible options (white list)

Possible => {

# possible ticket options (white list)

Ticket => {

Queue => ['Alert'],

};

Beispiel 5.3. ACL, die das Schließen von Tickets in der raw-Queue verbietet und den Schließen-Schalter ausblendet.

Here you can see how a ticket field (state) can be filtered with more than one possible value to select from. It is also possible to limit the actions that can be executed for a certain ticket. In this case, the ticket cannot be closed.

$Self->{TicketAcl}->{'101-Second-Example-ACL'} = {

# match properties

Properties => {

# current ticket match properties

Ticket => {

Queue => ['Raw'],

}

# return possible options (white list)

Possible => {

# possible ticket options (white list)

Ticket => {

State => ['new', 'open', 'pending reminder'],

# possible action options

Action => {

AgentTicketBounce => 1,

AgentTicketClose => 0,

AgentTicketCompose => 1,

AgentTicketCustomer => 1,

AgentTicketForward => 1,

AgentTicketFreeText => 1,

AgentTicketHistory => 1,

AgentTicketLink => 1,

AgentTicketLock => 1,

AgentTicketMerge => 1,

AgentTicketMove => 1,

AgentTicketNote => 1,

AgentTicketOwner => 1,

AgentTicketPending => 1,

AgentTicketPhone => 1, # only used to hide the Split action

AgentTicketPhoneInbound => 1,

AgentTicketPhoneOutbound => 1,

AgentTicketPrint => 1,

208

AgentTicketPriority => 1,

AgentTicketResponsible => 1,

AgentTicketWatcher => 1,

AgentTicketZoom => 1,

AgentLinkObject => 1, # only used to hide the Link action

};

Beispiel 5.4. ACL entfernt immer den Status Erfolgreich geschlossen

This example shows how it is possible to define negative filters (the state "closed successful" will be removed). You can also see that not defining match properties for a ticket will match any ticket, i. e. the ACL will always be applied. This may be useful if you want to hide certain values by default, and only enable them in special circumstances (e. g. if the agent is in a specific group).

$Self->{TicketAcl}->{'102-Third-ACL-Example'} = {

# match properties

Properties => {

# current ticket match properties (match always)

# return possible options

PossibleNot => {

# possible ticket options

Ticket => {

State => ['closed successful'],

};

Beispiel 5.5. ACL, die nur Hardware-Services für Tickets anzeigt, die in Queues erstellt wurden, die mit "HW" beginnen.

This example also shows you how you can use regular expressions for matching tickets and for filtering the available options.

$Self->{TicketAcl}->{'Only-Hardware-Services-for-HW-Queues'} = {

# match properties

# note we don't have "Ticket => {" because there's no ticket yet

Properties => {

Queue => {

Name => ['[RegExp]HW'],

}

# return possible options

Possible => {

# possible ticket options

Ticket => {

Service => ['[RegExp]^(Hardware)'],

};

1.3. Referenz

In dem angehängten Beispiel finden Sie eine Liste aller Parameter, welche für ACLs verwendet werden können.

Please see the section on ACLs in the ProcessManagement documentation for a detailed

descripton of how to use ACLs for process tickets.

209

Beispiel 5.6. Die Liste zeigt alle möglichen und wichtigen ACL-

Einstellungen

# ticket acl

$Self->{TicketAcl}->{'200-ACL-Reference'} = {

# match properties (current values from the form)

Properties => {

# the used frontend module

Frontend => {

Action => ['AgentTicketPhone', 'AgentTicketEmail'],

# the logged in agent

User => {

UserLogin => ['some login'],

Group_rw => [

'hotline',

Role => [

'admin',

# ...

# the logged in customer

CustomerUser => {

UserLogin => ['some login'],

Group_rw => [

'hotline',

Role => [

'admin',

# ...

# process properties

Process => {

ProcessEntityID => ['P1'], # the Process that the current ticket is

part of

ActivityEntityID => ['A1'], # the current Activity of the ticket

ActivityDialogEntityID => ['AD1'], # the current ActivityDialog that the Agent/

Customer is using

# ticket properties

Queue => {

Name => ['Raw'],

QueueID => ['some id'],

GroupID => ['some id'],

Email => ['some email'],

RealName => ['OTRS System'],

# ...

Service => {

ServiceID => ['some id'],

Name => ['some name'],

ParentID => ['some id'],

# ...

Type => {

ID => ['some id'],

Name => ['some name'],

# ...

Priority = {

ID => ['some id'],

Name => ['some name'],

# ...

210

SLA = {

SLAID => ['some id'],

Name => ['some name'],

Calendar => ['some calendar'],

# ...

State = {

ID => ['some id'],

Name => ['some name'],

TypeName => ['some state type name'],,

TypeID => ['some state type id'],

# ...

Owner => {

UserLogin => ['some login'],

Group_rw => [

'some group',

Role => [

'admin',

# ...

Responsible => {

UserLogin => ['some login'],

Group_rw => [

'some group',

Role => [

'admin',

# ...

DynamicField => {

# Names must be in DynamicField_<field_name> format.

# Values in [ ... ] must always be the untranslated internal data keys

# specified in the dynamic field definition and

# not the data values shown to the user.

DynamicField_Field1 => ['some value'],

DynamicField_OtherField => ['some value'],

DynamicField_TicketFreeText2 => ['some value'],

# ...

# alternatively, ticket properties can be specified in the ticket hash

Ticket => {

Queue => ['Raw'],

State => ['new', 'open'],

Priority => ['some priority'],

Lock => ['lock'],

CustomerID => ['some id'],

CustomerUserID => ['some id'],

Owner => ['some owner'],

DynamicField_Field1 => ['some value'],

DynamicField_MyField => ['some value'],

# ...

# match properties (existing values from the database)

PropertiesDatabase => {

# See section "Properties", the same config can be used here.

# ...

}

# return possible options (white list)

Possible => {

# possible ticket options (white list)

Ticket => {

Queue => ['Hotline', 'Coordination'],

State => ['some state'],

Priority => ['5 very high'],

211

DynamicField_Field1 => ['some value'],

DynamicField_MyField => ['some value'],

# ...

NewOwner => ['some owner'],

OldOwner => ['some owner'],

# ...

# Limit the number of possible ActivityDialogs the Agent/Customer

# can use in a process ticket.

ActivityDialog => ['AD1', 'AD3'],

# Limit the number of possible Processes that can be started

Process => ['P1', 'P2'],

# possible action options (white list)

Action => {

AgentTicketBounce => 1,

AgentTicketClose => 1,

AgentTicketCompose => 0,

AgentTicketCustomer => 0,

AgentTicketForward => 0,

AgentTicketFreeText => 1,

AgentTicketHistory => 1,

AgentTicketLink => 0,

AgentTicketLock => 1,

AgentTicketMerge => 0,

AgentTicketMove => 1,

AgentTicketNote => 1,

AgentTicketOwner => 1,

AgentTicketPending => 1,

AgentTicketPhone => 1, # only used to hide the Split action

AgentTicketPhoneInbound => 0,

AgentTicketPhoneOutbound => 1,

AgentTicketPrint => 1,

AgentTicketPriority => 0,

AgentTicketResponsible => 1,

AgentTicketWatcher => 1,

AgentTicketZoom => 1,

AgentLinkObject => 1, # only used to hide the Link action

# remove options (black list)

PossibleNot => {

# See section "Possible"

# ...

};

Anmerkung

While matching ACLs if CustomerUserID parameter sent, the ACL mechanism will compare the defined ACLs using the supplied CustomerUserID to gather the CustomerUser details to fill the CustomerUser hash and it also overrides the Customer information in the Ticket hash for the Properties match. On the other hand this calculations are also made for the PropertiesDatabase part, but using the Ticket

Customer as the basis to gather the data.

Notice that in Customer Interface, the CustomerUserID is always sent with the current logged Customer User.

Be aware that in ticket search screens (AgentTicketSearch and CustomerTicketSearch) the only affected attributes by ACLs are the Dynamic Fields. This means that this screens you can not restrict any other attribute like ticket type, state, queue, etc.

212

2. Prozess-Management

2.1. Einführung

Diese Funktion erlaubt Ihnen in OTRS Prozesse (Work-Flows) zu modellieren. Die grundlegende Idee ist wiederkehrende Prozesse zu definieren und die Arbeit an verschiedene

Personen zu delegieren, genauso um den Prozess in verschiedene Richtungen, basierend auf bestimmten Kriterien, zu führen.

2.2. Beispiel Prozess

Zur Demonstration schauen wir uns ein Beispiel an. Wir wollen die Bestellung eines

Buches in einem Prozess abbilden.

2.2.1. Aufnahme der Anforderungen

Bevor eine Bestellung abgesetzt wird, wird die Anforderung eines Mitarbeiters von Literatur gespeichert. Das folgende Buch wird in unserem Beispiel benötigt:

Titel: Prozessmanagement für Dummies

Autor: Thilo Knuppertz

ISBN: 3527703713

2.2.2. Genehmigung durch Manager

Der Abteilungsleiter des Mitarbeiters muss über die Bestellung entscheiden. Im Falle einer

Verweigerung sollte ein Grund vom Manager angegeben werden. Im Falle einer Genehmigung wird die Bestellung zur Einkauf-Abteilung weitergeleitet.

2.2.3. Verarbeitung durch Einkaufsabteilung

Die Einkauf-Abteilung muss nun herausfinden, wo das Buch zu den besten Konditionen bestellt werden kann. Wenn es ausverkauft ist kann das in der Bestellung vermerkt werden. Im Falle einer erfolgreichen Bestellung wird die Einkauf-Abteilung den Lieferanten, den Preis und das Lieferdatum aufnehmen.

2.2.4. Verarbeitung durch Poststelle

Die Lieferung kommt an der Firma an. Die Warenannahme überprüft die Lieferung und notiert das Empfangsdatum. Nun wird der Mitarbeiter informiert, dass seine Bestellung angekommen ist und bereit ist, abgeholt zu werden.

2.3. Implementierung des Beispiels

Wenn wir davon ausgehen, dass sich ein Ticket in diesem Work-Flow wie ein Begleitdokument verhält, das Veränderungen als Notizen empfängt, dann haben wir schon ein klares

Bild der Prozess-Tickets.

Nach der Analyse des Beispielprozesses, konnten wir folgende nötigen Elemente identifizieren:

• Möglichkeiten zur Datenaufnahme, hier Aktivitäten-Dialoge,

• Kontrollen, die automatisch auf geänderte Daten reagieren kann, nennen wir sie Über-

gänge,

• Änderungen, die sich auf ein Prozess-Ticket nach erfolgreichem Übergang eines Prozess-Ticket angewendet werden können, nennen wir sie Übergangsaktionen.

213

Wir brauchen noch ein zusätzliches Element, was nicht so offensichtlich sein könnte:

• Eine Möglichkeit mehr als nur einen Aktivitätsdialog zur Verfügung zustellen. In unserem Beispiel ist das erforderlich, wenn die Führungskraft zwischen "Genehmigen" und

"Ablehnen" zu entscheiden hat. Nennen wir sie Aktivität .

Mit Aktivitäten, Aktivitätsdialogen, Übergängen und Übergangsaktionen haben wir die notwendigen Werkzeuge, um die einzelnen Schritte unseres Beispiels zu modellieren. Was ist noch fehlt, ist ein Bereich, wo für jeden Arbeitsablauf die Reihenfolge der Schritte festgelegt wird. Nennen wir diesen Prozess. Um uns auf all diese Personen später beziehen zu können, werden wir ihnen in Klammern eine Abkürzung zuweisen. Diese Abkürzungen basieren auf einem internen Identifikations-Mechanismus namens EntityIDs.

Die EntityIDs werden mit einem oder zwei Buchstaben (je nach Prozessteil) und einer fortlaufenden Nummer gebildet, Beispiel:

• Prozess: 'P1', 'P2' ... 'Pn'.

• Aktivität: 'A1', 'A2' ... 'An'.

• Aktivitätsdialog: 'AD1', 'AD2' ... 'ADn'.

• Übergang: 'T1', 'T2' ... 'Tn'.

• Übergangsaktivität: 'TA1', 'TA2' ... 'TAn'.

Vor der Erstellung des Prozesses und seiner Abschnitte ist es notwendig, das System vorzubereiten, wir müssen sowohl einige Queues, Nutzer und Dynamic Fields definieren, als auch ein paar SysConfig-Optionen festlegen.

Erstellen Sie die folgenden Queues:

• Management

• Mitarbeiter

• Einkauf

• Post

Erstellen Sie die folgenden Benutzer:

• Manager

• Mitarbeiter

Erstellen Sie die folgenden DynamicFields

• Titel

Beschriftung

Typ

Objekt

Titel

Text

Ticket

• Autor

Beschriftung

Typ

Objekt

• ISBN

Beschriftung

Autor

Text

Ticket

ISBN

214

Typ

Objekt

• Status

Beschriftung

Typ

Objekt mögliche Werte

Text

Ticket

Status

Einfachauswahl

Ticket

• Genehmigung

• Genehmigung abgelehnt

• genehmigt

• Bestellung abgelehnt

• Bestellung aufgegeben

• Sendung empfangen

Bemerkung: Bitte benutzen Sie exakt diese möglichen Werte für "Schlüssel" und "Wert" in den DynamicField-Einstellungen

• Lieferant

Beschriftung

Typ

Objekt

Lieferant

Text

Ticket

• Preis

Beschriftung

Typ

Objekt

• LieferDatum

Beschriftung

Typ

Objekt

• Eingangsdatum

Beschriftung

Typ

Objekt

Preis

Text

Ticket

Liefertermin

Datum

Ticket

Datum des Eingangs

Datum

Ticket

Setzen Sie die folgenden SysConfig-Einstellungen:

• 'Ticket::Responsible': Ja

• 'Ticket::Frontend::AgentTicketZoom###ProcessWidgetDynamicFieldGroups':

Schlüssel:

Buch

Inhalt:

Titel, Autor,ISBN

215

Schlüssel:

Allgemein

Auftrag

Lieferung

Inhalt:

Status

Preis, Lieferant,Liefertermin

Eingangsdatum

• 'Ticket::Frontend::AgentTicketZoom###ProcessWidgetDynamicField':

Schlüssel:

Autor

Eingangsdatum

LieferDatum

ISBN

Preis

Status

Lieferant

Titel

Inhalt:

Fangen wir mit dem realen Prozessmanagement an. Im nächsten Schritt werden wir die einzelnen Objekte, die wir benötigen, definieren.

2.3.1. Prozess (als ein Container)

Um einen neuen Prozess zu erstellen ist es notwendig auf den Link "Prozess Management" in der Systemverwaltungs-Box im Admin-Menü zu klicken, anschließend gelangen wir zur

Prozessmanagement-Übersicht. Nachdem der Prozess erstellt wurden, können wir alle anderen Objekte (oder Prozessteile) erstellen.

Anmerkung

Aktivitäten, Aktivitätsdialoge, Übergänge und Übergangsaktionen die in einem

Prozess definiert wurden, sind ebenfalls für alle anderen Prozesse im System verfügbar.

Abbildung.: OTRS Administrationsbereich.

Klicken Sie auf "Neuen Prozess erstellen" im Adminmenü

Abbildung.: Neuen Prozess hinzufügen.

216

Füllen Sie die Prozessinformationen aus, definieren Sie einen Prozessname und die

Beschreibung für diesen Prozess, wir belassen den Prozessstatus auf "inaktiv", bis wir alle

Aufgaben erledigt haben. Speichern Sie den Vorgang.

Abb.: Neuen Prozess hinzufügen.

2.3.2. Aktivitäts-Dialoge

Klicken Sie auf den neuen Prozessnamen in der Prozessmanagement-Übersichtsbild, dann in den "verfügbaren Prozess Elementen" klicken Sie auf "Activity Dialoge" (diese Aktion wird die möglichen Dialogoptionen erweitern), anschließend klicken Sie auf "Neuen Aktivitätsdialog erstellen".

Abbildung: Erstelle neue Aktivitätsdialog.

In the opened popup screen fill the "Activity dialog Name" as well as the "Description

(short)" fields, for this example we will leave all other fields as the default, to assign fields to the Activity Dialog simple drag the required field from the "Available Fields" pool and drop into the "Assigned Fields" pool. The order in the "Assigned Fields" pool is the order as the fields will have in the screen, to modify the order simply drag and drop the filed within the pool to rearrange it in the correct place.

217

Abbildung: Neuen Aktivitätsdialog hinzufügen.

As soon as the fields are dropped into the "Assigned Fields" pool another popup screen is shown with some details about the field, we will leave the default options and only for

Article fields we should make sure that the ArticleType field is set to "note-internal".

Abbildung: Felddetails bearbeiten (Artikel).

After all fields are assigned click on the submit button in the main popup screen to save the changes.

In this example we will use Article field for comments, but another option could be to create a TextArea type Dynamic Field, the rest of the mentioned fields in the lines below are the Dynamic Fields that we define before.

Please be aware that in this screen all the Dynamic Fields has the prefix "DynamicField_" as in "DynamicField_Title", Do not confuse with the field "Title" that is the Ticket Title.

Erstellen Sie die folgenden Aktivitätsdialoge:

• "Aufnahme der Nachfrage" (AD1)

Ein Aktivitätsdialog, welcher alle erforderlichen Felder für die Daten der Bestellung enthält (Titel, Autor und ISBN) und ein Statusfeld mit der Möglichkeit "Approval" zu wählen.

• "Genehmigung verweigert" (AD2)

218

Ein Aktivitätsdialog mit einem Kommentarfeld (Artikel) und einem Statusfeld mit der

Möglichkeit "Approval denied".

• "Genehmigt" (AD3)

Hier benötigen Sie das Statusfeld mit der Option "Genehmigt".

• "Bestellung abgelehnt" (AD4)

Ein Aktivitsdialog, welcher es ermöglicht eine unmögliche Bestellung abzulehnen (Buch ist nicht auf Lager). Hier wird ebenfalls ein Kommentarfeld und ein Statusfeld mit der

Option "Order denied" benötigt.

• "Bestellung aufgegeben" (AD5)

Ein Aktivitätsdialog mit den Feldern Lieferant, Preis und Lieferdatum und dem Statusfeld mit der Option "Bestellung abgegeben".

• "Sendung empfangen" (AD6)

Eine Aktivität für die Poststelle mit einem Feld für das Empfangsdatum und dem Statusfeld mit der Option "Bestellung empfangen".

Um das Statusfeld zu beschränken, benötigen wir für jeden Aktivitätsdialog mindestens eine ACL in Kernel/Config.pm oder in einer neuen Perl-Datei in Kernel/Config/Files.

$Self->{TicketAcl}->{'P1-AD1-1'} = {

Properties => {

Process => {

ActivityDialogEntityID => ['AD1'],

Possible => {

Ticket => {

DynamicField_Status => ['Approval'],

};

$Self->{TicketAcl}->{'P1-AD2-1'} = {

Properties => {

Process => {

ActivityDialogEntityID => ['AD2'],

Possible => {

Ticket => {

DynamicField_Status => ['Approval denied'],

};

$Self->{TicketAcl}->{'P1-AD3-1'} = {

Properties => {

Process => {

ActivityDialogEntityID => ['AD3'],

Possible => {

Ticket => {

DynamicField_Status => ['Approved'],

};

219

$Self->{TicketAcl}->{'P1-AD4-1'} = {

Properties => {

Process => {

ActivityDialogEntityID => ['AD4'],

Possible => {

Ticket => {

DynamicField_Status => ['Order denied'],

};

$Self->{TicketAcl}->{'P1-AD5-1'} = {

Properties => {

Process => {

ActivityDialogEntityID => ['AD5'],

Possible => {

Ticket => {

DynamicField_Status => ['Order placed'],

};

$Self->{TicketAcl}->{'P1-AD6-1'} = {

Properties => {

Process => {

ActivityDialogEntityID => ['AD6'],

Possible => {

Ticket => {

DynamicField_Status => ['Shipment received'],

};

2.3.3. Übergänge

Klicken Sie in den "Verfügbaren Prozesselementen" auf "Übergänge", anschließend klicken Sie auf "Erstelle neue Übergans-Aktion".

Abbildung: Neuen Übergang hinzufügen.

In dem öffnenden Popup füllen Sie bitte den "Übergangsnamen" aus, anschließend tragen

Sie die benötigten Zustände ein. In diesem Beispiel werden wir nur einen Zustand und nur ein Feld benutzen. Für diese beiden lassen für den Linktyp auf "and" und wir werden den Match-Type-Wert als "String" nutzen.

220

Abildung: Neuen Übergang hinzufügen.

Nachdem alle Parameter und Werte gesetzt worden sind, klicken Sie auf die "Übermitteln"-Schaltfläche um die Werte zu speichern.

Erstellen Sie die folgenden Übergänge:

• "Genehmigung" (T1)

Ein Übergang, der überprüft ob das Statusfeld auf "Genehmigung" gesetzt ist.

• "Genehmigung verweigert" (T2)

Ein Übergang, der überprüft ob das Statusfeld auf "Genehmigung verweigert" gesetzt ist.

• "Genehmigt" (T3)

Ein Übergang, der überprüft ob das Statusfeld auf "Genehmigung erteilt" gesetzt ist.

• "Bestellung abgelehnt" (T4)

Ein Übergang, der überprüft ob das Statusfeld auf "Bestellung verweigert" gesetzt ist.

• "Bestellung aufgegeben" (T5)

Ein Übergang, der überprüft ob das Statusfeld auf "Bestellung aufgegeben" gesetzt ist.

• "Sendung empfangen" (T6)

Ein Übergang, der überprüft ob das Statusfeld auf "Sendung empfangen" gesetzt ist.

2.3.4. Übergangs-Aktionen

Klicken Sie auf "Übergangs-Aktionen" in den "Verfügbaren Prozesselementen", anschlie-

ßend klicken Sie auf "Erstelle neue Übergans-Aktion".

Abbildung: Erstelle neue Übergangsaktion.

221

In dem öffnenden Popup füllen Sie bitte den "Übergangsnamen" und das "Übergangsaktionsmodul" aus, dann tragen Sie die benötigten und optionalen Parameternamen und

Werte ein.

Alle Übergangsaktionsmodule befinden sich in Kernel/System/ProcessManagement/TransitionAction und die folgende Liste zeigt Ihnen alle Übergangsaktionen die mit diesem

Release ausgeliefert werden

• DynamicFieldSet

• TicketArticleCreate

• TicketCustomerSet

• TicketLockSet

• TicketOwnerSet

• TicketQueueSet

• TicketResponsibleSet

• TicketServiceSet

• TicketSLASet

• TicketStateSet

• TicketTitleSet

• TicketTypeSet

Jedes Modul hat seine eigenen und verschiedenen Parameter. Eine Übersicht aller benö-

tigten und optionalen Parameter finden Sie unter Moduldokumentation.

Abbildung: Hinzufügen einer Übergangsaktion.

Nachdem alle Parameter und Werte gesetzt worden sind, klicken Sie auf die "Übermitteln"-Schaltfläche um die Werte zu speichern.

Erstellen Sie die folgenden Übergangs-Aktionen:

• "Verschiebe das Prozessticket in die Management-Queue" (TA1)

Diese Aktion wird vermutlich ausgeführt wenn der Übergang "Approval" (T1) angewandt wurde.

• "Ändere den Ticket-Verantwortlichen zu 'Manager'" (TA2)

Wird ausgeführt, wenn der Übergang "Approval" (T1) ausgeführt wurde.

• "Verschiebe das Prozessticket in die 'Employees'-Queue" (TA3)

222

Wird ausgeführt, wenn:

• Der Übergang "Approval denied" (T2) wird ausgeführt

• Der Übergang "Order denied" (T4) wird ausgeführt.

• Der Übergang "Shipment received" (T6) wird ausgeführt

• Ändere den Ticket-Verantwortlichen zu 'Employee'" (TA4)

Wird ausgeführt, wenn:

• Der Übergang "Approval denied" (T2) wird ausgeführt

• Der Übergang "Order denied" (T4) wird ausgeführt

• Der Übergang "Shipment received" (T6) wird ausgeführt

• "Verschiebe das Prozessticket in die 'Purchasing'-Queue" (TA5)

Wird ausgeführt, wenn der Übergang "Approved" (T3) ausgeführt wurde.

• "Verschiebe das Prozessticket in die 'Post office'-Queue" (TA6)

Wird ausgeführt, wenn der Übergang "Order placed (T5) ausgeführt wurde.

• "Ticket erfolgreich schließen" (TA7)

Wird ausgeführt, wenn:

• Der Übergang "Shipment received" (T6) wird ausgeführt

• Ticket erfolglos schließen" (TA8)

Wird ausgeführt, wenn:

• Der Übergang "Approval denied" (T2) wird ausgeführt

• Der Übergang "Order denied" (T4) wird ausgeführt

Wie Sie sehen, gibt es Orte an denen gleiche Übergangsaktionen ausgeführt werden sollen. Deshalb ist es sinnvoll Übergangsaktionen frei mit Übergängen zu verknüpfen, um sie wiederverwenden zu können.

2.3.5. Aktivitäten

We chose the approach to see Activities as a basket which can contain one or more Activity

Dialogs.

Klicken Sie auf "Aktivitäten" in den verfügbaren "Prozesselementen", anschließend klicken

Sie auf "Erstelle neue Aktivität".

223

Abbildung: Erstelle neue Aktivitätsschaltfläche.

In the opened popup screen fill the "Activity Name", Then drap the required Activity Dialogs from the "Available Activity Dialogs" pool, and drop then into to the "Assigned Activity

Dialogs" pool. This dialogs will be presented (in the ticket zoom screen) in the same order as it is defined on this screen translating from top to bottom, to left to right.

This order is specially important in the first Activity, since the first Activity Dialog for this activity is the only one that is presented when the process starts

Erstellen Sie die folgenden Aktivitäten:

• "Aufnahme der Nachfrage" (A1)

Beinhaltet die Aktivität "Aufnahme der Nachfrage" (AD1)

• "Genehmigung" (A2)

Beinhaltet die Aktivitäsdialoge "Genehmigung verweigert" (AD2) und "Genehmigt" (AD3)

• "Bestellung" (A3)

Beinhaltet die Aktivitätsdialoge "Bestellung abgelehnt" (AD4) und "Bestellung aufgegeben" (AD5)

• Eingehend (A4)

Beinhaltet den Aktivitätsdialog "Bestellung erhalten" (AD6)

• "Prozess beendet" (A5): Das ist eine Aktivität ohne mögliche Aktivitätsdialoge. Sie wird nach "Genehmigung verweigert", "Genehmigt", "Bestellung abgelehnt", "Bestellung aufgegeben" oder "Bestellung erhalten" angezeigt und stellt das Ende des Prozesses dar.

Now we can clearly see that Activities are precisely defined states of a process ticket.

After a successful Transition a process ticket moves from one Activity to another.

2.3.6. Buchbestellprozesspfad

Let us conclude our example with the last missing piece in the puzzle, the Process as the a flow describer. In our case this is the whole ordering work-flow. Other processes could be office supply ordering or completely different processes.

The process has a starting point which consists of the start Activity and the start Activity

Dialog. For any new book order, the start Activity Dialog (first Activity Dialog for the first

Activity) is the first screen that is displayed. If this is completed and saved, the Process ticket will be created and can follow the configured work-flow.

The process also contains the directions for how the process ticket can move through the

Process. Let's call this the "Path". It consists of the start Activity, one or more Transitions

(possibly with Transition Actions), and other Activities.

Assuming that the Activities has already assigned their Activity Dialogs drag an Activity from the accordion (in the left part of the screen) and drop it into the canvas area (below process information). Notice that an arrow from the process start (green circle) to the

Activity is placed automatically. (This is the first Activity and its first Activity Dialog is the first screen that will be shown when the process starts).

224

Abbildung: Ziehen der ersten Aktivität in die Arbeitsfläche.

Next, drag another Activity into the canvas too. now we will have two Activities in the canvas the first one is connected to the start point and the second has no connections, you can hover the mouse over each activity to reveal their own Activity Dialogs.

225

Abbildung: Ziehen der zweiten Aktivität in die Arbeitsfläche.

Then let's create the "Path" (connection) between this two Activities, for this we will use the Transitions, Click on Transitions in the accordion drag a Transition and drop it inside the first Activity, notice that the Activity change its color indicating that the Transition is attached, as soon as the Transition is dropped the end point of the Transition arrow will be placed next to the process start point. Drag the Transition arrow end point and drop it inside the other Activity to create the connection between the Activities.

Abbildung: Ziehen des Überganges in die Arbeitsfläche.

Now that the "Path" between the Actions is defined, then we need to assign the Transition

Actions to the Transition, double click the Transition label (in the canvas), this will open a new popup window.

226

Abbildung: Verbinden von Aktivitäten mit Übergängen.

Drag the needed Transition Actions from Available Transition Actions pool and drop them into the Assigned Transition Actions pool and click on submit button.

Abbildung: Zuweisen von Übergangsaktionen. Assign Transition Actions.

Then back in the main process edit screen click on save button below the canvas to save all other changes.

Complete the "path"" adding the following Activities, Transitions and Transition Actions:

Aufnahme der Nachfrage bis zur "Approval"

• Startpunkt: Aktivität "Aufnahme der Nachfrage" (A1)

227

• Möglicher Übergang: Approval (T1)

• Wenn die Bedingung der Aktivität erfüllt ist, wird das Ticket in die Aktivität: Approval

(A2) geschoben.

• Zusätzlich werden die folgenden Übergangs-Aktionen ausgeführt:

• "Verschiebe das Ticket in die 'Managment' Queue (TA1)

• "Setze den Ticketverantwortlichen auf 'Manager'" (TA2)

The Activity: "Recording the demand" (A1) is a defined step of the process ticket, where there is the possibility for the Transition: "Approval" (T1). If this applies, the ticket will move to the next Activity: "Approval" (A2), and the Transition Actions: "Moving the ticket into the 'Management' Queue" (TA1) and "Set ticket responsible to 'manager'" (TA2) are executed. In the Activity: "Approval" (A2), the Activity Dialogs: "Approval denied" (AD2) and "Approved" (AD3) are available.

Genehmigung

• Startpunkt: Aktivität "Approval" (A2)

• Mögliche Übergänge:

• "Genehmigung verweigert" (T2)

• Wenn dies zutrifft, wird das Ticket in die Aktivität: "Process complete (A5) geschoben.

• Zusätzlich werden die folgenden Übergangs-Aktionen ausgeführt:

• "Verschiebe das Ticket in die 'Employees' Queue (TA3)

• "Setze den Ticketverantwortlichen auf 'Employee'" (TA4)

• Ticket erfolglos schließen" (TA8)

• "Genehmigt" (T3)

• Wenn dies zutrifft, wird das Ticket in die Aktivität: "Order" (A3) geschoben.

• Zusätzlich werden die folgenden Übergangs-Aktionen ausgeführt:

• "Verschiebe das Ticket in die 'Purchasing' Queue (TA5)

We can see that from the current Activity, which defines a step of the process ticket, there are one or more possibilities for Transition which have exactly one target Activity (and possibly one or more Transition Actions).

Auftrag

• Startpunkt: Aktivität "Order" (A3)

• Mögliche Übergänge:

• "Bestellung abgelehnt" (T4)

• Wenn dies zutrifft, wird das Ticket in die Aktivität: "Process complete (A5) geschoben.

• Zusätzlich werden die folgenden Übergangs-Aktionen ausgeführt:

• "Verschiebe das Ticket in die 'Employees' Queue (TA3)

228

• "Setze den Ticketverantwortlichen auf 'Employee'" (TA4)

• Ticket erfolglos schließen" (TA8)

• "Bestellung aufgegeben" (T5)

• Wenn dies zutrifft, wird das Ticket in die Aktivität: "Incoming" (A5) geschoben.

• Zusätzlich werden die folgenden Übergangs-Aktionen ausgeführt:

• "Verschiebe das Ticket in die 'Post office' Queue (TA6)

Eingehend

• Startpunkt: Aktivität "Incoming" (A4)

• Mögliche Übergänge:

• "Sendung empfangen" (T6)

• Wenn dies zutrifft, wird das Ticket in die Aktivität: "Process complete (A5) geschoben.

• Zusätzlich werden die folgenden Übergangs-Aktionen ausgeführt:

• "Verschiebe das Ticket in die 'Employees' Queue (TA3)

• "Setze den Ticketverantwortlichen auf 'Employee'" (TA4)

• "Ticket erfolgreich schließen" (TA7)

Der komplette Pfad für den Buchbestellprozess schaut wie folgt aus:

Abbildung: vollständiger Buchbestellprozesspfad.

After you finish the process path please click on "Save" button in the lower part of the canvas and then click on "Synchronize All Processes" button. This will gather all processes information form the Database and create a cache file (in Perl language). This cache file

229

is acctually the processes configuration that the system will use to create or use process tickets.

Any change that is made of the process (in the GUI) will require to re-synchronize the cache file in order to get the change reflected in the system.

It is also possible to import the whole process from a YAML file, but it is still necessary to create all Dynamic Fields, Users, Queues, etc that are needed by each process before the import.

Notice that if the process requires the use of ACLs those are also needed to be set manually.

Im folgenden sehen Sie die komplette YAML-Datei für den Buchbestellprozess:

---

Activities:

A1:

ActivityDialogs:

- AD1

ChangeTime: 2012-11-23 14:49:22

Config:

ActivityDialog:

1: AD1

CreateTime: 2012-11-23 11:49:38

EntityID: A1

ID: 151

Name: Recording the demand

A2:

ActivityDialogs:

- AD2

- AD3

ChangeTime: 2012-12-13 00:55:12

Config:

ActivityDialog:

1: AD2

2: AD3

CreateTime: 2012-11-23 11:50:11

EntityID: A2

ID: 152

Name: Approval

A3:

ActivityDialogs:

- AD4

- AD5

ChangeTime: 2012-11-23 18:12:14

Config:

ActivityDialog:

1: AD4

2: AD5

CreateTime: 2012-11-23 11:50:35

EntityID: A3

ID: 153

Name: Order

A4:

ActivityDialogs:

- AD6

ChangeTime: 2012-11-23 18:12:35

Config:

ActivityDialog:

1: AD6

CreateTime: 2012-11-23 11:51:00

EntityID: A4

ID: 154

Name: Incoming

A5:

ActivityDialogs: []

ChangeTime: 2012-11-23 11:51:33

Config: {}

230

CreateTime: 2012-11-23 11:51:33

EntityID: A5

ID: 155

Name: Process complete

ActivityDialogs:

AD1:

ChangeTime: 2012-12-06 02:16:21

Config:

DescriptionLong: ''

DescriptionShort: Recoding the demand

FieldOrder:

- DynamicField_Author

- DynamicField_ISBN

- DynamicField_Title

- DynamicField_Status

Fields:

DynamicField_Author:

DefaultValue: ''

DescriptionLong: ''

DescriptionShort: ''

Display: 1

DynamicField_ISBN:

DefaultValue: ''

DescriptionLong: ''

DescriptionShort: ''

Display: 1

DynamicField_Status:

DefaultValue: ''

DescriptionLong: ''

DescriptionShort: ''

Display: 1

DynamicField_Title:

DefaultValue: ''

DescriptionLong: ''

DescriptionShort: ''

Display: 1

Interface:

- AgentInterface

Permission: ''

RequiredLock: 0

SubmitAdviceText: ''

SubmitButtonText: ''

CreateTime: 2012-11-23 14:34:43

EntityID: AD1

ID: 154

Name: Recording the demand

AD2:

ChangeTime: 2012-11-23 14:57:41

Config:

DescriptionLong: ''

DescriptionShort: Approval denied

FieldOrder:

- Article

- DynamicField_Status

Fields:

Article:

Config:

ArticleType: note-internal

DefaultValue: ''

DescriptionLong: ''

DescriptionShort: ''

Display: 1

DynamicField_Status:

DefaultValue: ''

DescriptionLong: ''

DescriptionShort: ''

Display: 1

Interface:

- AgentInterface

Permission: ''

RequiredLock: 0

SubmitAdviceText: ''

231

SubmitButtonText: Deny Request

CreateTime: 2012-11-23 14:36:39

EntityID: AD2

ID: 155

Name: Approval denied

AD3:

ChangeTime: 2012-12-14 03:14:23

Config:

DescriptionLong: ''

DescriptionShort: Approved

FieldOrder:

- DynamicField_Status

Fields:

DynamicField_Status:

DefaultValue: ''

DescriptionLong: ''

DescriptionShort: ''

Display: 1

Interface:

- AgentInterface

Permission: ''

RequiredLock: 0

SubmitAdviceText: ''

SubmitButtonText: Approve Request

CreateTime: 2012-11-23 14:37:35

EntityID: AD3

ID: 156

Name: Approved

AD4:

ChangeTime: 2012-11-23 14:58:52

Config:

DescriptionLong: ''

DescriptionShort: Order rejected

FieldOrder:

- Article

- DynamicField_Status

Fields:

Article:

Config:

ArticleType: note-internal

DefaultValue: ''

DescriptionLong: ''

DescriptionShort: ''

Display: 1

DynamicField_Status:

DefaultValue: ''

DescriptionLong: ''

DescriptionShort: ''

Display: 1

Interface:

- AgentInterface

Permission: ''

RequiredLock: 0

SubmitAdviceText: ''

SubmitButtonText: Reject Order

CreateTime: 2012-11-23 14:38:48

EntityID: AD4

ID: 157

Name: Order rejected

AD5:

ChangeTime: 2012-12-06 02:20:12

Config:

DescriptionLong: ''

DescriptionShort: Order placed

FieldOrder:

- DynamicField_DeliveryDate

- DynamicField_Price

- DynamicField_Supplier

- DynamicField_Status

Fields:

DynamicField_DeliveryDate:

DefaultValue: ''

232

DescriptionLong: ''

DescriptionShort: ''

Display: 1

DynamicField_Price:

DefaultValue: ''

DescriptionLong: ''

DescriptionShort: ''

Display: 1

DynamicField_Status:

DefaultValue: ''

DescriptionLong: ''

DescriptionShort: ''

Display: 1

DynamicField_Supplier:

DefaultValue: ''

DescriptionLong: ''

DescriptionShort: ''

Display: 1

Interface:

- AgentInterface

Permission: ''

RequiredLock: 0

SubmitAdviceText: ''

SubmitButtonText: Place Order

CreateTime: 2012-11-23 14:41:28

EntityID: AD5

ID: 158

Name: Order placed

AD6:

ChangeTime: 2012-11-23 14:42:43

Config:

DescriptionLong: ''

DescriptionShort: Shipment received

FieldOrder:

- DynamicField_DateOfReceipt

- DynamicField_Status

Fields:

DynamicField_DateOfReceipt:

DefaultValue: ''

DescriptionLong: ''

DescriptionShort: ''

Display: 1

DynamicField_Status:

DefaultValue: ''

DescriptionLong: ''

DescriptionShort: ''

Display: 1

Interface:

- AgentInterface

Permission: ''

RequiredLock: 0

SubmitAdviceText: ''

SubmitButtonText: ''

CreateTime: 2012-11-23 14:42:43

EntityID: AD6

ID: 159

Name: Shipment received

Process:

Activities:

- A1

- A2

- A3

- A4

- A5

ChangeTime: 2012-12-06 02:31:59

Config:

Description: The process to order a book

Path:

A1:

T1:

ActivityEntityID: A2

TransitionAction:

233

- TA2

- TA1

A2:

T2:

ActivityEntityID: A5

TransitionAction:

- TA3

- TA4

- TA8

T3:

ActivityEntityID: A3

TransitionAction:

- TA5

A3:

T4:

ActivityEntityID: A5

TransitionAction:

- TA3

- TA4

- TA8

T5:

ActivityEntityID: A4

TransitionAction:

- TA6

A4:

T6:

ActivityEntityID: A5

TransitionAction:

- TA3

- TA4

- TA7

A5: {}

StartActivity: A1

StartActivityDialog: AD1

CreateTime: 2012-11-23 11:45:12

EntityID: P1

ID: 94

Layout:

A1: left: 172 top: 63

A2: left: 402 top: 156

A3: left: 649 top: 255

A4: left: 774 top: 391

A5: left: 194 top: 410

Name: Book ordering

State: Active

StateEntityID: S1

TransitionActions:

- TA1

- TA2

- TA3

- TA4

- TA8

- TA5

- TA3

- TA4

- TA8

- TA6

- TA3

- TA4

- TA7

Transitions:

- T1

234

- T2

- T3

- T4

- T5

- T6

TransitionActions:

TA1:

ChangeTime: 2012-11-23 16:01:37

Config:

Queue: Management

Module: Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet

CreateTime: 2012-11-23 15:50:59

EntityID: TA1

ID: 61

Name: Move the process ticket into the "Management" queue

TA2:

ChangeTime: 2012-11-23 16:02:12

Config:

Responsible: manager

Module: Kernel::System::ProcessManagement::TransitionAction::TicketResponsibleSet

CreateTime: 2012-11-23 15:58:22

EntityID: TA2

ID: 62

Name: Change ticket responsible to "manager"

TA3:

ChangeTime: 2012-11-24 14:27:02

Config:

Queue: Employees

Module: Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet

CreateTime: 2012-11-23 16:02:54

EntityID: TA3

ID: 63

Name: Move the process ticket into the "Employees" queue

TA4:

ChangeTime: 2012-11-23 16:04:06

Config:

Responsible: Employee

Module: Kernel::System::ProcessManagement::TransitionAction::TicketResponsibleSet

CreateTime: 2012-11-23 16:04:06

EntityID: TA4

ID: 64

Name: Change ticket responsible to "Employee"

TA5:

ChangeTime: 2012-12-06 02:18:34

Config:

Queue: Purchasing

Module: Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet

CreateTime: 2012-11-23 16:04:54

EntityID: TA5

ID: 65

Name: Move process ticket into the "Purchasing" queue

TA6:

ChangeTime: 2012-12-06 02:18:48

Config:

Queue: Post office

Module: Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet

CreateTime: 2012-11-23 16:06:20

EntityID: TA6

ID: 66

Name: Move process ticket into the "Post office" queue

TA7:

ChangeTime: 2012-12-06 02:29:55

Config:

State: closed successful

Module: Kernel::System::ProcessManagement::TransitionAction::TicketStateSet

235

CreateTime: 2012-12-06 02:29:27

EntityID: TA7

ID: 67

Name: Close ticket successfully

TA8:

ChangeTime: 2012-12-06 02:31:12

Config:

State: closed unsuccessful

Module: Kernel::System::ProcessManagement::TransitionAction::TicketStateSet

CreateTime: 2012-12-06 02:31:12

EntityID: TA8

ID: 68

Name: Close ticket unsuccessfully

Transitions:

T1:

ChangeTime: 2012-11-23 15:12:20

Config:

Condition:

Fields:

DynamicField_Status:

Match: Approval

Type: String

Type: and

ConditionLinking: and

CreateTime: 2012-11-23 11:53:52

EntityID: T1

ID: 94

Name: Approval

T2:

ChangeTime: 2012-11-23 15:12:50

Config:

Condition:

Fields:

DynamicField_Status:

Match: Approval denied

Type: String

Type: and

ConditionLinking: and

CreateTime: 2012-11-23 11:54:26

EntityID: T2

ID: 95

Name: Approval denied

T3:

ChangeTime: 2012-11-23 15:13:29

Config:

Condition:

Fields:

DynamicField_Status:

Match: Approved

Type: String

Type: and

ConditionLinking: and

CreateTime: 2012-11-23 11:54:54

EntityID: T3

ID: 96

Name: Approved

T4:

ChangeTime: 2012-11-23 15:14:08

Config:

Condition:

Fields:

DynamicField_Status:

Match: Order denied

Type: String

Type: and

ConditionLinking: and

CreateTime: 2012-11-23 11:55:25

236

EntityID: T4

ID: 97

Name: Order denied

T5:

ChangeTime: 2012-11-23 18:30:33

Config:

Condition:

Fields:

DynamicField_Status:

Match: Order placed

Type: String

Type: and

ConditionLinking: and

CreateTime: 2012-11-23 11:56:15

EntityID: T5

ID: 98

Name: Order placed

T6:

ChangeTime: 2012-11-23 15:15:30

Config:

Condition:

Fields:

DynamicField_Status:

Match: Shipment received

Type: String

Type: and

ConditionLinking: and

CreateTime: 2012-11-23 11:56:48

EntityID: T6

ID: 99

Name: Shipment received

2.4. Prozesskonfigurationsempfehlung

2.4.1. Prozess

Ein Prozess modelliert den Pfad eines Workflows/Prozess. Die Wegpunkte auf diesem Pfad können Aktivitäten oder Übergänge sein. Auf diese wird später noch genauer eingegangen.

2.4.1.1. Prozesskonfiguration

Die Prozesskonfiguration kann in der Datei Kernel/Config.pm vorgenommen werden, aber es wird dringend empfohlen neue Dateien, wie Kernel/Config/Files/

MeinProzess.pm

, zu erstellen. Beachten Sie das die GUI die Datei Kernel/Config/File/

ZZZProcessManagement automatisch generiert, somit sollte dieser Dateiname nicht für eigene Prozesse verwendet werden. Andererseits wird diese Datei überschrieben, sobald

Sie Prozesse synchronisieren. Anbei eine Beispielprozesskonfiguration (aus dem Prozesscache):

$Self->{'Process'} = {

'P1' => {

Name => 'Book order',

CreateTime => '16-02-2012 13:37:00',

CreateBy => '1',

ChangeTime => '17-02-2012 13:37:00',

ChangeBy => '1',

State => 'Active',

StartActivity => 'A1',

StartActivityDialog => 'AD1',

Path => {

'A1' => {

'T1' => {

ActivityEntityID => 'A2',

237

'A2' => {

'T2' => {

ActivityEntityID => 'A3',

'P2' => {

Name => 'IT order',

CreateTime => '26-02-2012 13:37:00',

CreateBy => '1',

ChangeTime => '27-02-2012 13:37:00',

ChangeBy => '1',

State => 'Active',

StartActivity => 'A2',

StartActivityDialog => 'AD2',

Path => {

'A2' => {

'T3' => {

ActivityEntityID => 'A4',

}

};

2.4.1.2. Name

Der Name des Prozesses, dieser kann vom Agenten ausgewählt werden, wenn ein neues

Prozessticket erstellt wird.

2.4.1.3. CreateTime

Die Zeit, wann der Prozess erstellt wurde.

2.4.1.4. CreateBy

Die UID des Users, der den Prozess erstellt hat.

2.4.1.5. ChangeTime

Die Zeit, wann der Prozess zuletzt geändert wurde.

2.4.1.6. ChangeBy

Die UID des Users, der den Prozess zuletzt bearbeitet hat.

2.4.1.7. State

Definiert den Status eines Prozesses. Möglich Werte sind:

• 'Active' sind alle Prozesse, welche in neuen Prozesstickets genutzt werden können.

• 'FadeAway' sind Prozesse, welche nicht mehr für neue Tickets genutzt werden können, aber bereits existierende Tickets können diesen Prozess immer noch ausführen.

• 'Inactive' Prozesse sind deaktiviert und können nicht neue und bereits existierende

Tickets genutzt werden.

2.4.1.8. StartActivity

Wenn ein neues Prozessticket erstellt wird, muss eine Startaktivität definiert werden.

Sobald das Ticket erstellt wurde, wird diese Aktivität gesetzt und als Basis für die erste

Prüfung des Übergangs genutzt.

238

2.4.1.9. StartActivityDialog

Für neue Prozesstickets muss ein StartActivityDialog definiert werden. Dieser wird angezeigt, wenn ein neues Prozessticket erstellt wird (nachdem der Prozess ausgewählt wurde). Das Ticket existiert noch nicht, wird aber nach Übermittlung des StartActivityDialog erstellt.

2.4.1.10. Pfad

Der Pfad beinhaltet die aktuelle Prozessstruktur der Aktivitäten und möglichen Übergänge zwischen ihnen.

'A1' => {

'T1' => {

ActivityEntityID => 'A2',

'T2' => {

ActivityEntityID => 'A3',

'T3' => {

ActivityEntityID => 'A4',

TransitionAction => ['TA1', 'TA2'],

Wenn ein Prozessticket in Aktivität 'A1' ist, hat es 3 mögliche Wege um zu einer anderen

Aktivität zugelangen. In den Übergängen 'T1' bis 'T3' wurden Bedingungen festgelegt, die ein Prozessticket erfüllen muss um zu einer anderen Aktivität zu gelangen.

If in this case all the values of the process ticket and its dynamic fields that are needed for the Transition 'T2' are correct, the ticket will be moved from Activity 'A1' to 'A3'. After an ActivityDialog is submitted, or any other change is made to a ticket, it will be checked for possible Transitions from the current Activity. If multiple Transitions are possible, the first one will be used (based on nummerical sorting of the TransitionIDs).

Additionally, it is possible to assign Transition Actions to Transitions in the Path configuration. These are modules which are executed after a successful Transition. They have to be specified in array form as in the example, we'll talk about the details later.

2.4.2. Aktivität

An Activity contains one or more Activity Dialogs and models a 'step' in the process. All

Activity Dialogs of the current Activity are displayed in the ticket zoom and can be used until the conditions of a Transition are fulfilled.

2.4.2.1. Aktivitäts-Konfiguration

Hier sehen Sie eine Beispiel Aktivitätskonfiguration:

$Self->{'Process::Activity'} =

{

'A1' => {

Name => 'Activity 1 optional',

CreateTime => '16-02-2012 13:37:00',

CreateBy => '1',

ChangeTime => '17-02-2012 13:37:00',

ChangeBy => '1',

ActivityDialog => {

1 => 'AD1',

'A2' => {

Name => 'Activity 2 optional',

239

CreateTime => '16-02-2012 13:37:00',

CreateBy => '1',

ChangeTime => '17-02-2012 13:37:00',

ChangeBy => '1',

ActivityDialog => {

1 => 'AD5',

2 => 'AD6',

3 => 'AD1',

};

2.4.2.2. Name

Der Name der Aktivität.

2.4.2.3. CreateTime

Die Erstellzeit.

2.4.2.4. CreateBy

Die UID des Benutzers, der die Aktivität erstellt hat.

2.4.2.5. ChangeTime

Die letzte Änderung.

2.4.2.6. ChangeBy

Die UID des Benutzers, der die letzte Aktivitätsänderung gemacht hat.

2.4.2.7. Aktivitäts-Dialog

Activity Dialog contains the list of Activity Dialogs which are available in this Activity. All

Activity Dialogs of the current Activity are displayed in the ticket zoom. Their order is set by the order in the configuration, here 'AD5' is shown before 'AD6' and 'AD1'.

2.4.3. Aktivitäts-Dialog

An Activity Dialog is a particular screen and can be used in different Activities.

2.4.3.1. Aktivitätsdialog-Konfiguration

Hier sehen Sie eine Beispiel Konfiguration:

$Self->{'Process::ActivityDialog'} = {

'AD1' => {

Name => 'ActivityDialog 1 optional',

DescriptionShort => 'Basic info',

DescriptionLong => 'Please insert the necessesary basic information for IT orders',

CreateTime => '28-02-2012 13:37:00',

CreateBy => '1',

ChangeTime => '29-02-2012 13:37:00',

ChangeBy => '1',

Fields => {

PriorityID => {

DescriptionShort => 'Priority ID',

DescriptionLong => 'Enter the priority here',

Display => 2,

FieldOrder => [ 'PriorityID' ],

SubmitAdviceText => 'Note: If you submit the form...',

SubmitButtonText => 'Send request',

240

'AD2' => {

Name => 'ActivityDialog 2 optional',

DescriptionShort => 'Basic info',

DescriptionLong => 'Please insert the necessesary basic information for Book orders',

CreateTime => '28-02-2012 13:37:00',

CreateBy => '1',

ChangeTime => '29-02-2012 13:37:00',

ChangeBy => '1',

Fields => {

StateID => {

DescriptionShort => 'State ID',

DescriptionLong => 'Enter the state here',

Display => 2,

DefaultValue => '2',

Queue => {

DescriptionShort => 'Queue ID',

DescriptionLong => 'Enter the queue here',

Display => 2,

DefaultValue => 'Raw',

Title => {

DescriptionShort => 'Title',

DescriptionLong => 'Enter the title here',

Display => 1,

DefaultValue => 'Default Title',

DynamicField_Anzahl => {

DescriptionShort => 'Amount',

DescriptionLong => 'Enter the amount here',

Display => 2,

DefaultValue => '4',

FieldOrder => [ 'DynamicField_Anzahl', 'StateID', 'Queue', 'Title' ],

SubmitAdviceText => 'Note: If you submit the form...',

SubmitButtonText => 'Send request',

};

2.4.3.2. Name

Name des Aktivitäts-Dialog.

2.4.3.3. CreateTime

Die Zeit, wann er erstellt wurde.

2.4.3.4. CreateBy

Die UID des Benutzers, der den Aktivitätendialog erstellt hat.

2.4.3.5. ChangeTime

Die letzte Änderung

2.4.3.6. ChangeBy

Die UID des Benutzers, der die letzte Änderung an diesem Aktivitätsdialog gemacht hat.

2.4.3.7. Felder

Beinhaltet alle Felder, welche in diesem Aktivitätsdialog angezeigt werden können. Die folgenden Felder können zurzeit benutzt werden:

Title

241

State

StateID

Priority

PriorityID

Lock

LockID

Queue

QueueID

Customer

CustomerID

CustomerNo

CustomerUserID

Owner

OwnerID

Type

TypeID

SLA

SLAID

Service

ServiceID

Responsible

ResponsibleID

PendingTime

DynamicField_$FieldName # for all dynamic fields

Beispielkonfiguration eines einfachen Feldes:

StateID => {

DescriptionShort => 'State ID',

DescriptionLong => 'Enter the state here',

Display => 2,

DefaultValue => '2',

The field "Article" is a special case. If it is present in a "Fields" configuration, the Activity

Dialog will contain a complete Richtext editor with subject field and attachment handling.

The entered text will then be added to the ticket as an article and sent by email. Let's see an example Article field configuration:

Article => {

DescriptionShort => 'Please insert your comment here.',

DescriptionLong => '',

Display => 1,

Config => {

ArticleType => 'note-internal',

LabelSubject => '',

LabelBody => '',

Werfen wir einen Blick auf die Optionen der Konfigurationsfelder:

2.4.3.7.1. Beschreibung (kurz)

Optionale Kurzbeschreibung, welche im Titel des Feldes angezeigt wird.

2.4.3.7.2. Beschreibung (lang)

Optionale längere Beschreibung, welche bei MouseOver über dem Feld angezeigt wird.

Zum Beispiel Hinweise, wie das Feld ausgefüllt werden soll.

2.4.3.7.3. Anzeige

Steuert, ob das Feld angezeigt und/oder verpflichtend ist. Möglich Werte:

• '0': Das Feld ist unsichtbar. Das kann hilfreich sein, wenn Feld-Werte automatisch gesetzt werden sollen. Der konfigurierte Standard-Wert wird in diesem Fall gespeichert.

242

• '1': Das Feld ist sichtbar, aber optional.

• '2': Das Feld ist sichtbar und verpflichtend. Die folgenden Felder können nur unsichtbar oder verpflichtend sein:

QueueID

Queue

State

StateID

Lock

LockID

Priority

PriorityID

Type

TypeID

Wenn Felder als optional konfiguriert sind und kein Wert vom Benutzer eingegeben wurde, wird der Standard-Wert übernommen, wenn der Aktivitätsdialog vom Benutzer übermittelt wurde.

2.4.3.7.4. Standard-Wert

For fields with 'ID' (like QueueID, OwnerID), this refers to the database ID of the value.

For other fields without 'ID' (like Queue, Owner), the DefaultValue must contain the value itself. Example:

Queue => {

DescriptionShort => 'Queue',

DescriptionLong => 'Hier die Queue eingeben',

Display => 2,

DefaultValue => 'Raw',

2.4.3.8. Feldreihenfolge

Here the display order of the fields is configured. IMPORTANT: Invisible fields also must be configured here, because only configured fields will be considered when saving. Fields which are not configured will not be saved.

2.4.3.9. SubmitAdviceText

Optional text to be shown right above the submit button for additional help or advice text.

2.4.3.10. SubmitButtonText

Optionaler Text für den "Übermitteln" Button

2.4.4. Übergang

A Transition decides - based on configurable conditions - which path in the Process is taken, i. e. to which Activity a Process ticket can be moved.

2.4.4.1. Übergangs-Konfiguration

Hier sehen Sie ein Beispiel:

$Self->{'Process::Transition'} = {

'T1' => {

Name => 'Transition 1',

CreateTime => '14-03-2012 13:37:00', # optional

CreateBy => '1', # optional

ChangeTime => '15-03-2012 13:37:00', # optional

243

ChangeBy => '15-03-2012 13:37:00', # optional

Condition => {

Cond1 => {

Fields => {

StateID => {

Type => 'String',

Match => '1',

'T2' => {

Name => 'Transition 2 optional',

CreateTime => 'DATE', # optional

CreateBy => 'USERID', # optional

ChangeTime => 'DATE', # optional

ChangeBy => 'USERID', # optional

Condition => {

Cond1 => {

Queue => 'Raw',

DynamicField_Farbe => '2',

DynamicField_Anzahl => '1',

};

2.4.4.2. Name

Name des Übergangs.

2.4.4.3. CreateTime

Die Zeit, wann er erstellt wurde.

2.4.4.4. CreateBy

Die UID des Benutzers, der den Übergang erstellt hat.

2.4.4.5. ChangeTime

Die letzte Änderung

2.4.4.6. ChangeBy

UID des Users, der den Übergang geändert hat.

2.4.4.7. Bedingung

Beinhaltet alle Bedingungen, die notwendig sind, damit der Übergang wirksam ist. Beispiel:

Condition => {

Type => 'and',

Cond1 => {

Type => 'and',

Fields => {

StateID => {

Type => 'String',

Match => '1',

DynamicField_Marke => {

Type => 'String',

Match => 'VW',

244

Cond2 => {

Type => 'and',

Fields => {

Queue => {

Type => 'String',

Match => 'Raw',

Werfen wir einen Blick auf den Zustand der Konfiguration im Detail.

2.4.4.7.1. Typ (Bedingung)

Specifies the way the different condition elements are connected to each other. Possible values:

• 'UND': Das ist der Standard. Alle Bedingungen müssen erfüllt sein damit der Übergang angewendet wird.

• 'ODER': Mindestens eine Bedingung muss erfüllt sein.

• 'XOR': Genau eine Bedingung muss erfüllt sein, nicht mehr.

2.4.4.7.2. Cond1

This is the name of an example condition. It can be freely chosen. Conditions are evaluated in sorted order.

2.4.4.7.3. Typ (Cond)

Specifies the way how the individual field tests of this condition are connected to each other. Possible values:

• 'UND': Das ist der Standard. Alle Feldtests müssen erfüllt sein damit die Bedingung erfüllt ist.

• 'ODER': Mindestens ein Feldtest muss erfüllt sein.

• 'XOR': Genau ein Feldtest muss erfüllt sein, nicht mehr.

2.4.4.7.4. Felder

Specifies the particular fields whose values should be tested. From our example:

Fields => {

StateID => {

Type => 'String',

Match => '1',

2.4.4.7.5. StateID

Beispiel für einen Feldnamen. Die folgenden Ticketfelder können verwendet werden:

Title

State

StateID

Priority

PriorityID

Lock

245

LockID

Queue

QueueID

Customer

CustomerID

CustomerNo

CustomerUserID

Owner

OwnerID

Type

TypeID

SLA

SLAID

Service

ServiceID

Responsible

ResponsibleID

DynamicField_$FieldName # for all DynamicFields

Beim Testen eines Feldes mit "ID" (wie SLAID), wird die Datenbank-ID des Feldes für die

Prüfung verwendet werden, für andere Bereiche (wie SLA) wird der Ist-Wert für den Test verwendet.

2.4.4.7.6. Typ

Bestimmt die Art der Feldtests. Mögliche Werte:

• 'String': Vergleicht den Feldwert mit der in 'Match' angegebene Zeichenfolge. Stimmt

überein, wenn sie genau gleich sind.

• 'Hash': Vergleicht den Feldwert (Hash) mit dem in 'Match' angegebenen Hash. Alle Hash-

Werte müssen identisch sein.

• 'Array': Vergleicht den Wert des Feldes (Array) mit dem in 'Match' angegebene Array.

Beide Listen müssen gleich sein.

• 'Regex': The field value can be tested with a regular expression. It is important that

'Match' contains qr{}xms as a base condition. Between the braces the actual regular expression can be noted.

• 'Module': Allows you to use a perl module for condition checking. If it returns 1, the check was positive. You can find an example module in Kernel/System/ProcessManagement/TransitionValidation/ValidateDemo.pm

2.4.5. Übergangs-Aktionen

Transition Actions are actions which can be triggered after successfully applied transitions

(when a process ticket moves from one activity to another). These Transition Actions can be used to perform different changes on the ticket, e. g. change the Queue or the Owner of the ticket, and you can also create your own Transition Actions to perform other complex changes.

2.4.5.1. Übergangs-Aktionen-Konfiguration

Hier sehen Sie ein Beispiel:

$Self->{'Process::TransitionAction'} = {

'TA1' => {

Name => 'Queue Move',

Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet',

Config => {

Queue => 'Junk',

UserID => 123,

246

};

2.4.5.2. Name

Name der Übergangs-Aktion

2.4.5.3. Modul

Spezifiziert das Perl-Modul, welches benutzt werden soll.

2.4.5.4. Konfiguration

This parameter contains all settings which are required for the module. Its content depends on the particular Transition Action module which is used. Please see the documentation of the individual modules for details. In our example, only the Queue must be specified, Nevertheless we are also sending UserID parameter, by using the UserID parameter, the transition action will be executed impersonating the user with the given

UserID.

The use of UserID inside the "Config" parameter of a Transition Action is accepted by all

Transition Actions (since OTRS 3.2.4), in this example it could be particularly important if the user that triggers the Transition does not have permissions to move the ticket to the queue 'Junk', while the user with the UserID 123 might have.

2.4.5.5. Wiederverwendung von Übergangs-Aktionsmodulen

To use Transition Action modules multiple times, just specify several TransitionActions in your configuration. Example:

$Self->{'Process::TransitionAction'} = {

'TA1' => {

Name => 'Queue Move Junk',

Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet',

Config => {

Queue => 'Junk',

'TA2' => {

Name => 'Queue Move Raw',

Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet',

Config => {

Queue => 'Raw',

};

Here the same module is used to move a process ticket into the 'Raw' queue, and another time to move it into the junk queue. The Transition Action which must be used for a particular Transition is determined from the 'Path' setting of the Process configuration.

2.4.5.6. Verfügbare Übergangs-Aktionen

OTRS comes with several Transition Actions that can be used in your processes. Here you can find their documentation and how they need to be configured.

2.4.5.6.1. DynamicFieldSet

Fügt eins oder mehrere dynamischen Felder an ein Prozessticket an. Beispiel:

247

$Self->{'Process::TransitionAction'} = {

'TA1' => {

Name => 'Set DynamicField Master to Master and Approved to 1',

Module => 'Kernel::System::ProcessManagement::TransitionAction::DynamicFieldSet',

Config => {

MasterSlave => 'Master',

Approved => '1',

};

'Name' definiert den Namen der konfigurierten Übergangsaktion.

'MasterSlave' and 'Approved' are given as examples of DynamicField names. The values of the fields ('Master' and '1') will be set by this TransitionAction.

2.4.5.6.2. TicketArticleCreate

Erzeugt einen Artikel und wird verwendet um Notizen oder E-Mail Antworten erzeugen.

Beispiel:

$Self->{'Process::TransitionAction'} = {

'TA1' => {

Name => 'Article Create Note Internal',

Module =>

'Kernel::System::ProcessManagement::TransitionAction::TicketArticleCreate',

Config => {

ArticleType => 'note-internal', #

note-external|phone|fax|sms|...

excluding any email type

SenderType => 'agent', #

agent|system|customer

ContentType => 'text/plain; charset=ISO-8859-15', # or

optional Charset & MimeType

Subject => 'some short description', #

required

Body => 'the message text', #

required

HistoryType => 'OwnerUpdate', #

HistoryComment => 'Some free text!',

From => 'Some Agent <[email protected]>', #

not required but useful

To => 'Some Customer A <[email protected]>', #

not required but useful

Cc => 'Some Customer B <[email protected]>', #

not required but useful

ReplyTo => 'Some Customer B <[email protected]>', #

not required

InReplyTo => '<[email protected]>', #

not required but useful

References => '<[email protected]> <[email protected]>', #

not required but useful

NoAgentNotify => 0, # if

you don't want to send agent notifications

AutoResponseType => 'auto reply', #

auto reject|auto follow up|auto reply/new ticket|auto remove

ForceNotificationToUserID => [ 1, 43, 56 ], # if

you want to force somebody

ExcludeNotificationToUserID => [ 43, 56 ],

# if you want full exclude somebody from notfications,

# will also be removed in To: line of article,

# higher prio as ForceNotificationToUserID

ExcludeMuteNotificationToUserID => [ 43, 56 ],

# the same as ExcludeNotificationToUserID but only the

# sending gets muted, agent will still shown in To:

248

# line of article

};

'Name' specifies the name of the configured TransitionAction. It can be freely chosen, but should reflect the purpose of the configured action.

'ArticleType' defines the type of the article to be created. Possible values: phone, fax, sms, webrequest, note-internal, note-external and note-report.

SenderType definiert den Absendertyp des Artikel. Mögliche Werte sind: Agent, System,

Customer.

'ContentType' defines the content type of the article. Possible values: 'text/plain; charset=ISO-8859-15' or any other valid charset and mime type.

'Betreff' definiert den Artikeltitel. Verfplichtend.

'Body' definiert den Artikelinhalt. Verpflichtend

Der Historientyp definiert den Typ des Historieneintrages. Mögliche Werte sind: AddNote, ArchiveFlagUpdate, Bounce, CustomerUpdate, EmailAgent, EmailCustomer, EscalationResponseTimeNotifyBefore, EscalationResponseTimeStart, EscalationResponseTimeStop, EscalationSolutionTimeNotifyBefore, EscalationSolutionTimeStart, EscalationSolutionTimeStop, EscalationUpdateTimeNotifyBefore, EscalationUpdateTimeStart, EscalationUpdateTimeStop, FollowUp, Forward, Lock, LoopProtection, Merged, Misc, Move, New-

Ticket, OwnerUpdate, PhoneCallAgent, PhoneCallCustomer, PriorityUpdate, Remove,

ResponsibleUpdate, SendAgentNotification, SendAnswer, SendAutoFollowUp, SendAutoReject, SendAutoReply, SendCustomerNotification, ServiceUpdate, SetPendingTime,

SLAUpdate, StateUpdate, Subscribe, SystemRequest, TicketDynamicFieldUpdate, Ticket-

LinkAdd, TicketLinkDelete, TimeAccounting, TypeUpdate, Unlock, Unsubscribe, WebRequestCustomer.

'HistoryContent' definiert den Inhalt von Historieneinträgen.

'Von', 'An', 'Cc' und 'ReplyTo' nehmen E-Mailadressen in der oben angegebenen Schreibweise.

'InReplyTo' und 'References' nehmen E-Mailnachrichten-IDs

'NoAgentNotify' - Ist dieser Wert auf 1 gesetzt, werden keine E-Mailbenachrichtigungen an Agenten verschickt.

'AutoResponseType' kann die folgenden Werte annehmen: Auto FollowUp, Auto-Reject,

Auto-Remove, Auto-Reply, Auto-Reply/New Ticket.

'ForceNotificationToUserID', 'ExcludeNotificationToUserID', 'ExcludeMuteNotificationToUserID' can take a list of UserIDs that are either always notified, not notified or listed as notified but not actually sent a notification email.

2.4.5.6.3. TicketCustomerSet

Legt den Kunden für ein Prozessticket fest. Beispiel:

$Self->{'Process::TransitionAction'} = {

'TA1' => {

Name => 'Customer Set Customer to test',

Module => 'Kernel::System::Process::TransitionAction::TicketCustomerSet',

Config => {

No => 'test',

User => 'client-user-123',

249

# or in other words

# CustomerID => 'client123',

# CustomerUserID => 'client-user-123',

};

'Name' definiert den Namen der konfigurierten Übergangsaktion.

No oder CustomerID setzt die Kundennummer des Kunden.

User oder CustomerUserID setzt den Benutzernamen des Kunden

2.4.5.6.4. TicketLockSet

Ändert die Sperre eines Prozessticket. Beispiel:

$Self->{'Process::TransitionAction'} = {

'TA1' => {

Name => 'Set Lock to lock',

Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketLockSet',

Config => {

Lock => 'lock',

# or

LockID => 2,

};

'Name' definiert den Namen der konfigurierten Übergangsaktion.

'Lock' definiert den neuen Sperrstatus des Prozesstickets.

'LockID' definiert die interne ID des neuen Sperrstatus.

2.4.5.6.5. TicketOwnerSet

Ändert den Besitzer eines Prozesstickets. Beispiel:

$Self->{'Process::TransitionAction'} = {

'TA1' => {

Name => 'Owner Set root@localhost',

Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketOwnerSet',

Config => {

Owner => 'root@localhost',

# or

OwnerID => 1,

};

'Name' definiert den Namen der konfigurierten Übergangsaktion.

'Owner' definiert den Loginnamen des neuen Beistzers.

'OwenerID' definiert die interne ID des neuen Besitzers.

2.4.5.6.6. TicketQueueSet

Verschiebt das Ticket in eine Ziel-Queue. Beispiel:

250

$Self->{'Process::TransitionAction'} = {

'TA1' => {

Name => 'Queue Move Raw',

Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet',

Config => {

Queue => 'Raw',

# or

# QueueID => '2',

};

'Name' definiert den Namen der konfigurierten Übergangsaktion.

'Queue' definiert den Namen der Ziel-Queue.

'QueueID' definiert die interne ID der Ziel-Queue.

2.4.5.6.7. TicketResponsibleSet

Ändert den Verantwortlichen eines Prozesstickets. Beispiel:

$Self->{'Process::TransitionAction'} = {

'TA1' => {

Name => 'Responsible Set root@localhost',

Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketResponsibleSet',

Config => {

Responsible => 'root@localhost',

# or

ResponsibleID => 1,

};

'Name' definiert den Namen der konfigurierten Übergangsaktion.

'Responsible' definiert den Loginnamen des neuen Verantwortlichen

'ResponsibleID' definiert die interne ID des neuen Verantwortlichen.

2.4.5.6.8. TicketServiceSet

Ordnet einem Prozessticket einen Service zu. Das Ticket benötigt einen Kunden und der

Service muss diesem Kunden zugeordnet sein. Beispiel:

$Self->{'Process::TransitionAction'} = {

'TA1' => {

Name => 'Set MyService service',

Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketServiceSet',

Config => {

Service => 'MyService',

# or

ServiceID => 123,

};

'Name' definiert den Namen der konfigurierten Übergangsaktion.

'Service' definiert den neuen Service des Prozesstickets. Es wird der vollständige Name des Service benötigt. (zum Beispiel: GramdFatherService::FatherService::SonService ).

'ServiceID' definiert die interne ID des neuen Services.

251

2.4.5.6.9. TicketSLASet

Ordnet eine Service-Level-Vereinbarung einem Prozessticket zu. Das Ticket muss einen

Service haben und das SLA muss diesem Service zugeordnet sein. Beispiel:

$Self->{'Process::TransitionAction'} = {

'TA1' => {

Name => 'Set MySLA SLA',

Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketSLASet',

Config => {

SLA => 'MyService',

# or

SLAID => 123,

};

'Name' definiert den Namen der konfigurierten Übergangsaktion.

'SLA' definiert die neue Service-Level-Vereinbarung des Prozesstickets.

'SLAID' definiert die interne ID des neuen SLA.

2.4.5.6.10. TicketStateSet

Ändert den Status eines Prozesstickets. Beispiel:

$Self->{'Process::TransitionAction'} = {

'TA1' => {

Name => 'Set State to open',

Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketStateSet',

Config => {

State => 'open',

# or

StateID => 4,

PendingTimeDiff => 123,

};

'Name' definiert den Namen der konfigurierten Übergangsaktion.

'State' definiert den neuen Status des Prozesstickets.

'StateID' definiert die interne ID des neuen Status.

'PendingTimeDiff' used only for pending type states, defines the time difference in seconds relative (relative to the Transition Action execution time) to set ticket pending time (e.g. 3600 means that the pending time is 1hr after the Transition Action is executed).

2.4.5.6.11. TicketTitleSet

Setzt den Tickettitel eines Prozesstickets. Beispiel:

$Self->{'Process::TransitionAction'} = {

'TA1' => {

Name => 'Set Ticket Title to Ticket-title',

Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketTitleSet',

Config => {

Title => 'Ticket-title',

252

};

'Name' definiert den Namen der konfigurierten Übergangsaktion.

'Title' definiert den neuen Titel des Tickets.

2.4.5.6.12. TicketTypeSet

Setzt den Tickettyp eines Prozesstickets. Beispiel:

$Self->{'Process::TransitionAction'} = {

'TA1' => {

Name => 'Set Ticket Type to default',

Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketTypeSet',

Config => {

Type => 'default',

# or

# TypeID => '1',

};

'Name' definiert den Namen der konfigurierten Übergangsaktion.

'Type' definiert den Namen des Tickettyps.

'TypeID' definiert die interne ID des Tickettyps.

2.4.6. Access Control Lists (ACLs)

Mit der Hilfe von ACLs, können Sie die auswählbaren Werte in Prozesstickets limitieren.

Weitere Beschreibungen der ACL-Syntax finden Sie in der ACL-Referenz

2.4.6.1. ACL Konfiguration

ACLs können nur in der Kernel/Config.pm definiert werden. Beispiel:

$Self->{TicketAcl}->{'001-ACL-ProcessProperties'} = {

Properties => {

Process => {

ProcessEntityID => ['P1'],

ActivityEntityID => ['A1'],

ActivityDialogEntityID => ['AD1'],

}

Possible => {

ActivityDialog => ['AD1', 'AD3'],

PossibleNot => {

ActivityDialog => ['AD3'],

};

2.4.6.2. 001-ACL-ProzessEigenschaften

Seit OTRS 2.0 können Access Control Lists (ACLs) verwendet werden, um den Zugriff auf

Tickets, Module, Queues, usw. zu steuern bzw. um in bestimmten Situationen Aktionen auf Tickets (schließen, verschieben, usw.) zu beeinflussen. ACLs können als Ergänzung zum bestehenden Berechtigungssystem der Rollen und Gruppen verwendet werden. Mit

ACLs lassen sich, basierend auf Ticket-Attributen, rudimentäre Workflows innerhalb des

Systems abbilden.

253

2.4.6.3. Prozess

This is the section that is used to check if an ACL must be applied. If it has the specified values, the rule is applied. The following values can be used:

2.4.6.3.1. ProcessEntityID

The ID of a process that the process. Matches if the ticket is assigned to this process.

2.4.6.3.2. ActivityEntityID

Die Nummer der Aktivität die dem Prozessticket aktuell zugeordnet ist.

2.4.6.3.3. ActivityDialogEntityID

Die Nummer des Aktivitätendialogs der dem Prozessticket aktuell zugeordnet ist.

2.4.6.4. Possible/PossibleNot Activity Dialog

Hier können Sie eine Liste von Aktivitätsdialogen-Nummern definieren. Diese Liste beschränkt die möglichen Aktivitätsdialoge die dem Agenten in der TicketZoom-Oberfläche angeboten werden.

'Möglich' listet die Aktivitätsdialoge auf, die erlaubt sind. Durch diese Einstellung wird nur

'AD1' und 'AD3' in der Liste der konfigurierten Aktivitätsdialoge angezeigt.

'Nicht Möglich' listet die Aktivitätsdialoge auf, die nicht erlaubt sind. Im oberen Beispiel wird diese Einstellung 'AD3' aus der Liste der konfigurierten Aktivitätsdialoge entfernen.

If both 'Possible' and 'PossibleNot' are specified, the list of configured Activity Dialogs will first be filtered by 'Possible', leaving only 'AD1' and 'AD3' in our example. Then 'Possible-

Not' will be applied and filter out 'AD3', so that only 'AD1' remains and is shown as a possible Activity Dialog that the user can use.

Wenn mehrere ACL-Regeln übereinstimmen, wird der Durchschnitt aller passenden Regeln berechnet um die möglichen Aktivitätsdialoge zu bestimmen. Beispiel:

Konfigurierte Aktivitätsdialoge: 'AD1', 'AD2', 'AD3', 'AD4', 'AD5', 'AD6', 'AD7'.

$Self->{TicketAcl}->{'001-ACL-Status'} = {

Properties => {

Ticket => {

Status => 'new',

}

Possible => {

ActivityDialog => ['AD1', 'AD2', 'AD3', 'AD6', 'AD7'],

};

$Self->{TicketAcl}->{'002-ACL-Queue'} = {

Properties => {

Ticket => {

Queue => ['Raw']

}

Possible => {

ActivityDialog => ['AD2', 'AD3', 'AD4', 'AD7'],

};

$Self->{TicketAcl}->{'003-ACL-Priority'} = {

Properties => {

Ticket => {

Priority => ['3 normal']

}

254

PossibleNot => {

ActivityDialog => ['AD3', 'AD4'],

};

Wenn ein Prozessticket den Zustand "Neu" hat, in der "Raw"-Queue ist und eine Priorität

"3 normal" hat, dann werden alle drei ACL-Regeln angewendet werden.

Die erste Regel reduziert die Aktivitätsdialoge von 'AD1', 'AD2', 'AD3', 'AD4', 'AD5', 'AD6',

'AD7' to 'AD1', 'AD2', 'AD3', 'AD6', 'AD7' und verbietet 'AD4' and 'AD5'.

Die zweite Regel reduziert die verbleibende Aktivitätsdialoge weiter. In unserem Beispiel werden 'AD2', 'AD3', 'AD 7' bleiben.

Nun wird die dritte Regel die Liste durch 'PossibleNot' weiter reduzieren. 'AD3' wird von der

Liste entfernt. 'AD4' wird nicht entfernt, da er in der Liste nicht an erster Stelle steht. Am

Ende bleiben 'AD2' und 'AD 7' als mögliche Aktivitätsdialoge, die der Benutzer verwenden kann.

It is also possible to limit the processes that can be displayed in the "New process ticket" screen, the functionality is similar to limiting the ActivityDialogs with one exception: The

ACLs could only be based on Users.

Siehe Beispiele:

$Self->{TicketAcl}->{'200-ACL-Process'} = {

# match properties

Properties => {

User => {

UserID => [2, 3],

Possible => {

Process => ['P1', 'P2', 'P3'],

PossibleNot => {

Process => ['P4'],

};

$Self->{TicketAcl}->{'201-ACL-Process'} = {

# match properties

Properties => {

User => {

Group_rw => [ 'MyGroup' ],

Possible => {

Process => ['P1', 'P2', 'P3'],

PossibleNot => {

Process => ['P4'],

};

$Self->{TicketAcl}->{'202-ACL-Process'} = {

# match properties

Properties => {

User => {

Role => [ 'MyRole' ],

Possible => {

255

Process => ['P1', 'P2', 'P3'],

PossibleNot => {

Process => ['P4'],

};

3. Erstellung eigener Themes

Für OTRS können verschiedene Themes angelegt werden, also verschiedene Layouts zur

Gestaltung der Web-Oberfläche. Dazu müssen Sie die vorhandenen Templates ändern und

Ihren Wünschen entsprechend anpassen.

More information on the syntax and structure of output templates can be found in the

Developer Manual at http://otrs.github.io/doc , especialy in the chapter on

templates

Führen Sie beispielsweise folgende Schritte durch um ein neues Theme namens "Company" zu erstellen:

1. Erstellen Sie das Verzeichnis Kernel/Output/HTML/Company und kopieren Sie die

Dateien, die Sie für das Company-Theme anpassen möchten, aus Kernel/Output/HTML/Standard in das neu erstellte Verzeichnis.

Wichtig

Kopieren Sie nur diejenigen Dateien, die Sie verändern möchten. Fehlende

Dateien wird OTRS automatisch vom Standard-Theme laden. Dadurch werden

Systemaktualisierungen vereinfacht.

2. Passen Sie die Dateien im Verzeichnis Kernel/Output/HTML/Company Ihren Wünschen entsprechend an.

3. To activate the new theme, add them in SysConfig under Frontend::Themes.

Ab nun sollten sie das neue Theme nutzen und über Ihre persönlichen Einstellungen akti-

vieren können.

Warnung

Nehmen Sie keine Änderungen an den Theme-Dateien vor, die mit OTRS installiert wurden, da diese bei einem Update verloren gehen können. Erstellen Sie eigene

Themes ausschließlich nach dem oben beschriebenen Verfahren.

4. Übersetzung des OTRS-Frontends

OTRS bietet Mehrsprachigkeit in der Weboberfläche an.

Procedures for localization for the OTRS framework, steps to be followed to create a new language translation, as well as procedures for translation customizations, can be found in the "Language Translations" chapter from the developer manual on http://otrs.github.io/ doc .

256

Kapitel 6.

Leistungsverbesserung

Presented below is a list of performance enhancing techniques for your OTRS installation, including configuration, coding, memory use, and more.

1. OTRS

Es gibt verschiedene Ansätze zur Leistungssteigerung von OTRS.

1.1. TicketIndexModule

Zur Verfügung stehen zwei Backend-Module für den Ticket Index:

• Kernel::System::Ticket::IndexAccelerator::RuntimeDB (Standard), generiere jede

Queue-Ansicht dynamisch aus der Ticket Tabelle. Sie werden keine Probleme mit der

Leistung bekommen bis zu etwa 60.000 Tickets (oder 6000 offenen) in Ihrem System.

• Kernel::System::Ticket::IndexAccelerator::StaticDB, das leistungsfähigste Modul. Es sollte ab 80.000 Tickets oder mehr als 6000 offenen eingesetzt werden. Benutzt eine extra ticket_index Tabelle, arbeitet wie eine Ansicht (View). Führen Sie bin/ otrs.RebuildTicketIndex.pl

zum erstmaligen Aufbau des Index aus.

Sie können den IndexAccelerator per SysConfig einstellen.

1.2. TicketStorageModule

Es stehen zwei Module für das Speichern der Tickets und Artikel bereit:

• Kernel::System::Ticket::ArticleStorageDB (Standard), speichert Anhänge u. A. in der

Datenbank. Merke: Benutzen Sie diese Option nicht für größere Systeme.

Pro: Ist der Benutzer, unter dem der Webserver läuft, nicht der Benutzer 'otrs', können

Sie mit diesem Modul Dateiberechtigungsprobleme vermeiden.

Contra: Es ist nicht wirklich ratsa,, Anhänge in Ihrer Datenbank zu speichern. Achten Sie darauf, dass Ihre Datenbank das kann. Für MySQL setzen Sie in dessen Konfiguration bspw. "set-variable = max_allowed_packet=8M", um 8 MB große Objekte zu speichern

(Standard ist 2M).

• Kernel::System::Ticket::ArticleStorageFS, speichert Anhänge u. A. im lokalen Filesystem ab. Merke: Benutzen Sie dies für große Installationen.

Pro: Schneller!

Con: Your web server user should be the 'otrs' user. Also, if you have multiple front-end servers, you should make sure the filesystem is shared between the servers. Place it on an NFS share or preferably a SAN or similar solution.

Note: you can switch from one back-end to the other on the fly. You can switch the backend in the SysConfig, and then run the command line utility otrs.ArticleStorageSwitch.pl

to put the articles from the database onto the filesystem or the other way around. You can use the -s and -d options to specify the source and destination back-ends. Please note that the entire process can take considerable time to run, depending on the number of articles you have and the available CPU power and/or network capacity.

shell> bin/otrs.ArticleStorageSwitch.pl -s ArticleStorageDB -d ArticleStorageFS

257

Skript: Wechsel des TicketStorage-Backends von Datenbank zu Dateisystem.

1.3. Tickets archivieren

Da OTRS als revisionssicheres System betrieben werden kann, ist das Löschen von geschlossenen Tickets möglicherweise nicht empfehlenswert. Daher haben wir eine Funktion implementiert, mit der Sie Tickets archivieren können.

Tickets that match certain criteria can be marked as "archived" These tickets are not accessed if you do a regular ticket search or run a Generic Agent job. The system itself does not have to deal with a huge amount of tickets any longer as only the "latest" tickets are taken into consideration when using OTRS. This can result in a huge performance gain on large systems.

Befolgen Sie folgende Schritte, um die Archivierungsfunktion zu nutzen:

1. Archivsystem in der SysConfig aktivieren

Wählen Sie in der SysConfig die Gruppe Ticket aus. In Core::Ticket finden Sie die

Option Ticket::ArchiveSystem, die standardmäßig auf "Nein" steht. Ändern Sie diese auf "Ja" und speichern Sie die Änderung ab.

2. Anlegen eines GenericAgent-Jobs

Wählen Sie im Administrationsbereich den "GenericAgent" aus und legen Sie dort einen neuen Job an.

a. Job-Einstellungen

Geben Sie dem Job einen geeigneten Namen und angemessene Optionen.

b. Ticket-Filter

Der Ticketfilter ist eine Ticketsuche, die Tickets nach bestimmten Kriterien auswählt.

Es könnte empfehlenswert sein, nur Tickets zu archivieren, die seit einigen Monaten im Status "geschlossen" sind.

c. Ticket-Aktion

Im Abschnitt "Ticket-Aktion" werden Sie eine Aktion "Ausgewählte Tickets archivieren" finden. Wählen Sie dort "Tickets archivieren" aus.

d. Job speichern

Am Ende der Seite finden Sie einen Knopf zum Speichern des Jobs.

e. Betroffene Tickets

Das System wird dann alle Tickets anzeigen, die beim Ausführen des GenericAgent-Jobs archiviert werden.

3. Ticketsuche

Wenn Sie nun nach Tickets suchen, werden standardmäßig nur Tickets gefunden, die nicht archiviert sind. Wenn Sie auch in archivierten Tickets suchen wollen, fügen Sie

"Archivsuche" zu Ihren Suchkriterien hinzu.

2. Datenbank

Einstellungen sind immer spezifisch für die jeweils eingesetzte Datenbank. Bei Problemen lesen Sie die Dokumentation und fragen Sie Ihren Datenbankadministrator.

258

2.1. MySQL

Wenn Sie den Tabellentyp MyISAM (Standard) benutzen, und einen großen Teil einer Tabelle gelöscht haben, oder wenn Sie sehr viele Änderungen an einer Tabelle mit Zeilen variabler Länge vorgenommen haben (Tabellen mit VARCHAR, BLOB oder TEXT Spalten), sollten Sie die Datendateien (Tabellen) mit dem "optimize" Kommando behandeln.

Dies bietet sich an, wenn MySQL viel CPU Zeit braucht. Optimieren Sie die Tabellen ticket, ticket_history und article.

shell$ mysql -u user -p database mysql$ optimize table ticket; mysql$ optimize table ticket_history; mysql$ optimize table article;

Skript: Optimierung von Datenbanktabellen.

2.2. PostgreSQL

PostgreSQL konfigurieren Sie am besten in der postgresql.conf Datei in Ihrem PostgreSQL

Datenverzeichnis. Hier gibt es Hilfe dazu:

• http://www.revsys.com/writings/postgresql-performance.html

• http://varlena.com/GeneralBits/Tidbits/perf.html

• http://varlena.com/GeneralBits/Tidbits/annotated_conf_e.html

Ist die Leistung immer noch nicht genügend, empfehlen wir, Fragen auf der "PostgreSQL

Performance Mailing Liste" ( http://www.postgresql.org/community/lists/ ) zu stellen. Die

Teilnehmer der PostgreSQL Liste sind sehr freundlich und können wahrscheinlich helfen.

3. Webserver

Natürlich empfehlen wir mod_perl 2.0 ( http://perl.apache.org/ ). Es ist sehr viel schneller

(etwa um den Faktor 100) als pures CGI, braucht aber auch mehr Speicher. Ihr httpd wird mit mod_perl also größer sein.

3.1. Persistente Datenbankverbindungen

Sie können die Datenbankverbindung bereits beim Start des Webservers herstellen lassen. Dies spart ebenso Zeit (siehe auch README.webserver).

3.2. Vorgeladene Module - startup.pl

Nutzen Sie das Start Skript scripts/apache2-perl-startup.pl, um die Perl Module vorzuladen (siehe README.webserver). Dadurch wird der Webserver schneller und braucht weniger Speicher.

3.3. Perl Module bei Änderung neu laden

Standardmäßig wird Apache::Reload in scripts/apache2-httpd.include.conf eingesetzt.

Deaktivieren Sie es und die Geschwindigkeit steigt um etwa 8%. Ab nun müssen Sie den

Webserver neu starten, wenn Sie irgendetwas ändern! Wichtig: Dies hat zur Folge, dass der OTRS-Paket-Manager nicht mehr über das Web-Interface bedient werden kann sondern nur noch auf der Kommandozeile - bin/otrs.PackageManager.pl.

259

3.4. Die richtige Strategie wählen

Bei wirklich großen Installationen (über 1000 neue Tickets am Tag, über 40 Agenten) ist es eine sehr gute Idee, den Artikel "Choosing the Right Strategy" (in englisch) zu lesen

( http://perl.apache.org/docs/1.0/guide/strategy.html

3.5. mod_gzip/mod_deflate

Falls Ihre Bandbreite ein wenig schmal sein sollte, benutzen Sie mod_deflate für Apache2. Eine HTML-Seite von 45k wird mod_gzip/mod_deflate auf etwa 7k zusammendrücken. Allerdings wird dadurch die Last auf dem Server erhöht.

260

Anhang A. Weitere Quellen

We try to support you with the very latest information about OTRS. We also give you an opportunity to provide us with your feedback.

1. Webseite OTRS Gruppe

You can find the website of the OTRS Group, the company behind OTRS, at

http:// www.otrs.com

. It contains a lot of product-related information, such as white papers, release notes, case studies and so on.

2. Mailinglisten

The Table A-1 displays our various community mailing lists.

Tabelle A.1. Mailinglisten

Name

[email protected]

ç [email protected]

[email protected]

Beschreibung

Ankündigungen zu OTRS

(neue kehr.

Versionen,

Updates, ...) mit wenig Ver-

Medium to high traffic list, in

English, where you can find all sorts of relevant questions and support for the product.

Medium to high traffic list, in

German, where you can find all sorts of relevant questions and support for the product.

Mailingliste für die Entwickler von OTRS mit wenig Verkehr.

Englische Mailingliste mit wenig Verkehr für Übersetzungs- und Lokalisierungsfragen. Wenn Sie OTRS

übersetzen oder übersetzen wollen oder Probleme mit einer unserer Applikationen in einer internationalen Umgebung haben, sollten Sie sich in diese Liste eintragen.

Homepage

http://lists.otrs.org/cgi-bin/ listinfo/announce http://lists.otrs.org/cgi-bin/ listinfo/otrs http://lists.otrs.org/cgi-bin/ listinfo/otrs-de http://lists.otrs.org/cgi-bin/ listinfo/dev http://lists.otrs.org/cgi-bin/ listinfo/i18n

Um eine dieser Listen zu abonnieren besuchen Sie folgenden Link: http://lists.otrs.org/ .

3. Fehler berichten

To submit bugs visit http://bugs.otrs.org/ (see Figure below). Please take note of the difference between a bug and a configuration issue. Configuration issues are problems that

261

you encounter when setting a system, or general questions regarding the use of OTRS.

Bug reports should only be used for issues with the source code of OTRS itself, or to file enhancements for OTRS. All your bug reports and enhancement requests are very welcome in the bug tracker.

Abb. A-2. Fehlerverfolgungssystem.

For configuration issues, you should either use the

commercial support, available from

OTRS.com

, or the public mailing lists.

Wenn Sie uns Fehler berichten, tragen Sie zur Verbesserung des Produkts bei. Wir freuen uns auf Ihre Mitwirkung!

4. Kommerzieller Support

For services (support, consulting, development, and training) you can contact the company behind OTRS, OTRS AG. Our offices are located in Germany, USA, Mexico, the

Netherlands, and in other countries. Visit our website for contact information: http:// www.otrs.com/en/corporate-navigation/contact/

262

Anhang B. Referenz der

Konfigurationsoptionen

1. DynamicFields

1.1. DynamicFields::Driver::Registration

1.1.1. DynamicFields::Driver###Text

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

DynamicField backend registration.

DynamicFields

DynamicFields::Driver::Registration

$Self->{'DynamicFields::Driver'}->{'Text'} = {

'ConfigDialog' => 'AdminDynamicFieldText',

'DisplayName' => 'Text',

'Module' => 'Kernel::System::DynamicField::Driver::Text'

};

1.1.2. DynamicFields::Driver###TextArea

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

DynamicField backend registration.

DynamicFields

DynamicFields::Driver::Registration

$Self->{'DynamicFields::Driver'}->{'TextArea'} = {

'ConfigDialog' => 'AdminDynamicFieldText',

'DisplayName' => 'Textarea',

'Module' => 'Kernel::System::DynamicField::Driver::TextArea'

};

1.1.3. DynamicFields::Driver###Checkbox

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

DynamicField backend registration.

DynamicFields

DynamicFields::Driver::Registration

$Self->{'DynamicFields::Driver'}->{'Checkbox'} = {

'ConfigDialog' => 'AdminDynamicFieldCheckbox',

'DisplayName' => 'Checkbox',

'Module' => 'Kernel::System::DynamicField::Driver::Checkbox'

};

1.1.4. DynamicFields::Driver###Dropdown

Description:

Group:

DynamicField backend registration.

DynamicFields

263

SubGroup:

Valid:

Required:

Config-Setting:

DynamicFields::Driver::Registration

$Self->{'DynamicFields::Driver'}->{'Dropdown'} = {

'ConfigDialog' => 'AdminDynamicFieldDropdown',

'DisplayName' => 'Dropdown',

'Module' => 'Kernel::System::DynamicField::Driver::Dropdown'

};

1.1.5. DynamicFields::Driver###DateTime

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

DynamicField backend registration.

DynamicFields

DynamicFields::Driver::Registration

$Self->{'DynamicFields::Driver'}->{'DateTime'} = {

'ConfigDialog' => 'AdminDynamicFieldDateTime',

'DisplayName' => 'Date / Time',

'Module' => 'Kernel::System::DynamicField::Driver::DateTime'

};

1.1.6. DynamicFields::Driver###Date

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

DynamicField backend registration.

DynamicFields

DynamicFields::Driver::Registration

$Self->{'DynamicFields::Driver'}->{'Date'} = {

'ConfigDialog' => 'AdminDynamicFieldDateTime',

'DisplayName' => 'Date',

'Module' => 'Kernel::System::DynamicField::Driver::Date'

};

1.1.7. DynamicFields::Driver###Multiselect

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

DynamicField backend registration.

DynamicFields

DynamicFields::Driver::Registration

$Self->{'DynamicFields::Driver'}->{'Multiselect'} = {

'ConfigDialog' => 'AdminDynamicFieldMultiselect',

'DisplayName' => 'Multiselect',

'ItemSeparator' => ', ',

'Module' => 'Kernel::System::DynamicField::Driver::Multiselect'

};

1.2. DynamicFields::ObjectType::Registration

1.2.1. DynamicFields::ObjectType###Ticket

Description: DynamicField object registration.

264

Group:

SubGroup:

Valid:

Required:

Config-Setting:

DynamicFields

DynamicFields::ObjectType::Registration

$Self->{'DynamicFields::ObjectType'}->{'Ticket'} = {

'DisplayName' => 'Ticket',

'Module' => 'Kernel::System::DynamicField::ObjectType::Ticket'

};

1.2.2. DynamicFields::ObjectType###Article

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

DynamicField object registration.

DynamicFields

DynamicFields::ObjectType::Registration

$Self->{'DynamicFields::ObjectType'}->{'Article'} = {

'DisplayName' => 'Article',

'Module' => 'Kernel::System::DynamicField::ObjectType::Article'

};

1.3. Frontend::Admin::ModuleRegistration

1.3.1. Frontend::Module###AdminDynamicField

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

DynamicFields

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminDynamicField'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'Loader' => {

'CSS' => [

'Core.Agent.Admin.DynamicField.css'

'JavaScript' => [

'Core.Agent.Admin.DynamicField.js'

]

'NavBarModule' => {

'Block' => 'Ticket',

'Description' => 'Create and manage dynamic fields.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Dynamic Fields',

'Prio' => '1000'

'NavBarName' => 'Admin',

'Title' => 'Dynamic Fields GUI'

};

1.3.2. Frontend::Module###AdminDynamicFieldText

Description:

Group:

Frontend module registration for the agent interface.

DynamicFields

265

SubGroup:

Valid:

Required:

Config-Setting:

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminDynamicFieldText'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'Loader' => {

'JavaScript' => [

'Core.Agent.Admin.DynamicField.js'

]

'Title' => 'Dynamic Fields Text Backend GUI'

};

1.3.3.

Frontend::Module###AdminDynamicFieldCheckbox

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

DynamicFields

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminDynamicFieldCheckbox'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'Loader' => {

'JavaScript' => [

'Core.Agent.Admin.DynamicField.js'

]

'Title' => 'Dynamic Fields Checkbox Backend GUI'

};

1.3.4.

Frontend::Module###AdminDynamicFieldDropdown

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

DynamicFields

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminDynamicFieldDropdown'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'Loader' => {

'CSS' => [

'Core.Agent.Admin.DynamicField.css'

'JavaScript' => [

'Core.Agent.Admin.DynamicField.js',

'Core.Agent.Admin.DynamicFieldDropdown.js'

]

266

'Title' => 'Dynamic Fields Drop-down Backend GUI'

};

1.3.5.

Frontend::Module###AdminDynamicFieldDateTime

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

DynamicFields

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminDynamicFieldDateTime'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'Loader' => {

'CSS' => [

'Core.Agent.Admin.DynamicField.css'

'JavaScript' => [

'Core.Agent.Admin.DynamicField.js',

'Core.Agent.Admin.DynamicFieldDateTime.js'

]

'Title' => 'Dynamic Fields Date Time Backend GUI'

};

1.3.6.

Frontend::Module###AdminDynamicFieldMultiselect

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

DynamicFields

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminDynamicFieldMultiselect'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'Loader' => {

'CSS' => [

'Core.Agent.Admin.DynamicField.css'

'JavaScript' => [

'Core.Agent.Admin.DynamicField.js',

'Core.Agent.Admin.DynamicFieldMultiselect.js'

]

'Title' => 'Dynamic Fields Multiselect Backend GUI'

};

1.4. Frontend::Agent::Preferences

1.4.1. PreferencesGroups###DynamicField

Description: Defines the config parameters of this item, to be shown in the preferences view.

267

Group:

SubGroup:

Valid:

Required:

Config-Setting:

DynamicFields

Frontend::Agent::Preferences

$Self->{'PreferencesGroups'}->{'DynamicField'} = {

'Active' => '1',

'Block' => 'Input',

'Column' => 'Other Settings',

'Data' => '$Env{"UserDynamicField_NameX"}',

'Key' => 'Default value for NameX',

'Label' => 'NameX',

'Module' => 'Kernel::Output::HTML::PreferencesGeneric',

'PrefKey' => 'UserDynamicField_NameX',

'Prio' => '7000'

};

1.4.2.

PreferencesGroups###DynamicFieldsOverviewPageShown

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Parameters for the pages (in which the dynamic fields are shown) of the dynamic fields overview.

DynamicFields

Frontend::Agent::Preferences

$Self->{'PreferencesGroups'}->{'DynamicFieldsOverviewPageShown'} =

{

'Active' => '0',

'Column' => 'Other Settings',

'Data' => {

'10' => '10',

'15' => '15',

'20' => '20',

'25' => '25',

'30' => '30',

'35' => '35'

'DataSelected' => '25',

'Key' => 'Dynamic fields limit per page for Dynamic Fields

Overview',

'Label' => 'Dynamic Fields Overview Limit',

'Module' => 'Kernel::Output::HTML::PreferencesGeneric',

'PrefKey' => 'AdminDynamicFieldsOverviewPageShown',

'Prio' => '8000'

};

2. Framework

2.1. Core

2.1.1. SecureMode

Description: Disables the web installer (http://yourhost.example.com/otrs/ installer.pl), to prevent the system from being hijacked. If set to

"No", the system can be reinstalled and the current basic configuration will be used to pre-populate the questions within the installer script. If not active, it also disables the GenericAgent, PackageManager and SQL Box.

268

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Framework

Core

$Self->{'SecureMode'} = '0';

2.1.2. Frontend::DebugMode

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

2.1.3. ConfigLevel

Enables or disable the debug mode over frontend interface.

Framework

Core

$Self->{'Frontend::DebugMode'} = '0';

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the configuration level of the administrator. Depending on the config level, some sysconfig options will be not shown. The config levels are in in ascending order: Expert, Advanced, Beginner. The higher the config level is (e.g. Beginner is the highest), the less likely is it that the user can accidentally configure the system in a way that it is not usable any more.

Framework

Core

$Self->{'ConfigLevel'} = '100';

2.1.4. ProductName

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

2.1.5. SystemID

Defines the name of the application, shown in the web interface, tabs and title bar of the web browser.

Framework

Core

$Self->{'ProductName'} = 'OTRS';

Description:

Group:

SubGroup:

Defines the system identifier. Every ticket number and http session string contains this ID. This ensures that only tickets which belong to your system will be processed as follow-ups (useful when communicating between two instances of OTRS).

Framework

Core

269

Valid:

Required:

Config-Setting:

2.1.6. FQDN

$Self->{'SystemID'} = '10';

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the fully qualified domain name of the system. This setting is used as a variable, OTRS_CONFIG_FQDN which is found in all forms of messaging used by the application, to build links to the tickets within your system.

Framework

Core

$Self->{'FQDN'} = 'yourhost.example.com';

2.1.7. SupportDataCollector::HTTPHostname

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

2.1.8. HttpType

Defines the HTTP hostname for the support data collection with the public module 'PublicSupportDataCollector' (e.g. used from the

OTRS Daemon).

Framework

Core

$Self->{'SupportDataCollector::HTTPHostname'} = '';

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

2.1.9. ScriptAlias

Defines the type of protocol, used by the web server, to serve the application. If https protocol will be used instead of plain http, it must be specified here. Since this has no affect on the web server's settings or behavior, it will not change the method of access to the application and, if it is wrong, it will not prevent you from logging into the application. This setting is only used as a variable,

OTRS_CONFIG_HttpType which is found in all forms of messaging used by the application, to build links to the tickets within your system.

Framework

Core

$Self->{'HttpType'} = 'http';

Description: Sets the prefix to the scripts folder on the server, as configured on the web server. This setting is used as a variable,

270

Group:

SubGroup:

Valid:

Required:

Config-Setting:

OTRS_CONFIG_ScriptAlias which is found in all forms of messaging used by the application, to build links to the tickets within the system.

Framework

Core

$Self->{'ScriptAlias'} = 'otrs/';

2.1.10. AdminEmail

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the system administrator's email address. It will be displayed in the error screens of the application.

Framework

Core

$Self->{'AdminEmail'} = '[email protected]';

2.1.11. Organization

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Company name which will be included in outgoing emails as an

X-Header.

Framework

Core

$Self->{'Organization'} = 'Example Company';

2.1.12. DefaultLanguage

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default front-end language. All the possible values are determined by the available language files on the system (see the next setting).

Framework

Core

$Self->{'DefaultLanguage'} = 'en';

2.1.13. DefaultUsedLanguages

Description: Defines all the languages that are available to the application. The

Key/Content pair links the front-end display name to the appropriate language PM file. The "Key" value should be the base-name of the PM file (i.e. de.pm is the file, then de is the "Key" value). The

"Content" value should be the display name for the front-end. Spe-

271

Group:

SubGroup:

Valid:

Required:

Config-Setting: cify any own-defined language here (see the developer documentation http://doc.otrs.org/ for more infomation). Please remember to use the HTML equivalents for non-ASCII characters (i.e. for the

German oe = o umlaut, it is necessary to use the ö symbol).

Framework

Core

$Self->{'DefaultUsedLanguages'} = {

'ar_SA' => 'Arabic (Saudi Arabia)',

'bg' => 'Bulgarian

(Български)',

'ca' => 'Català',

'cs' => 'Czech (Česky)',

'da' => 'Dansk',

'de' => 'Deutsch',

'el' => 'Greek

(Ελληνικά)',

'en' => 'English (United States)',

'en_CA' => 'English (Canada)',

'en_GB' => 'English (United Kingdom)',

'es' => 'Español',

'es_CO' => 'Español (Colombia)',

'es_MX' => 'Español (México)',

'et' => 'Eesti',

'fa' => 'Persian (فارسى)',

'fi' => 'Suomi',

'fr' => 'Français',

'fr_CA' => 'Français (Canada)',

'he' => 'Hebrew (########)',

'hi' => 'Hindi',

'hr' => 'Hrvatski',

'hu' => 'Magyar',

'it' => 'Italiano',

'ja' => 'Japanese (日本&#x8a9e)',

'lt' => 'Lietuvių kalba',

'lv' => 'Latvijas',

'ms' => 'Malay',

'nb_NO' => 'Norsk bokmål',

'nl' => 'Nederlands',

'pl' => 'Polski',

'pt' => 'Português',

'pt_BR' => 'Português Brasileiro',

'ru' => 'Russian

(Русский)',

'sk_SK' => 'Slovak (Slovenčina)',

'sl' => 'Slovenian (Slovenščina)',

'sr_Cyrl' => 'Serbian Cyrillic (српски)',

'sr_Latn' => 'Serbian Latin (Srpski)',

'sv' => 'Svenska',

'tr' => 'Türkçe',

'uk' => 'Ukrainian

(Українська)',

'vi_VN' => 'Vietnam (ViɆt Nam)',

'zh_CN' => 'Chinese (Sim.) (简体中文)',

'zh_TW' => 'Chinese (Tradi.) (正體中文)'

};

2.1.14. DefaultTheme

Description:

Group:

Defines the default front-end (HTML) theme to be used by the agents and customers. If you like, you can add your own theme. Please refer the administrator manual located at http:// doc.otrs.org/.

Framework

272

SubGroup:

Valid:

Required:

Config-Setting:

Core

$Self->{'DefaultTheme'} = 'Standard';

2.1.15. DefaultTheme::HostBased

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

It is possible to configure different themes, for example to distinguish between agents and customers, to be used on a per-domain basis within the application. Using a regular expression (regex), you can configure a Key/Content pair to match a domain. The value in "Key" should match the domain, and the value in "Content" should be a valid theme on your system. Please see the example entries for the proper form of the regex.

Framework

Core

$Self->{'DefaultTheme::HostBased'} = {

'host1\\.example\\.com' => 'SomeTheme1',

'host2\\.example\\.com' => 'SomeTheme2'

};

2.1.16. CheckMXRecord

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Makes the application check the MX record of email addresses before sending an email or submitting a telephone or email ticket.

Framework

Core

$Self->{'CheckMXRecord'} = '1';

2.1.17. CheckMXRecord::Nameserver

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the address of a dedicated DNS server, if necessary, for the "CheckMXRecord" look-ups.

Framework

Core

$Self->{'CheckMXRecord::Nameserver'} = 'ns.example.com';

2.1.18. CheckEmailAddresses

Description:

Group:

SubGroup:

Makes the application check the syntax of email addresses.

Framework

Core

273

Valid:

Required:

Config-Setting:

$Self->{'CheckEmailAddresses'} = '1';

2.1.19. CheckEmailValidAddress

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines a regular expression that excludes some addresses from the syntax check (if "CheckEmailAddresses" is set to "Yes").

Please enter a regex in this field for email addresses, that aren't syntactically valid, but are necessary for the system (i.e.

"root@localhost").

Framework

Core

$Self->{'CheckEmailValidAddress'} = '^(root@localhost| admin@localhost)$';

2.1.20. CheckEmailInvalidAddress

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines a regular expression that filters all email addresses that should not be used in the application.

Framework

Core

$Self->{'CheckEmailInvalidAddress'} = '@(example)\\.(..|...)$';

2.1.21. CGILogPrefix

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the text that should appear in the log file to denote a

CGI script entry.

Framework

Core

$Self->{'CGILogPrefix'} = 'OTRS-CGI';

2.1.22. DemoSystem

Description:

Group:

SubGroup:

Runs the system in "Demo" mode. If set to "Yes", agents can change preferences, such as selection of language and theme via the agent web interface. These changes are only valid for the current session. It will not be possible for agents to change their passwords.

Framework

Core

274

Valid:

Required:

Config-Setting:

$Self->{'DemoSystem'} = '0';

2.1.23. SwitchToUser

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Allows the administrators to login as other users, via the users administration panel.

Framework

Core

$Self->{'SwitchToUser'} = '0';

2.1.24. SwitchToCustomer

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Allows the administrators to login as other customers, via the customer user administration panel.

Framework

Core

$Self->{'SwitchToCustomer'} = '0';

2.1.25. SwitchToCustomer::PermissionGroup

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the group where the user needs rw permissions so that he can access the "SwitchToCustomer" feature.

Framework

Core

$Self->{'SwitchToCustomer::PermissionGroup'} = 'admin';

2.1.26. NotificationSenderName

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the name that should be used by the application when sending notifications. The sender name is used to build the complete display name for the notification master (i.e. "OTRS Notification Master" [email protected]). Notifications are messages such as en::Customer::QueueUpdate or en::Agent::Move.

Framework

Core

$Self->{'NotificationSenderName'} = 'OTRS Notification Master';

275

2.1.27. NotificationSenderEmail

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the email address that should be used by the application when sending notifications. The email address is used to build the complete display name for the notification master (i.e.

"OTRS Notification Master" [email protected]). You can use the OTRS_CONFIG_FQDN variable as set in your configuation, or choose another email address. Notifications are messages such as en::Customer::QueueUpdate or en::Agent::Move.

Framework

Core

$Self->{'NotificationSenderEmail'} = 'otrs@<OTRS_CONFIG_FQDN>';

2.1.28. System::Customer::Permission

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the standard permissions available for customers within the application. If more permissions are needed, you can enter them here. Permissions must be hard coded to be effective. Please ensure, when adding any of the afore mentioned permissions, that the "rw" permission remains the last entry.

Framework

Core

$Self->{'System::Customer::Permission'} = [

'ro',

'rw'

];

2.1.29. LanguageDebug

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Debugs the translation set. If this is set to "Yes" all strings (text) without translations are written to STDERR. This can be helpful when you are creating a new translation file. Otherwise, this option should remain set to "No".

Framework

Core

$Self->{'LanguageDebug'} = '0';

2.1.30. Secure::DisableBanner

Description:

Group:

SubGroup:

Valid:

If enabled, the OTRS version tag will be removed from the Webinterface, the HTTP headers and the X-Headers of outgoing mails.

Framework

Core

276

Required:

Config-Setting:

$Self->{'Secure::DisableBanner'} = '0';

2.1.31. StandardTemplate2QueueByCreating

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

List of default Standard Templates which are assigned automatically to new Queues upon creation.

Framework

Core

$Self->{'StandardTemplate2QueueByCreating'} = [

];

2.2. Core::Cache

2.2.1. Cache::Module

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Selects the cache backend to use.

Framework

Core::Cache

$Self->{'Cache::Module'} = 'Kernel::System::Cache::FileStorable';

2.2.2. Cache::SubdirLevels

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specify how many sub directory levels to use when creating cache files. This should prevent too many cache files being in one directory.

Framework

Core::Cache

$Self->{'Cache::SubdirLevels'} = '2';

2.3. Core::CustomerCompany

2.3.1. CustomerCompany::EventModulePost###100-

UpdateCustomerUsers

Description:

Group:

SubGroup:

Valid:

Required:

Event module that updates customer users after an update of the

Customer Company.

Framework

Core::CustomerCompany

277

Config-Setting:

$Self->{'CustomerCompany::EventModulePost'}->{'100-

UpdateCustomerUsers'} = {

'Event' => 'CustomerCompanyUpdate',

'Module' =>

'Kernel::System::CustomerCompany::Event::CustomerUserUpdate',

'Transaction' => '0'

};

2.4. Core::CustomerUser

2.4.1. CustomerUser::EventModulePost###100-

UpdateServiceMembership

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Event module that updates customer user service membership if login changes.

Framework

Core::CustomerUser

$Self->{'CustomerUser::EventModulePost'}->{'100-

UpdateServiceMembership'} = {

'Event' => 'CustomerUserUpdate',

'Module' =>

'Kernel::System::CustomerUser::Event::ServiceMemberUpdate',

'Transaction' => '0'

};

2.5. Core::LinkObject

2.5.1. LinkObject::ViewMode

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Determines the way the linked objects are displayed in each zoom mask.

Framework

Core::LinkObject

$Self->{'LinkObject::ViewMode'} = 'Simple';

2.5.2. LinkObject::Type###Normal

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the link type 'Normal'. If the source name and the target name contain the same value, the resulting link is a non-directional one; otherwise, the result is a directional link.

Framework

Core::LinkObject

$Self->{'LinkObject::Type'}->{'Normal'} = {

'SourceName' => 'Normal',

'TargetName' => 'Normal'

};

278

2.5.3. LinkObject::Type###ParentChild

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the link type 'ParentChild'. If the source name and the target name contain the same value, the resulting link is a non-directional one; otherwise, the result is a directional link.

Framework

Core::LinkObject

$Self->{'LinkObject::Type'}->{'ParentChild'} = {

'SourceName' => 'Parent',

'TargetName' => 'Child'

};

2.5.4. LinkObject::TypeGroup###0001

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the link type groups. The link types of the same group cancel one another. Example: If ticket A is linked per a 'Normal' link with ticket B, then these tickets could not be additionally linked with link of a 'ParentChild' relationship.

Framework

Core::LinkObject

$Self->{'LinkObject::TypeGroup'}->{'0001'} = [

'Normal',

'ParentChild'

];

2.6. Core::Log

2.6.1. LogModule

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the log module for the system. "File" writes all messages in a given logfile, "SysLog" uses the syslog daemon of the system, e.g. syslogd.

Framework

Core::Log

$Self->{'LogModule'} = 'Kernel::System::Log::SysLog';

2.6.2. LogModule::SysLog::Facility

Description:

Group:

SubGroup:

Valid:

Required:

If "SysLog" was selected for LogModule, a special log facility can be specified.

Framework

Core::Log

279

Config-Setting:

$Self->{'LogModule::SysLog::Facility'} = 'user';

2.6.3. LogModule::SysLog::LogSock

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If "SysLog" was selected for LogModule, a special log sock can be specified (on solaris you may need to use 'stream').

Framework

Core::Log

$Self->{'LogModule::SysLog::LogSock'} = 'unix';

2.6.4. LogModule::SysLog::Charset

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If "SysLog" was selected for LogModule, the charset that should be used for logging can be specified.

Framework

Core::Log

$Self->{'LogModule::SysLog::Charset'} = 'utf-8';

2.6.5. LogModule::LogFile

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If "file" was selected for LogModule, a logfile must be specified. If the file doesn't exist, it will be created by the system.

Framework

Core::Log

$Self->{'LogModule::LogFile'} = '/tmp/otrs.log';

2.6.6. LogModule::LogFile::Date

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Adds a suffix with the actual year and month to the OTRS log file.

A logfile for every month will be created.

Framework

Core::Log

$Self->{'LogModule::LogFile::Date'} = '0';

2.7. Core::MIME-Viewer

2.7.1. MIME-Viewer###application/excel

Description: Specifies the path to the converter that allows the view of Microsoft

Excel files, in the web interface.

280

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Framework

Core::MIME-Viewer

$Self->{'MIME-Viewer'}->{'application/excel'} = 'xlhtml';

2.7.2. MIME-Viewer###application/msword

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the path to the converter that allows the view of Microsoft

Word files, in the web interface.

Framework

Core::MIME-Viewer

$Self->{'MIME-Viewer'}->{'application/msword'} = 'wvWare';

2.7.3. MIME-Viewer###application/pdf

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the path to the converter that allows the view of PDF documents, in the web interface.

Framework

Core::MIME-Viewer

$Self->{'MIME-Viewer'}->{'application/pdf'} = 'pdftohtml -stdout i';

2.7.4. MIME-Viewer###text/xml

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the path to the converter that allows the view of XML files, in the web interface.

Framework

Core::MIME-Viewer

$Self->{'MIME-Viewer'}->{'text/xml'} = '<OTRS_CONFIG_Home>/ scripts/tools/xml2html.pl';

2.8. Core::MirrorDB

2.8.1. Core::MirrorDB::DSN

Description:

Group:

SubGroup:

Valid:

If you want to use a mirror database for agent ticket fulltext search or to generate stats, specify the DSN to this database.

Framework

Core::MirrorDB

281

Required:

Config-Setting:

$Self->{'Core::MirrorDB::DSN'} =

'DBI:mysql:database=mirrordb;host=mirrordbhost';

2.8.2. Core::MirrorDB::User

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If you want to use a mirror database for agent ticket fulltext search or to generate stats, the user to authenticate to this database can be specified.

Framework

Core::MirrorDB

$Self->{'Core::MirrorDB::User'} = 'some_user';

2.8.3. Core::MirrorDB::Password

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

2.9. Core::PDF

2.9.1. PDF

If you want to use a mirror database for agent ticket fulltext search or to generate stats, the password to authenticate to this database can be specified.

Framework

Core::MirrorDB

$Self->{'Core::MirrorDB::Password'} = 'some_password';

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Enables PDF output. The CPAN module PDF::API2 is required, if not installed, PDF output will be disabled.

Framework

Core::PDF

$Self->{'PDF'} = '1';

2.9.2. PDF::LogoFile

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the path of the file for the logo in the page header (gif| jpg|png, 700 x 100 pixel).

Framework

Core::PDF

$Self->{'PDF::LogoFile'} = '<OTRS_CONFIG_Home>/var/logo-otrs.png';

282

2.9.3. PDF::PageSize

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the standard size of PDF pages.

Framework

Core::PDF

$Self->{'PDF::PageSize'} = 'a4';

2.9.4. PDF::MaxPages

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the maximum number of pages per PDF file.

Framework

Core::PDF

$Self->{'PDF::MaxPages'} = '100';

2.9.5. PDF::TTFontFile###Proportional

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the path and TTF-File to handle proportional font in PDF documents.

Framework

Core::PDF

$Self->{'PDF::TTFontFile'}->{'Proportional'} = 'DejaVuSans.ttf';

2.9.6. PDF::TTFontFile###ProportionalBold

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the path and TTF-File to handle bold proportional font in

PDF documents.

Framework

Core::PDF

$Self->{'PDF::TTFontFile'}->{'ProportionalBold'} = 'DejaVuSans-

Bold.ttf';

2.9.7. PDF::TTFontFile###ProportionalItalic

Description:

Group:

SubGroup:

Valid:

Required:

Defines the path and TTF-File to handle italic proportional font in

PDF documents.

Framework

Core::PDF

283

Config-Setting:

$Self->{'PDF::TTFontFile'}->{'ProportionalItalic'} = 'DejaVuSans-

Oblique.ttf';

2.9.8. PDF::TTFontFile###ProportionalBoldItalic

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the path and TTF-File to handle bold italic proportional font in PDF documents.

Framework

Core::PDF

$Self->{'PDF::TTFontFile'}->{'ProportionalBoldItalic'} =

'DejaVuSans-BoldOblique.ttf';

2.9.9. PDF::TTFontFile###Monospaced

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the path and TTF-File to handle monospaced font in PDF documents.

Framework

Core::PDF

$Self->{'PDF::TTFontFile'}->{'Monospaced'} = 'DejaVuSansMono.ttf';

2.9.10. PDF::TTFontFile###MonospacedBold

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the path and TTF-File to handle bold monospaced font in

PDF documents.

Framework

Core::PDF

$Self->{'PDF::TTFontFile'}->{'MonospacedBold'} = 'DejaVuSansMono-

Bold.ttf';

2.9.11. PDF::TTFontFile###MonospacedItalic

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the path and TTF-File to handle italic monospaced font in

PDF documents.

Framework

Core::PDF

$Self->{'PDF::TTFontFile'}->{'MonospacedItalic'} =

'DejaVuSansMono-Oblique.ttf';

2.9.12. PDF::TTFontFile###MonospacedBoldItalic

Description: Defines the path and TTF-File to handle bold italic monospaced font in PDF documents.

284

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Framework

Core::PDF

$Self->{'PDF::TTFontFile'}->{'MonospacedBoldItalic'} =

'DejaVuSansMono-BoldOblique.ttf';

2.10. Core::Package

2.10.1. Package::FileUpload

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Enables file upload in the package manager frontend.

Framework

Core::Package

$Self->{'Package::FileUpload'} = '1';

2.10.2. Package::RepositoryRoot

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the location to get online repository list for additional packages. The first available result will be used.

Framework

Core::Package

$Self->{'Package::RepositoryRoot'} = [

'http://ftp.otrs.org/pub/otrs/misc/packages/repository.xml'

];

2.10.3. Package::RepositoryList

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the list of online repositories. Another installations can be used as repository, for example: Key="http://example.com/otrs/ public.pl?Action=PublicRepository;File=" and Content="Some

Name".

Framework

Core::Package

$Self->{'Package::RepositoryList'} = {

'ftp://ftp.example.com/pub/otrs/misc/packages/' => '[Example]

ftp://ftp.example.com/'

};

2.10.4. Package::RepositoryAccessRegExp

Description: Defines the IP regular expression for accessing the local repository.

You need to enable this to have access to your local repository and the package::RepositoryList is required on the remote host.

285

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Framework

Core::Package

$Self->{'Package::RepositoryAccessRegExp'} = '127\\.0\\.0\\.1';

2.10.5. Package::Timeout

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the timeout (in seconds) for package downloads. Overwrites

"WebUserAgent::Timeout".

Framework

Core::Package

$Self->{'Package::Timeout'} = '15';

2.10.6. Package::Proxy

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Fetches packages via proxy. Overwrites "WebUserAgent::Proxy".

Framework

Core::Package

$Self->{'Package::Proxy'} = 'http://proxy.sn.no:8001/';

2.10.7. Package::ShowFeatureAddons

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Toggles display of OTRS FeatureAddons list in PackageManager.

Framework

Core::Package

$Self->{'Package::ShowFeatureAddons'} = '1';

2.10.8. Package::EventModule###99-SupportData-

Send

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Package event module file a scheduler task for update registration.

Framework

Core::Package

$Self->{'Package::EventModule'}->{'99-SupportDataSend'} = {

'Event' => '(PackageInstall|PackageReinstall|PackageUpgrade|

PackageUninstall)',

'Module' => 'Kernel::System::Package::Event::SupportDataSend',

'Transaction' => '1'

286

};

2.11. Core::PerformanceLog

2.11.1. PerformanceLog

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Enables performance log (to log the page response time). It will affect the system performance.

Frontend::Module###AdminPerformanceLog must be enabled.

Framework

Core::PerformanceLog

$Self->{'PerformanceLog'} = '0';

2.11.2. PerformanceLog::File

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the path of the file for the performance log.

Framework

Core::PerformanceLog

$Self->{'PerformanceLog::File'} = '<OTRS_CONFIG_Home>/var/log/

Performance.log';

2.11.3. PerformanceLog::FileMax

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the maximum size (in MB) of the log file.

Framework

Core::PerformanceLog

$Self->{'PerformanceLog::FileMax'} = '25';

2.12. Core::ReferenceData

2.12.1. ReferenceData::OwnCountryList

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

This setting allows you to override the built-in country list with your own list of countries. This is particularly handy if you just want to use a small select group of countries.

Framework

Core::ReferenceData

$Self->{'ReferenceData::OwnCountryList'} = {

'AT' => 'Austria',

'CH' => 'Switzerland',

287

'DE' => 'Germany'

};

2.13. Core::SOAP

2.13.1. SOAP::User

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the username to access the SOAP handle (bin/cgi-bin/ rpc.pl).

Framework

Core::SOAP

$Self->{'SOAP::User'} = 'some_user';

2.13.2. SOAP::Password

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the password to access the SOAP handle (bin/cgi-bin/ rpc.pl).

Framework

Core::SOAP

$Self->{'SOAP::Password'} = 'some_pass';

2.13.3. SOAP::Keep-Alive

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Enable keep-alive connection header for SOAP responses.

Framework

Core::SOAP

$Self->{'SOAP::Keep-Alive'} = '0';

2.14. Core::Sendmail

2.14.1. SendmailModule

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the module to send emails. "Sendmail" directly uses the sendmail binary of your operating system. Any of the "SMTP" mechanisms use a specified (external) mailserver. "DoNotSendEmail" doesn't send emails and it is useful for test systems.

Framework

Core::Sendmail

$Self->{'SendmailModule'} = 'Kernel::System::Email::Sendmail';

288

2.14.2. SendmailModule::CMD

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If "Sendmail" was selected as SendmailModule, the location of the sendmail binary and the needed options must be specified.

Framework

Core::Sendmail

$Self->{'SendmailModule::CMD'} = '/usr/sbin/sendmail -i -f';

2.14.3. SendmailModule::Host

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If any of the "SMTP" mechanisms was selected as SendmailModule, the mailhost that sends out the mails must be specified.

Framework

Core::Sendmail

$Self->{'SendmailModule::Host'} = 'mail.example.com';

2.14.4. SendmailModule::Port

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If any of the "SMTP" mechanisms was selected as SendmailModule, the port where your mailserver is listening for incoming connections must be specified.

Framework

Core::Sendmail

$Self->{'SendmailModule::Port'} = '25';

2.14.5. SendmailModule::AuthUser

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If any of the "SMTP" mechanisms was selected as SendmailModule, and authentication to the mail server is needed, an username must be specified.

Framework

Core::Sendmail

$Self->{'SendmailModule::AuthUser'} = 'MailserverLogin';

2.14.6. SendmailModule::AuthPassword

Description: If any of the "SMTP" mechanisms was selected as SendmailModule, and authentication to the mail server is needed, a password must be specified.

289

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Framework

Core::Sendmail

$Self->{'SendmailModule::AuthPassword'} = 'MailserverPassword';

2.14.7. SendmailBcc

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sends all outgoing email via bcc to the specified address. Please use this only for backup reasons.

Framework

Core::Sendmail

$Self->{'SendmailBcc'} = '';

2.14.8. SendmailEnvelopeFrom

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If set, this address is used as envelope sender in outgoing messages (not notifications - see below). If no address is specified, the envelope sender is equal to queue e-mail address.

Framework

Core::Sendmail

$Self->{'SendmailEnvelopeFrom'} = '';

2.14.9. SendmailNotificationEnvelopeFrom

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If set, this address is used as envelope sender header in outgoing notifications. If no address is specified, the envelope sender header is empty.

Framework

Core::Sendmail

$Self->{'SendmailNotificationEnvelopeFrom'} = '';

2.14.10. SendmailEncodingForce

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Forces encoding of outgoing emails (7bit|8bit|quoted-printable|base64).

Framework

Core::Sendmail

$Self->{'SendmailEncodingForce'} = 'base64';

290

2.15. Core::Session

2.15.1. SessionModule

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the module used to store the session data. With "DB" the frontend server can be splitted from the db server. "FS" is faster.

Framework

Core::Session

$Self->{'SessionModule'} = 'Kernel::System::AuthSession::DB';

2.15.2. SessionName

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the name of the session key. E.g. Session, SessionID or

OTRS.

Framework

Core::Session

$Self->{'SessionName'} = 'OTRSAgentInterface';

2.15.3. CustomerPanelSessionName

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the name of the key for customer sessions.

Framework

Core::Session

$Self->{'CustomerPanelSessionName'} = 'OTRSCustomerInterface';

2.15.4. SessionCheckRemoteIP

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Turns on the remote ip address check. It should be set to "No" if the application is used, for example, via a proxy farm or a dialup connection, because the remote ip address is mostly different for the requests.

Framework

Core::Session

$Self->{'SessionCheckRemoteIP'} = '1';

2.15.5. SessionDeleteIfNotRemoteID

Description:

Group:

Deletes a session if the session id is used with an invalid remote

IP address.

Framework

291

SubGroup:

Valid:

Required:

Config-Setting:

Core::Session

$Self->{'SessionDeleteIfNotRemoteID'} = '1';

2.15.6. SessionMaxTime

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the maximal valid time (in seconds) for a session id.

Framework

Core::Session

$Self->{'SessionMaxTime'} = '57600';

2.15.7. SessionMaxIdleTime

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the inactivity time (in seconds) to pass before a session is killed and a user is loged out.

Framework

Core::Session

$Self->{'SessionMaxIdleTime'} = '21600';

2.15.8. SessionActiveTime

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the time (in seconds) a user is marked as active.

Framework

Core::Session

$Self->{'SessionActiveTime'} = '600';

2.15.9. SessionDeleteIfTimeToOld

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Deletes requested sessions if they have timed out.

Framework

Core::Session

$Self->{'SessionDeleteIfTimeToOld'} = '1';

2.15.10. SessionUseCookie

Description: Makes the session management use html cookies. If html cookies are disabled or if the client browser disabled html cookies, then the system will work as usual and append the session id to the links.

292

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Framework

Core::Session

$Self->{'SessionUseCookie'} = '1';

2.15.11. SessionUseCookieAfterBrowserClose

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Stores cookies after the browser has been closed.

Framework

Core::Session

$Self->{'SessionUseCookieAfterBrowserClose'} = '0';

2.15.12. SessionCSRFProtection

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Protection against CSRF (Cross Site Request Forgery) exploits (for more info see http://en.wikipedia.org/wiki/Crosssite_request_forgery).

Framework

Core::Session

$Self->{'SessionCSRFProtection'} = '1';

2.15.13. AgentSessionLimit

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the maximum number of active agents within the timespan defined in SessionActiveTime.

Framework

Core::Session

$Self->{'AgentSessionLimit'} = '100';

2.15.14. CustomerSessionLimit

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the maximum number of active customers within the timespan defined in SessionActiveTime.

Framework

Core::Session

$Self->{'CustomerSessionLimit'} = '100';

293

2.15.15. SessionDir

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If "FS" was selected for SessionModule, a directory where the session data will be stored must be specified.

Framework

Core::Session

$Self->{'SessionDir'} = '<OTRS_CONFIG_Home>/var/sessions';

2.15.16. SessionTable

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If "DB" was selected for SessionModule, a table in database where session data will be stored must be specified.

Framework

Core::Session

$Self->{'SessionTable'} = 'sessions';

2.16. Core::SpellChecker

2.16.1. SpellChecker

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Enables spell checker support.

Framework

Core::SpellChecker

$Self->{'SpellChecker'} = '0';

2.16.2. SpellCheckerBin

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Install ispell or aspell on the system, if you want to use a spell checker. Please specify the path to the aspell or ispell binary on your operating system.

Framework

Core::SpellChecker

$Self->{'SpellCheckerBin'} = '/usr/bin/ispell';

2.16.3. SpellCheckerDictDefault

Description:

Group:

SubGroup:

Defines the default spell checker dictionary.

Framework

Core::SpellChecker

294

Valid:

Required:

Config-Setting:

$Self->{'SpellCheckerDictDefault'} = 'english';

2.16.4. SpellCheckerIgnore

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines a default list of words, that are ignored by the spell checker.

Framework

Core::SpellChecker

$Self->{'SpellCheckerIgnore'} = [

'www',

'webmail',

'https',

'http',

'html',

'rfc'

];

2.17. Core::Stats

2.17.1. Stats::StatsHook

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the stats hook.

Framework

Core::Stats

$Self->{'Stats::StatsHook'} = 'Stat#';

2.17.2. Stats::StatsStartNumber

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Start number for statistics counting. Every new stat increments this number.

Framework

Core::Stats

$Self->{'Stats::StatsStartNumber'} = '10000';

2.17.3. Stats::MaxXaxisAttributes

Description:

Group:

SubGroup:

Valid:

Required:

Defines the default maximum number of X-axis attributes for the time scale.

Framework

Core::Stats

295

Config-Setting:

$Self->{'Stats::MaxXaxisAttributes'} = '1000';

2.18. Core::Stats::Graph

2.18.1. Stats::Graph::t_margin

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the top margin of the chart.

Framework

Core::Stats::Graph

$Self->{'Stats::Graph::t_margin'} = '10';

2.18.2. Stats::Graph::l_margin

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the left margin of the chart.

Framework

Core::Stats::Graph

$Self->{'Stats::Graph::l_margin'} = '10';

2.18.3. Stats::Graph::b_margin

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the bottom margin of the chart.

Framework

Core::Stats::Graph

$Self->{'Stats::Graph::b_margin'} = '10';

2.18.4. Stats::Graph::r_margin

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the right margin of the chart.

Framework

Core::Stats::Graph

$Self->{'Stats::Graph::r_margin'} = '20';

2.18.5. Stats::Graph::bgclr

Description:

Group:

SubGroup:

Valid:

Required:

Specifies the background color of the picture.

Framework

Core::Stats::Graph

296

Config-Setting:

$Self->{'Stats::Graph::bgclr'} = 'white';

2.18.6. Stats::Graph::transparent

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Makes the picture transparent.

Framework

Core::Stats::Graph

$Self->{'Stats::Graph::transparent'} = '0';

2.18.7. Stats::Graph::fgclr

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the border color of the chart.

Framework

Core::Stats::Graph

$Self->{'Stats::Graph::fgclr'} = 'black';

2.18.8. Stats::Graph::boxclr

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the background color of the chart.

Framework

Core::Stats::Graph

$Self->{'Stats::Graph::boxclr'} = 'white';

2.18.9. Stats::Graph::accentclr

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the border color of the legend.

Framework

Core::Stats::Graph

$Self->{'Stats::Graph::accentclr'} = 'black';

2.18.10. Stats::Graph::legendclr

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the text color of the legend.

Framework

Core::Stats::Graph

$Self->{'Stats::Graph::legendclr'} = 'black';

297

2.18.11. Stats::Graph::textclr

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the text color of the chart (e. g. caption).

Framework

Core::Stats::Graph

$Self->{'Stats::Graph::textclr'} = 'black';

2.18.12. Stats::Graph::dclrs

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the colors for the graphs.

Framework

Core::Stats::Graph

$Self->{'Stats::Graph::dclrs'} = [

'red',

'green',

'blue',

'yellow',

'purple',

'orange',

'pink',

'marine',

'cyan',

'lgray',

'lblue',

'lyellow',

'lgreen',

'lred',

'lpurple',

'lorange',

'lbrown'

];

2.18.13. Stats::Graph::TitleFont

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the title font in graphs (place custom fonts in var/fonts).

Framework

Core::Stats::Graph

$Self->{'Stats::Graph::TitleFont'} = 'DejaVuSans-Bold.ttf';

2.18.14. Stats::Graph::LegendFont

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the legend font in graphs (place custom fonts in var/fonts).

Framework

Core::Stats::Graph

$Self->{'Stats::Graph::LegendFont'} = 'DejaVuSans.ttf';

298

2.18.15. Stats::Graph::line_width

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the boldness of the line drawed by the graph.

Framework

Core::Stats::Graph

$Self->{'Stats::Graph::line_width'} = '1';

2.18.16. Stats::Graph::legend_placement

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the placement of the legend. This should be a two letter key of the form: 'B[LCR]|R[TCB]'. The first letter indicates the placement (Bottom or Right), and the second letter the alignment

(Left, Right, Center, Top, or Bottom).

Framework

Core::Stats::Graph

$Self->{'Stats::Graph::legend_placement'} = 'BC';

2.18.17. Stats::Graph::legend_spacing

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the spacing of the legends.

Framework

Core::Stats::Graph

$Self->{'Stats::Graph::legend_spacing'} = '4';

2.18.18. Stats::Graph::legend_marker_width

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the width of the legend.

Framework

Core::Stats::Graph

$Self->{'Stats::Graph::legend_marker_width'} = '12';

2.18.19. Stats::Graph::legend_marker_height

Description:

Group:

SubGroup:

Valid:

Required:

Defines the height of the legend.

Framework

Core::Stats::Graph

299

Config-Setting:

$Self->{'Stats::Graph::legend_marker_height'} = '8';

2.19. Core::Time

2.19.1. TimeInputFormat

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the date input format used in forms (option or input fields).

Framework

Core::Time

$Self->{'TimeInputFormat'} = 'Option';

2.19.2. TimeShowAlwaysLong

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

2.19.3. TimeZone

Shows time in long format (days, hours, minutes), if set to "Yes"; or in short format (days, hours), if set to "No".

Framework

Core::Time

$Self->{'TimeShowAlwaysLong'} = '0';

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the system time zone (required a system with UTC as system time). Otherwise this is a diff time to the local time.

Framework

Core::Time

$Self->{'TimeZone'} = '+0';

2.19.4. TimeZoneUser

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the user time zone per user (required a system with UTC as system time and UTC under TimeZone). Otherwise this is a diff time to the local time.

Framework

Core::Time

$Self->{'TimeZoneUser'} = '0';

2.19.5. TimeZoneUserBrowserAutoOffset

Description: Sets the user time zone per user based on java script / browser time zone offset feature at login time.

300

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Framework

Core::Time

$Self->{'TimeZoneUserBrowserAutoOffset'} = '1';

2.19.6. CalendarWeekDayStart

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Define the start day of the week for the date picker.

Framework

Core::Time

$Self->{'CalendarWeekDayStart'} = '1';

2.19.7. TimeVacationDays

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Adds the permanent vacation days. Please use single digit pattern for numbers from 1 to 9 (instead of 01 - 09).

Framework

Core::Time

$Self->{'TimeVacationDays'} = {

'1' => {

'1' => 'New Year\'s Day'

'12' => {

'24' => 'Christmas Eve',

'25' => 'First Christmas Day',

'26' => 'Second Christmas Day',

'31' => 'New Year\'s Eve'

'5' => {

'1' => 'International Workers\' Day'

}

};

2.19.8. TimeVacationDaysOneTime

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Adds the one time vacation days. Please use single digit pattern for numbers from 1 to 9 (instead of 01 - 09).

Framework

Core::Time

$Self->{'TimeVacationDaysOneTime'} = {

'2004' => {

'1' => {

'1' => 'test'

}

};

301

2.19.9. TimeWorkingHours

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the hours and week days to count the working time.

Framework

Core::Time

'Sun' => [],

'Thu' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Tue' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

$Self->{'TimeWorkingHours'} = {

'Fri' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Mon' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Sat' => [],

302

'20'

'Wed' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

]

};

2.19.10. TimeShowCompleteDescription

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows time use complete description (days, hours, minutes), if set to "Yes"; or just first letter (d, h, m), if set to "No".

Framework

Core::Time

$Self->{'TimeShowCompleteDescription'} = '0';

2.20. Core::Time::Calendar1

2.20.1. TimeZone::Calendar1Name

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the name of the indicated calendar.

Framework

Core::Time::Calendar1

$Self->{'TimeZone::Calendar1Name'} = 'Calendar Name 1';

2.20.2. TimeZone::Calendar1

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the time zone of the indicated calendar, which can be assigned later to a specific queue.

Framework

Core::Time::Calendar1

$Self->{'TimeZone::Calendar1'} = '0';

2.20.3. TimeVacationDays::Calendar1

Description: Adds the permanent vacation days for the indicated calendar.

Please use single digit pattern for numbers from 1 to 9 (instead of 01 - 09).

303

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Framework

Core::Time::Calendar1

$Self->{'TimeVacationDays::Calendar1'} = {

'1' => {

'1' => 'New Year\'s Day'

'12' => {

'24' => 'Christmas Eve',

'25' => 'First Christmas Day',

'26' => 'Second Christmas Day',

'31' => 'New Year\'s Eve'

'5' => {

'1' => 'International Workers\' Day'

}

};

2.20.4. TimeVacationDaysOneTime::Calendar1

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Adds the one time vacation days for the indicated calendar. Please use single digit pattern for numbers from 1 to 9 (instead of 01 - 09).

Framework

Core::Time::Calendar1

$Self->{'TimeVacationDaysOneTime::Calendar1'} = {

'2004' => {

'1' => {

'1' => 'test'

}

};

2.20.5. TimeWorkingHours::Calendar1

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the hours and week days of the indicated calendar, to count the working time.

Framework

Core::Time::Calendar1

$Self->{'TimeWorkingHours::Calendar1'} = {

'Fri' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

304

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

]

};

'Tue' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Wed' => [

'Mon' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Sat' => [],

'Sun' => [],

'Thu' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

2.21. Core::Time::Calendar2

2.21.1. TimeZone::Calendar2Name

Description: Defines the name of the indicated calendar.

305

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Framework

Core::Time::Calendar2

$Self->{'TimeZone::Calendar2Name'} = 'Calendar Name 2';

2.21.2. TimeZone::Calendar2

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the time zone of the indicated calendar, which can be assigned later to a specific queue.

Framework

Core::Time::Calendar2

$Self->{'TimeZone::Calendar2'} = '0';

2.21.3. TimeVacationDays::Calendar2

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Adds the permanent vacation days for the indicated calendar.

Please use single digit pattern for numbers from 1 to 9 (instead of 01 - 09).

Framework

Core::Time::Calendar2

$Self->{'TimeVacationDays::Calendar2'} = {

'1' => {

'1' => 'New Year\'s Day'

'12' => {

'24' => 'Christmas Eve',

'25' => 'First Christmas Day',

'26' => 'Second Christmas Day',

'31' => 'New Year\'s Eve'

'5' => {

'1' => 'International Workers\' Day'

}

};

2.21.4. TimeVacationDaysOneTime::Calendar2

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Adds the one time vacation days for the indicated calendar. Please use single digit pattern for numbers from 1 to 9 (instead of 01 - 09).

Framework

Core::Time::Calendar2

$Self->{'TimeVacationDaysOneTime::Calendar2'} = {

'2004' => {

'1' => {

306

'1' => 'test'

}

};

2.21.5. TimeWorkingHours::Calendar2

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the hours and week days of the indicated calendar, to count the working time.

Framework

Core::Time::Calendar2

$Self->{'TimeWorkingHours::Calendar2'} = {

'Fri' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Mon' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Sat' => [],

'Sun' => [],

'Thu' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Tue' => [

'8',

'9',

'10',

'11',

'12',

307

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Wed' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

]

};

2.22. Core::Time::Calendar3

2.22.1. TimeZone::Calendar3Name

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the name of the indicated calendar.

Framework

Core::Time::Calendar3

$Self->{'TimeZone::Calendar3Name'} = 'Calendar Name 3';

2.22.2. TimeZone::Calendar3

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the time zone of the indicated calendar, which can be assigned later to a specific queue.

Framework

Core::Time::Calendar3

$Self->{'TimeZone::Calendar3'} = '0';

2.22.3. TimeVacationDays::Calendar3

Description:

Group:

SubGroup:

Adds the permanent vacation days for the indicated calendar.

Please use single digit pattern for numbers from 1 to 9 (instead of 01 - 09).

Framework

Core::Time::Calendar3

308

Valid:

Required:

Config-Setting:

$Self->{'TimeVacationDays::Calendar3'} = {

'1' => {

'1' => 'New Year\'s Day'

'12' => {

'24' => 'Christmas Eve',

'25' => 'First Christmas Day',

'26' => 'Second Christmas Day',

'31' => 'New Year\'s Eve'

'5' => {

'1' => 'International Workers\' Day'

}

};

2.22.4. TimeVacationDaysOneTime::Calendar3

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Adds the one time vacation days for the indicated calendar. Please use single digit pattern for numbers from 1 to 9 (instead of 01 - 09).

Framework

Core::Time::Calendar3

$Self->{'TimeVacationDaysOneTime::Calendar3'} = {

'2004' => {

'1' => {

'1' => 'test'

}

};

2.22.5. TimeWorkingHours::Calendar3

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the hours and week days of the indicated calendar, to count the working time.

Framework

Core::Time::Calendar3

$Self->{'TimeWorkingHours::Calendar3'} = {

'Fri' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Mon' => [

'8',

309

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Wed' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

]

};

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Sat' => [],

'Sun' => [],

'Thu' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Tue' => [

'8',

2.23. Core::Time::Calendar4

2.23.1. TimeZone::Calendar4Name

Description:

Group:

Defines the name of the indicated calendar.

Framework

310

SubGroup:

Valid:

Required:

Config-Setting:

Core::Time::Calendar4

$Self->{'TimeZone::Calendar4Name'} = 'Calendar Name 4';

2.23.2. TimeZone::Calendar4

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the time zone of the indicated calendar, which can be assigned later to a specific queue.

Framework

Core::Time::Calendar4

$Self->{'TimeZone::Calendar4'} = '0';

2.23.3. TimeVacationDays::Calendar4

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Adds the permanent vacation days for the indicated calendar.

Please use single digit pattern for numbers from 1 to 9 (instead of 01 - 09).

Framework

Core::Time::Calendar4

$Self->{'TimeVacationDays::Calendar4'} = {

'1' => {

'1' => 'New Year\'s Day'

'12' => {

'24' => 'Christmas Eve',

'25' => 'First Christmas Day',

'26' => 'Second Christmas Day',

'31' => 'New Year\'s Eve'

'5' => {

'1' => 'International Workers\' Day'

}

};

2.23.4. TimeVacationDaysOneTime::Calendar4

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Adds the one time vacation days for the indicated calendar. Please use single digit pattern for numbers from 1 to 9 (instead of 01 - 09).

Framework

Core::Time::Calendar4

$Self->{'TimeVacationDaysOneTime::Calendar4'} = {

'2004' => {

'1' => {

'1' => 'test'

311

}

};

2.23.5. TimeWorkingHours::Calendar4

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the hours and week days of the indicated calendar, to count the working time.

Framework

Core::Time::Calendar4

$Self->{'TimeWorkingHours::Calendar4'} = {

'Fri' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Mon' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Sat' => [],

'Sun' => [],

'Thu' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Tue' => [

'8',

'9',

'10',

'11',

'12',

'13',

312

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Wed' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

]

};

2.24. Core::Time::Calendar5

2.24.1. TimeZone::Calendar5Name

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the name of the indicated calendar.

Framework

Core::Time::Calendar5

$Self->{'TimeZone::Calendar5Name'} = 'Calendar Name 5';

2.24.2. TimeZone::Calendar5

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the time zone of the indicated calendar, which can be assigned later to a specific queue.

Framework

Core::Time::Calendar5

$Self->{'TimeZone::Calendar5'} = '0';

2.24.3. TimeVacationDays::Calendar5

Description:

Group:

SubGroup:

Valid:

Adds the permanent vacation days for the indicated calendar.

Please use single digit pattern for numbers from 1 to 9 (instead of 01 - 09).

Framework

Core::Time::Calendar5

313

Required:

Config-Setting:

$Self->{'TimeVacationDays::Calendar5'} = {

'1' => {

'1' => 'New Year\'s Day'

'12' => {

'24' => 'Christmas Eve',

'25' => 'First Christmas Day',

'26' => 'Second Christmas Day',

'31' => 'New Year\'s Eve'

'5' => {

'1' => 'International Workers\' Day'

}

};

2.24.4. TimeVacationDaysOneTime::Calendar5

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Adds the one time vacation days for the indicated calendar. Please use single digit pattern for numbers from 1 to 9 (instead of 01 - 09).

Framework

Core::Time::Calendar5

$Self->{'TimeVacationDaysOneTime::Calendar5'} = {

'2004' => {

'1' => {

'1' => 'test'

}

};

2.24.5. TimeWorkingHours::Calendar5

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the hours and week days of the indicated calendar, to count the working time.

Framework

Core::Time::Calendar5

$Self->{'TimeWorkingHours::Calendar5'} = {

'Fri' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Mon' => [

'8',

'9',

'10',

314

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Wed' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

]

};

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Sat' => [],

'Sun' => [],

'Thu' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Tue' => [

'8',

'9',

'10',

2.25. Core::Time::Calendar6

2.25.1. TimeZone::Calendar6Name

Description:

Group:

SubGroup:

Defines the name of the indicated calendar.

Framework

Core::Time::Calendar6

315

Valid:

Required:

Config-Setting:

$Self->{'TimeZone::Calendar6Name'} = 'Calendar Name 6';

2.25.2. TimeZone::Calendar6

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the time zone of the indicated calendar, which can be assigned later to a specific queue.

Framework

Core::Time::Calendar6

$Self->{'TimeZone::Calendar6'} = '0';

2.25.3. TimeVacationDays::Calendar6

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Adds the permanent vacation days for the indicated calendar.

Please use single digit pattern for numbers from 1 to 9 (instead of 01 - 09).

Framework

Core::Time::Calendar6

$Self->{'TimeVacationDays::Calendar6'} = {

'1' => {

'1' => 'New Year\'s Day'

'12' => {

'24' => 'Christmas Eve',

'25' => 'First Christmas Day',

'26' => 'Second Christmas Day',

'31' => 'New Year\'s Eve'

'5' => {

'1' => 'International Workers\' Day'

}

};

2.25.4. TimeVacationDaysOneTime::Calendar6

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Adds the one time vacation days for the indicated calendar. Please use single digit pattern for numbers from 1 to 9 (instead of 01 - 09).

Framework

Core::Time::Calendar6

$Self->{'TimeVacationDaysOneTime::Calendar6'} = {

'2004' => {

'1' => {

'1' => 'test'

}

316

};

2.25.5. TimeWorkingHours::Calendar6

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the hours and week days of the indicated calendar, to count the working time.

Framework

Core::Time::Calendar6

'Sun' => [],

'Thu' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Tue' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

$Self->{'TimeWorkingHours::Calendar6'} = {

'Fri' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Mon' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Sat' => [],

317

'16',

'17',

'18',

'19',

'20'

'Wed' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

]

};

2.26. Core::Time::Calendar7

2.26.1. TimeZone::Calendar7Name

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the name of the indicated calendar.

Framework

Core::Time::Calendar7

$Self->{'TimeZone::Calendar7Name'} = 'Calendar Name 7';

2.26.2. TimeZone::Calendar7

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the time zone of the indicated calendar, which can be assigned later to a specific queue.

Framework

Core::Time::Calendar7

$Self->{'TimeZone::Calendar7'} = '0';

2.26.3. TimeVacationDays::Calendar7

Description:

Group:

SubGroup:

Valid:

Required:

Adds the permanent vacation days for the indicated calendar.

Please use single digit pattern for numbers from 1 to 9 (instead of 01 - 09).

Framework

Core::Time::Calendar7

318

Config-Setting:

$Self->{'TimeVacationDays::Calendar7'} = {

'1' => {

'1' => 'New Year\'s Day'

'12' => {

'24' => 'Christmas Eve',

'25' => 'First Christmas Day',

'26' => 'Second Christmas Day',

'31' => 'New Year\'s Eve'

'5' => {

'1' => 'International Workers\' Day'

}

};

2.26.4. TimeVacationDaysOneTime::Calendar7

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Adds the one time vacation days for the indicated calendar. Please use single digit pattern for numbers from 1 to 9 (instead of 01 - 09).

Framework

Core::Time::Calendar7

$Self->{'TimeVacationDaysOneTime::Calendar7'} = {

'2004' => {

'1' => {

'1' => 'test'

}

};

2.26.5. TimeWorkingHours::Calendar7

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the hours and week days of the indicated calendar, to count the working time.

Framework

Core::Time::Calendar7

$Self->{'TimeWorkingHours::Calendar7'} = {

'Fri' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Mon' => [

'8',

'9',

'10',

'11',

319

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Wed' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

]

};

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Sat' => [],

'Sun' => [],

'Thu' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Tue' => [

'8',

'9',

'10',

'11',

2.27. Core::Time::Calendar8

2.27.1. TimeZone::Calendar8Name

Description:

Group:

SubGroup:

Valid:

Defines the name of the indicated calendar.

Framework

Core::Time::Calendar8

320

Required:

Config-Setting:

$Self->{'TimeZone::Calendar8Name'} = 'Calendar Name 8';

2.27.2. TimeZone::Calendar8

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the time zone of the indicated calendar, which can be assigned later to a specific queue.

Framework

Core::Time::Calendar8

$Self->{'TimeZone::Calendar8'} = '0';

2.27.3. TimeVacationDays::Calendar8

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Adds the permanent vacation days for the indicated calendar.

Please use single digit pattern for numbers from 1 to 9 (instead of 01 - 09).

Framework

Core::Time::Calendar8

$Self->{'TimeVacationDays::Calendar8'} = {

'1' => {

'1' => 'New Year\'s Day'

'12' => {

'24' => 'Christmas Eve',

'25' => 'First Christmas Day',

'26' => 'Second Christmas Day',

'31' => 'New Year\'s Eve'

'5' => {

'1' => 'International Workers\' Day'

}

};

2.27.4. TimeVacationDaysOneTime::Calendar8

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Adds the one time vacation days for the indicated calendar. Please use single digit pattern for numbers from 1 to 9 (instead of 01 - 09).

Framework

Core::Time::Calendar8

$Self->{'TimeVacationDaysOneTime::Calendar8'} = {

'2004' => {

'1' => {

'1' => 'test'

}

};

321

2.27.5. TimeWorkingHours::Calendar8

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the hours and week days of the indicated calendar, to count the working time.

Framework

Core::Time::Calendar8

'Sun' => [],

'Thu' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Tue' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

$Self->{'TimeWorkingHours::Calendar8'} = {

'Fri' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Mon' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Sat' => [],

322

'19',

'20'

'Wed' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

]

};

2.28. Core::Time::Calendar9

2.28.1. TimeZone::Calendar9Name

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the name of the indicated calendar.

Framework

Core::Time::Calendar9

$Self->{'TimeZone::Calendar9Name'} = 'Calendar Name 9';

2.28.2. TimeZone::Calendar9

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the time zone of the indicated calendar, which can be assigned later to a specific queue.

Framework

Core::Time::Calendar9

$Self->{'TimeZone::Calendar9'} = '0';

2.28.3. TimeVacationDays::Calendar9

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Adds the permanent vacation days for the indicated calendar.

Please use single digit pattern for numbers from 1 to 9 (instead of 01 - 09).

Framework

Core::Time::Calendar9

$Self->{'TimeVacationDays::Calendar9'} = {

'1' => {

'1' => 'New Year\'s Day'

'12' => {

'24' => 'Christmas Eve',

323

'25' => 'First Christmas Day',

'26' => 'Second Christmas Day',

'31' => 'New Year\'s Eve'

'5' => {

'1' => 'International Workers\' Day'

}

};

2.28.4. TimeVacationDaysOneTime::Calendar9

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Adds the one time vacation days for the indicated calendar. Please use single digit pattern for numbers from 1 to 9 (instead of 01 - 09).

Framework

Core::Time::Calendar9

$Self->{'TimeVacationDaysOneTime::Calendar9'} = {

'2004' => {

'1' => {

'1' => 'test'

}

};

2.28.5. TimeWorkingHours::Calendar9

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the hours and week days of the indicated calendar, to count the working time.

Framework

Core::Time::Calendar9

$Self->{'TimeWorkingHours::Calendar9'} = {

'Fri' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Mon' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

324

'20'

'Sat' => [],

'Sun' => [],

'Thu' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Tue' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

'Wed' => [

'8',

'9',

'10',

'11',

'12',

'13',

'14',

'15',

'16',

'17',

'18',

'19',

'20'

]

};

2.29. Core::Web

2.29.1. Frontend::WebPath

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the URL base path of icons, CSS and Java Script.

Framework

Core::Web

$Self->{'Frontend::WebPath'} = '/otrs-web/';

2.29.2. Frontend::ImagePath

Description: Defines the URL image path of icons for navigation.

325

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Framework

Core::Web

$Self->{'Frontend::ImagePath'} =

'<OTRS_CONFIG_Frontend::WebPath>skins/Agent/default/img/';

2.29.3. Frontend::CSSPath

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the URL CSS path.

Framework

Core::Web

$Self->{'Frontend::CSSPath'} =

'<OTRS_CONFIG_Frontend::WebPath>css/';

2.29.4. Frontend::JavaScriptPath

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the URL java script path.

Framework

Core::Web

$Self->{'Frontend::JavaScriptPath'} =

'<OTRS_CONFIG_Frontend::WebPath>js/';

2.29.5. Frontend::RichText

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Uses richtext for viewing and editing: articles, salutations, signatures, standard templates, auto responses and notifications.

Framework

Core::Web

$Self->{'Frontend::RichText'} = '1';

2.29.6. Frontend::RichTextPath

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the URL rich text editor path.

Framework

Core::Web

$Self->{'Frontend::RichTextPath'} =

'<OTRS_CONFIG_Frontend::WebPath>js/thirdparty/ckeditor-4.4.5/';

326

2.29.7. Frontend::RichTextWidth

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the width for the rich text editor component. Enter number

(pixels) or percent value (relative).

Framework

Core::Web

$Self->{'Frontend::RichTextWidth'} = '620';

2.29.8. Frontend::RichTextHeight

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the height for the rich text editor component. Enter number (pixels) or percent value (relative).

Framework

Core::Web

$Self->{'Frontend::RichTextHeight'} = '320';

2.29.9. Frontend::RichText::DefaultCSS

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default CSS used in rich text editors.

Framework

Core::Web

$Self->{'Frontend::RichText::DefaultCSS'} = 'fontfamily:Geneva,Helvetica,Arial,sans-serif; font-size: 12px;';

2.29.10. Frontend::RichText::EnhancedMode

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines if the enhanced mode should be used (enables use of table, replace, subscript, superscript, paste from word, etc.).

Framework

Core::Web

$Self->{'Frontend::RichText::EnhancedMode'} = '0';

2.29.11. DisableMSIFrameSecurityRestricted

Description:

Group:

SubGroup:

Valid:

Required:

Disable restricted security for IFrames in IE. May be required for

SSO to work in IE8.

Framework

Core::Web

327

Config-Setting:

$Self->{'DisableMSIFrameSecurityRestricted'} = '0';

2.29.12. DisableContentSecurityPolicy

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Disable HTTP header "Content-Security-Policy" to allow loading of external script contents. Disabling this HTTP header can be a security issue! Only disable it, if you know what you are doing!

Framework

Core::Web

$Self->{'DisableContentSecurityPolicy'} = '0';

2.29.13. DefaultViewNewLine

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Automated line break in text messages after x number of chars.

Framework

Core::Web

$Self->{'DefaultViewNewLine'} = '90';

2.29.14. DefaultViewLines

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the number of lines that are displayed in text messages (e.g.

ticket lines in the QueueZoom).

Framework

Core::Web

$Self->{'DefaultViewLines'} = '6000';

2.29.15. Frontend::AnimationEnabled

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Turns on the animations used in the GUI. If you have problems with these animations (e.g. performance issues), you can turn them off here.

Framework

Core::Web

$Self->{'Frontend::AnimationEnabled'} = '1';

2.29.16. AttachmentDownloadType

Description: Allows choosing between showing the attachments of a ticket in the browser (inline) or just make them downloadable (attachment).

328

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Framework

Core::Web

$Self->{'AttachmentDownloadType'} = 'attachment';

2.29.17. WebMaxFileUpload

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the maximal size (in bytes) for file uploads via the browser.

Warning: Setting this option to a value which is too low could cause many masks in your OTRS instance to stop working (probably any mask which takes input from the user).

Framework

Core::Web

$Self->{'WebMaxFileUpload'} = '24000000';

2.29.18. WebUploadCacheModule

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Selects the module to handle uploads via the web interface. "DB" stores all uploads in the database, "FS" uses the file system.

Framework

Core::Web

$Self->{'WebUploadCacheModule'} =

'Kernel::System::Web::UploadCache::DB';

2.29.19. Frontend::Output::FilterText###AAAURL

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the filter that processes the text in the articles, in order to highlight URLs.

Framework

Core::Web

$Self->{'Frontend::Output::FilterText'}->{'AAAURL'} = {

'Module' => 'Kernel::Output::HTML::OutputFilterTextURL',

'Templates' => {

'AgentTicketZoom' => '1'

}

};

2.29.20. Frontend::Themes

Description:

Group:

SubGroup:

Activates the available themes on the system. Value 1 means active, 0 means inactive.

Framework

Core::Web

329

Valid:

Required:

Config-Setting:

$Self->{'Frontend::Themes'} = {

'Lite' => '0',

'Standard' => '1'

};

2.29.21.

Frontend::Output::FilterText###OutputFilterTextAutoLink

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines a filter to process the text in the articles, in order to highlight predefined keywords.

Framework

Core::Web

$Self->{'Frontend::Output::FilterText'}-

>{'OutputFilterTextAutoLink'} = {

'Module' => 'Kernel::Output::HTML::OutputFilterTextAutoLink',

'Templates' => {

'AgentTicketZoom' => '1'

}

};

2.29.22.

Frontend::Output::OutputFilterTextAutoLink###CVE

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines a filter for html output to add links behind CVE numbers.

The element Image allows two input kinds. At once the name of an image (e.g. faq.png). In this case the OTRS image path will be used. The second possiblity is to insert the link to the image.

Framework

Core::Web

$Self->{'Frontend::Output::OutputFilterTextAutoLink'}->{'CVE'} = {

'RegExp' => [

'(CVE|CAN)\\-(\\d{3,4})\\-(\\d{2,})'

'Templates' => {

'AgentTicketZoom' => '1'

'URL1' => {

'Description' => 'Mitre',

'Image' => 'http://cve.mitre.org/favicon.ico',

'Target' => '_blank',

'URL' => 'http://cve.mitre.org/cgi-bin/cvename.cgi?

name=<MATCH1>-<MATCH2>-<MATCH3>'

'URL2' => {

'Description' => 'Google',

'Image' => 'http://www.google.de/favicon.ico',

'Target' => '_blank',

'URL' => 'http://google.com/search?q=<MATCH1>-<MATCH2>-<MATCH3>'

'URL3' => {

'Description' => 'US-CERT NVD',

'Image' => 'http://nvd.nist.gov/favicon.ico',

330

'Target' => '_blank',

'URL' => 'http://nvd.nist.gov/nvd.cfm?cvename=<MATCH1>-<MATCH2>-

<MATCH3>'

}

};

2.29.23.

Frontend::Output::OutputFilterTextAutoLink###Bugtraq

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines a filter for html output to add links behind bugtraq numbers. The element Image allows two input kinds. At once the name of an image (e.g. faq.png). In this case the OTRS image path will be used. The second possiblity is to insert the link to the image.

Framework

Core::Web

$Self->{'Frontend::Output::OutputFilterTextAutoLink'}->{'Bugtraq'}

= {

'RegExp' => [

'Bugtraq[\\s\\w\\t]*?ID[\\s\\w\\t]*?:[\\s\\w\\t]*?(\\d{2,8})',

'Bugtraq[\\s\\w\\t]*?ID[\\s\\w\\t]*?(\\d{2,8})',

'Bugtraq[\\s\\w\\t]*?:[\\s\\w\\t]*?(\\d{2,8})',

'Bugtraq[\\s\\w\\t]*?(\\d{2,8})',

'BID[\\s\\w\\t]*?:[\\s\\w\\t]*?(\\d{2,8})',

'BID[\\s\\w\\t]*?(\\d{2,8})'

'Templates' => {

'AgentTicketZoom' => '1'

'URL1' => {

'Description' => 'Security Focus',

'Image' => 'http://www.securityfocus.com/favicon.ico',

'Target' => '_blank',

'URL' => 'http://www.securityfocus.com/bid/<MATCH1>/info'

'URL2' => {

'Description' => 'Google',

'Image' => 'http://www.google.de/favicon.ico',

'Target' => '_blank',

'URL' => 'http://google.com/search?q=<MATCH>'

}

};

2.29.24.

Frontend::Output::OutputFilterTextAutoLink###MSBulletins

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines a filter for html output to add links behind MSBulletin numbers. The element Image allows two input kinds. At once the name of an image (e.g. faq.png). In this case the OTRS image path will be used. The second possiblity is to insert the link to the image.

Framework

Core::Web

$Self->{'Frontend::Output::OutputFilterTextAutoLink'}-

>{'MSBulletins'} = {

'RegExp' => [

'MS[^A-Za-z]{0,5}(\\d\\d).?(\\d{2,4})'

331

'Templates' => {

'AgentTicketZoom' => '1'

'URL1' => {

'Description' => 'Microsoft Technet',

'Image' => 'http://www.microsoft.com/favicon.ico',

'Target' => '_blank',

'URL' => 'http://www.microsoft.com/technet/security/bulletin/

MS<MATCH1>-<MATCH2>.mspx'

'URL2' => {

'Description' => 'Google',

'Image' => 'http://www.google.de/favicon.ico',

'Target' => '_blank',

'URL' => 'http://google.com/search?q=MS<MATCH1>-<MATCH2>'

}

};

2.29.25.

Frontend::Output::OutputFilterTextAutoLink###Setting1

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Define a filter for html output to add links behind a defined string.

The element Image allows two input kinds. At once the name of an image (e.g. faq.png). In this case the OTRS image path will be used. The second possiblity is to insert the link to the image.

Framework

Core::Web

$Self->{'Frontend::Output::OutputFilterTextAutoLink'}->{'Setting1'}

= {

'RegExp' => [

'RegExp'

'Templates' => {

'AgentTicketZoom' => '1'

'URL1' => {

'Description' => 'Description',

'Image' => 'right-small.png',

'Target' => '_blank',

'URL' => 'URL'

'URL2' => {

'Description' => 'Description',

'Image' => 'Image',

'Target' => '_blank',

'URL' => 'URL'

}

};

2.29.26.

Frontend::Output::OutputFilterTextAutoLink###Setting2

Description:

Group:

SubGroup:

Valid:

Defines a filter for html output to add links behind a defined string.

The element Image allows two input kinds. At once the name of an image (e.g. faq.png). In this case the OTRS image path will be used. The second possiblity is to insert the link to the image.

Framework

Core::Web

332

Required:

Config-Setting:

$Self->{'Frontend::Output::OutputFilterTextAutoLink'}->{'Setting2'}

= {

'RegExp' => [

'RegExp'

'Templates' => {

'AgentTicketZoom' => '1'

'URL1' => {

'Description' => 'Description',

'Image' => 'right-small.png',

'Target' => '_blank',

'URL' => 'URL'

'URL2' => {

'Description' => 'Description',

'Image' => 'Image',

'Target' => '_blank',

'URL' => 'URL'

'URL3' => {

'Description' => 'Description',

'Image' => 'Image',

'Target' => '_blank',

'URL' => 'URL'

}

};

2.29.27. Loader::Enabled::CSS

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If enabled, OTRS will deliver all CSS files in minified form.

WARNING: If you turn this off, there will likely be problems in IE 7, because it cannot load more than 32 CSS files.

Framework

Core::Web

$Self->{'Loader::Enabled::CSS'} = '1';

2.29.28. Loader::Enabled::JS

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If enabled, OTRS will deliver all JavaScript files in minified form.

Framework

Core::Web

$Self->{'Loader::Enabled::JS'} = '1';

2.29.29. Loader::Agent::CommonCSS###000-Framework

Description:

Group:

SubGroup:

Valid:

List of CSS files to always be loaded for the agent interface.

Framework

Core::Web

333

Required:

Config-Setting:

$Self->{'Loader::Agent::CommonCSS'}->{'000-Framework'} = [

'Core.Reset.css',

'Core.Default.css',

'Core.Header.css',

'Core.OverviewControl.css',

'Core.OverviewSmall.css',

'Core.OverviewMedium.css',

'Core.OverviewLarge.css',

'Core.Footer.css',

'Core.PageLayout.css',

'Core.Form.css',

'Core.Table.css',

'Core.Widget.css',

'Core.WidgetMenu.css',

'Core.TicketDetail.css',

'Core.Tooltip.css',

'Core.Dialog.css',

'Core.Print.css',

'thirdparty/fontawesome/font-awesome.css'

];

2.29.30. Loader::Agent::CommonCSS::IE8###000-

Framework

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

List of IE8-specific CSS files to always be loaded for the agent interface.

Framework

Core::Web

$Self->{'Loader::Agent::CommonCSS::IE8'}->{'000-Framework'} = [

'Core.OverviewSmall.IE8.css'

];

2.29.31. Loader::Agent::CommonJS###000-Framework

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

List of JS files to always be loaded for the agent interface.

Framework

Core::Web

$Self->{'Loader::Agent::CommonJS'}->{'000-Framework'} = [

'thirdparty/jquery-1.10.0/jquery.js',

'thirdparty/jquery-browser-detection/jquery-browser-detection.js',

'thirdparty/jquery-ui-1.10.3/jquery-ui.js',

'thirdparty/jquery-validate-1.11.1/jquery.validate.js',

'thirdparty/stacktrace-0.4/stacktrace.js',

'thirdparty/jquery-pubsub/pubsub.js',

'thirdparty/jquery-jstree-v.pre1.0/jquery.jstree.js',

'thirdparty/jquery-jstree-v.pre1.0/_lib/jquery.hotkeys.js',

'Core.JavaScriptEnhancements.js',

'Core.Debug.js',

'Core.Data.js',

'Core.Config.js',

'Core.Exception.js',

'Core.JSON.js',

'Core.App.js',

'Core.AJAX.js',

'Core.UI.js',

334

'Core.UI.Accordion.js',

'Core.UI.Datepicker.js',

'Core.UI.Resizable.js',

'Core.UI.Table.js',

'Core.UI.Accessibility.js',

'Core.UI.RichTextEditor.js',

'Core.UI.Dialog.js',

'Core.UI.ActionRow.js',

'Core.UI.Popup.js',

'Core.UI.TreeSelection.js',

'Core.UI.Autocomplete.js',

'Core.Form.js',

'Core.Form.ErrorTooltips.js',

'Core.Form.Validate.js',

'Core.Agent.js',

'Core.Agent.Search.js',

'Core.Agent.CustomerInformationCenterSearch.js'

];

2.29.32. Loader::Agent::CommonJS###001-JQueryMigrate

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

List of JS files to always be loaded for the agent interface.

Framework

Core::Web

$Self->{'Loader::Agent::CommonJS'}->{'001-JQueryMigrate'} = [

'thirdparty/jquery-migrate-1.2.1/jquery-migrate.js'

];

2.29.33. Loader::Customer::CommonCSS###000-

Framework

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

List of CSS files to always be loaded for the customer interface.

Framework

Core::Web

$Self->{'Loader::Customer::CommonCSS'}->{'000-Framework'} = [

'Core.Reset.css',

'Core.Default.css',

'Core.Form.css',

'Core.Dialog.css',

'Core.Tooltip.css',

'Core.Login.css',

'Core.Control.css',

'Core.Table.css',

'Core.TicketZoom.css',

'Core.Print.css',

'thirdparty/fontawesome/font-awesome.css'

];

2.29.34. Loader::Customer::CommonCSS::IE8###000-

Framework

Description: List of IE8-specific CSS files to always be loaded for the customer interface.

335

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Framework

Core::Web

$Self->{'Loader::Customer::CommonCSS::IE8'}->{'000-Framework'} =

[];

2.29.35. Loader::Customer::CommonJS###000-Framework

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

List of JS files to always be loaded for the customer interface.

Framework

Core::Web

$Self->{'Loader::Customer::CommonJS'}->{'000-Framework'} = [

'thirdparty/jquery-1.10.0/jquery.js',

'thirdparty/jquery-browser-detection/jquery-browser-detection.js',

'thirdparty/jquery-validate-1.11.1/jquery.validate.js',

'thirdparty/jquery-ui-1.10.3/jquery-ui.js',

'thirdparty/stacktrace-0.4/stacktrace.js',

'thirdparty/jquery-pubsub/pubsub.js',

'thirdparty/jquery-jstree-v.pre1.0/jquery.jstree.js',

'thirdparty/jquery-jstree-v.pre1.0/_lib/jquery.hotkeys.js',

'Core.Debug.js',

'Core.Data.js',

'Core.Exception.js',

'Core.JSON.js',

'Core.JavaScriptEnhancements.js',

'Core.Config.js',

'Core.App.js',

'Core.AJAX.js',

'Core.UI.js',

'Core.UI.Accessibility.js',

'Core.UI.Dialog.js',

'Core.UI.RichTextEditor.js',

'Core.UI.Datepicker.js',

'Core.UI.Popup.js',

'Core.UI.TreeSelection.js',

'Core.UI.Autocomplete.js',

'Core.Form.js',

'Core.Form.ErrorTooltips.js',

'Core.Form.Validate.js',

'Core.Customer.js'

];

2.29.36. Loader::Customer::CommonJS###001-JQuery-

Migrate

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

List of JS files to always be loaded for the agent interface.

Framework

Core::Web

$Self->{'Loader::Customer::CommonJS'}->{'001-JQueryMigrate'} = [

'thirdparty/jquery-migrate-1.2.1/jquery-migrate.js'

];

336

2.29.37. Loader::Agent::DefaultSelectedSkin

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

The agent skin's InternalName which should be used in the agent interface. Please check the available skins in

Frontend::Agent::Skins.

Framework

Core::Web

$Self->{'Loader::Agent::DefaultSelectedSkin'} = 'default';

2.29.38. Loader::Customer::SelectedSkin::HostBased

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

It is possible to configure different skins, for example to distinguish between diferent customers, to be used on a per-domain basis within the application. Using a regular expression (regex), you can configure a Key/Content pair to match a domain. The value in "Key" should match the domain, and the value in "Content" should be a valid skin on your system. Please see the example entries for the proper form of the regex.

Framework

Core::Web

$Self->{'Loader::Customer::SelectedSkin::HostBased'} = {

'host1\\.example\\.com' => 'Someskin1',

'host2\\.example\\.com' => 'Someskin2'

};

2.30. Core::WebUserAgent

2.30.1. WebUserAgent::Timeout

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the timeout (in seconds) for http/ftp downloads.

Framework

Core::WebUserAgent

$Self->{'WebUserAgent::Timeout'} = '15';

2.30.2. WebUserAgent::Proxy

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the connections for http/ftp, via a proxy.

Framework

Core::WebUserAgent

$Self->{'WebUserAgent::Proxy'} = 'http://proxy.sn.no:8001/';

337

2.30.3. WebUserAgent::DisableSSLVerification

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Turns off SSL certificate validation, for example if you use a transparent HTTPS proxy. Use at your own risk!

Framework

Core::WebUserAgent

$Self->{'WebUserAgent::DisableSSLVerification'} = '0';

2.31. Crypt::PGP

2.31.1. PGP

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

2.31.2. PGP::Bin

Enables PGP support. When PGP support is enabled for signing and encrypting mail, it is HIGHLY recommended that the web server runs as the OTRS user. Otherwise, there will be problems with the privileges when accessing .gnupg folder.

Framework

Crypt::PGP

$Self->{'PGP'} = '0';

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the path to PGP binary.

Framework

Crypt::PGP

$Self->{'PGP::Bin'} = '/usr/bin/gpg';

2.31.3. PGP::Options

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the options for PGP binary.

Framework

Crypt::PGP

$Self->{'PGP::Options'} = '--homedir /opt/otrs/.gnupg/ --batch -no-tty --yes';

2.31.4. PGP::Key::Password

Description: Sets the password for private PGP key.

338

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Framework

Crypt::PGP

$Self->{'PGP::Key::Password'} = {

'488A0B8F' => 'SomePassword',

'D2DF79FA' => 'SomePassword'

};

2.31.5. PGP::TrustedNetwork

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

2.31.6. PGP::Log

Set this to yes if you trust in all your public and private pgp keys, even if they are not certified with a trusted signature.

Framework

Crypt::PGP

$Self->{'PGP::TrustedNetwork'} = '0';

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Configure your own log text for PGP.

Framework

Crypt::PGP

$Self->{'PGP::Log'} = {

'BADSIG' => 'The PGP signature with the keyid has not been

verified successfully.',

'ERRSIG' => 'It was not possible to check the PGP signature,

this may be caused by a missing public key or an unsupported

algorithm.',

'EXPKEYSIG' => 'The PGP signature was made by an expired key.',

'GOODSIG' => 'Good PGP signature.',

'KEYREVOKED' => 'The PGP signature was made by a revoked key, this

could mean that the signature is forged.',

'NODATA' => 'No valid OpenPGP data found.',

'NO_PUBKEY' => 'No public key found.',

'REVKEYSIG' => 'The PGP signature was made by a revoked key, this

could mean that the signature is forged.',

'SIGEXPIRED' => 'The PGP signature is expired.',

'SIG_ID' => 'Signature data.',

'TRUST_UNDEFINED' => 'This key is not certified with a trusted

signature!.',

'VALIDSIG' => 'The PGP signature with the keyid is good.'

};

2.31.7. PGP::StoreDecryptedData

Description:

Group:

SubGroup:

Valid:

If this option is enabled, then the decrypted data will be stored in the database if they are displayed in AgentTicketZoom.

Framework

Crypt::PGP

339

Required:

Config-Setting:

$Self->{'PGP::StoreDecryptedData'} = '1';

2.32. Crypt::SMIME

2.32.1. SMIME

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Enables S/MIME support.

Framework

Crypt::SMIME

$Self->{'SMIME'} = '0';

2.32.2. SMIME::Bin

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the path to open ssl binary. It may need a HOME env

($ENV{HOME} = '/var/lib/wwwrun';).

Framework

Crypt::SMIME

$Self->{'SMIME::Bin'} = '/usr/bin/openssl';

2.32.3. SMIME::CertPath

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the directory where SSL certificates are stored.

Framework

Crypt::SMIME

$Self->{'SMIME::CertPath'} = '/etc/ssl/certs';

2.32.4. SMIME::PrivatePath

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the directory where private SSL certificates are stored.

Framework

Crypt::SMIME

$Self->{'SMIME::PrivatePath'} = '/etc/ssl/private';

2.32.5. SMIME::CacheTTL

Description: Cache time in seconds for the SSL certificate attributes.

340

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Framework

Crypt::SMIME

$Self->{'SMIME::CacheTTL'} = '86400';

2.32.6. SMIME::StoreDecryptedData

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If this option is enabled, then the decrypted data will be stored in the database if they are displayed in AgentTicketZoom.

Framework

Crypt::SMIME

$Self->{'SMIME::StoreDecryptedData'} = '1';

2.33. CustomerInformationCenter

2.33.1.

AgentCustomerInformationCenter::MainMenu###010-

EditCustomerID

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Main menu registration.

Framework

CustomerInformationCenter

$Self->{'AgentCustomerInformationCenter::MainMenu'}->{'010-

EditCustomerID'} = {

'Link' =>

'$Env{"Baselink"}Action=AdminCustomerCompany;Subaction=Change;CustomerID=

$LQData{"CustomerID"};Nav=0',

'Name' => 'Edit customer company'

};

2.34. Frontend::Admin

2.34.1. Events###Package

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

List of all Package events to be displayed in the GUI.

Framework

Frontend::Admin

$Self->{'Events'}->{'Package'} = [

'PackageInstall',

'PackageReinstall',

'PackageUpgrade',

341

'PackageUninstall'

];

2.34.2. Events###CustomerUser

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

List of all CustomerUser events to be displayed in the GUI.

Framework

Frontend::Admin

$Self->{'Events'}->{'CustomerUser'} = [

'CustomerUserAdd',

'CustomerUserUpdate'

];

2.34.3. Events###CustomerCompany

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

List of all CustomerCompany events to be displayed in the GUI.

Framework

Frontend::Admin

$Self->{'Events'}->{'CustomerCompany'} = [

'CustomerCompanyAdd',

'CustomerCompanyUpdate'

];

2.35. Frontend::Admin::AdminCustomerUser

2.35.1. AdminCustomerUser::RunInitialWildcardSearch

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Runs an initial wildcard search of the existing customer users when accessing the AdminCustomerUser module.

Framework

Frontend::Admin::AdminCustomerUser

$Self->{'AdminCustomerUser::RunInitialWildcardSearch'} = '1';

2.36. Frontend::Admin::AdminSelectBox

2.36.1. AdminSelectBox::AllowDatabaseModification

Description:

Group:

SubGroup:

Valid:

Controls if the admin is allowed to make changes to the database via AdminSelectBox.

Framework

Frontend::Admin::AdminSelectBox

342

Required:

Config-Setting:

$Self->{'AdminSelectBox::AllowDatabaseModification'} = '0';

2.37. Frontend::Admin::ModuleRegistration

2.37.1. Frontend::Module###Admin

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'Admin'} = {

'Description' => 'Admin-Area',

'Group' => [

'admin'

'Loader' => {

'CSS' => [

'Core.Agent.Admin.css'

'JavaScript' => [

'Core.Agent.Admin.SysConfig.js'

]

'NavBar' => [

{

'AccessKey' => 'a',

'Block' => 'ItemArea',

'Description' => '',

'Link' => 'Action=Admin',

'LinkOption' => '',

'Name' => 'Admin',

'NavBar' => 'Admin',

'Prio' => '10000',

'Type' => 'Menu'

}

'NavBarModule' => {

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin'

'NavBarName' => 'Admin',

'Title' => ''

};

2.37.2. Frontend::Module###AdminInit

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminInit'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarName' => '',

'Title' => 'Init'

};

343

2.37.3. Frontend::Module###AdminUser

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminUser'} = {

'Description' => 'Create and manage agents.',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'Agent',

'Description' => 'Create and manage agents.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Agents',

'Prio' => '100'

'NavBarName' => 'Admin',

'Title' => 'Agents'

};

2.37.4. Frontend::Module###AdminGroup

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminGroup'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'Agent',

'Description' => 'Create and manage groups.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Groups',

'Prio' => '150'

'NavBarName' => 'Admin',

'Title' => 'Groups'

};

2.37.5. Frontend::Module###AdminUserGroup

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminUserGroup'} = {

'Description' => 'Admin',

'Group' => [

'admin'

344

'NavBarModule' => {

'Block' => 'Agent',

'Description' => 'Link agents to groups.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Agents <-> Groups',

'Prio' => '200'

'NavBarName' => 'Admin',

'Title' => 'Agents <-> Groups'

};

2.37.6. Frontend::Module###AdminCustomerUser

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminCustomerUser'} = {

'Description' => 'Edit Customer Users',

'Group' => [

'admin',

'users'

'GroupRo' => [

'Loader' => {

'JavaScript' => [

'Core.Agent.TicketAction.js'

]

'NavBar' => [

{

'AccessKey' => '',

'Block' => 'ItemArea',

'Description' => 'Customer User Administration.',

'Link' => 'Action=AdminCustomerUser;Nav=Agent',

'LinkOption' => '',

'Name' => 'Customer User Administration',

'NavBar' => 'Customers',

'Prio' => '9000',

'Type' => ''

}

'NavBarModule' => {

'Block' => 'Customer',

'Description' => 'Create and manage customer users.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Customer User',

'Prio' => '300'

'NavBarName' => 'Customers',

'Title' => 'Customer Users'

};

2.37.7. Frontend::Module###AdminCustomerCompany

Description:

Group:

SubGroup:

Valid:

Required:

Frontend module registration for the agent interface.

Framework

Frontend::Admin::ModuleRegistration

345

Config-Setting:

$Self->{'Frontend::Module'}->{'AdminCustomerCompany'} = {

'Description' => 'Admin',

'Group' => [

'admin',

'users'

'GroupRo' => [

'NavBar' => [

{

'AccessKey' => '',

'Block' => 'ItemArea',

'Description' => 'Customer Company Administration.',

'Link' => 'Action=AdminCustomerCompany;Nav=Agent',

'LinkOption' => '',

'Name' => 'Customer Company Administration',

'NavBar' => 'Customers',

'Prio' => '9100',

'Type' => ''

}

'NavBarModule' => {

'Block' => 'Customer',

'Description' => 'Create and manage customers.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Customers',

'Prio' => '310'

'NavBarName' => 'Admin',

'Title' => 'Customer Companies'

};

2.37.8.

Frontend::Module###AdminCustomerUserGroup

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminCustomerUserGroup'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'Customer',

'Description' => 'Link customer user to groups.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Customer User <-> Groups',

'Prio' => '400'

'NavBarName' => 'Admin',

'Title' => 'Customers <-> Groups'

};

2.37.9.

Frontend::Module###AdminCustomerUserService

Description:

Group:

SubGroup:

Frontend module registration for the agent interface.

Framework

Frontend::Admin::ModuleRegistration

346

Valid:

Required:

Config-Setting:

$Self->{'Frontend::Module'}->{'AdminCustomerUserService'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'Customer',

'Description' => 'Link customer user to services.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Customer User <-> Services',

'Prio' => '500'

'NavBarName' => 'Admin',

'Title' => 'Customer User <-> Services'

};

2.37.10. Frontend::Module###AdminRole

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminRole'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'Agent',

'Description' => 'Create and manage roles.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Roles',

'Prio' => '600'

'NavBarName' => 'Admin',

'Title' => 'Roles'

};

2.37.11. Frontend::Module###AdminRoleUser

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminRoleUser'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'Agent',

'Description' => 'Link agents to roles.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Agents <-> Roles',

'Prio' => '700'

'NavBarName' => 'Admin',

347

'Title' => 'Agents <-> Roles'

};

2.37.12. Frontend::Module###AdminRoleGroup

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminRoleGroup'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'Agent',

'Description' => 'Link roles to groups.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Roles <-> Groups',

'Prio' => '800'

'NavBarName' => 'Admin',

'Title' => 'Roles <-> Groups'

};

2.37.13. Frontend::Module###AdminSMIME

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminSMIME'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'Email',

'Description' => 'Manage S/MIME certificates for email

encryption.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'S/MIME Certificates',

'Prio' => '1100'

'NavBarName' => 'Admin',

'Title' => 'S/MIME Management'

};

2.37.14. Frontend::Module###AdminPGP

Description:

Group:

SubGroup:

Valid:

Required:

Frontend module registration for the agent interface.

Framework

Frontend::Admin::ModuleRegistration

348

Config-Setting:

$Self->{'Frontend::Module'}->{'AdminPGP'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'Email',

'Description' => 'Manage PGP keys for email encryption.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'PGP Keys',

'Prio' => '1200'

'NavBarName' => 'Admin',

'Title' => 'PGP Key Management'

};

2.37.15. Frontend::Module###AdminMailAccount

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminMailAccount'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'Email',

'Description' => 'Manage POP3 or IMAP accounts to fetch email

from.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'PostMaster Mail Accounts',

'Prio' => '100'

'NavBarName' => 'Admin',

'Title' => 'Mail Accounts'

};

2.37.16. Frontend::Module###AdminPostMasterFilter

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminPostMasterFilter'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'Email',

'Description' => 'Filter incoming emails.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'PostMaster Filters',

'Prio' => '200'

'NavBarName' => 'Admin',

'Title' => 'PostMaster Filters'

};

349

2.37.17. Frontend::Module###AdminEmail

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminEmail'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'System',

'Description' => 'Send notifications to users.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Admin Notification',

'Prio' => '400'

'NavBarName' => 'Admin',

'Title' => 'Admin Notification'

};

2.37.18. Frontend::Module###AdminSession

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminSession'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'System',

'Description' => 'Manage existing sessions.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Session Management',

'Prio' => '500'

'NavBarName' => 'Admin',

'Title' => 'Session Management'

};

2.37.19. Frontend::Module###AdminPerformanceLog

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminPerformanceLog'} = {

'Description' => 'Admin',

'Group' => [

'admin'

350

'Loader' => {

'CSS' => [

'Core.Agent.Admin.PerformanceLog.css'

]

'NavBarModule' => {

'Block' => 'System',

'Description' => 'View performance benchmark results.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Performance Log',

'Prio' => '550'

'NavBarName' => 'Admin',

'Title' => 'Performance Log'

};

2.37.20. Frontend::Module###AdminRegistration

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminRegistration'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'Loader' => {

'CSS' => [

'Core.Agent.Admin.Registration.css'

]

'NavBarModule' => {

'Block' => 'System',

'Description' => 'Manage system registration.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'System Registration',

'Prio' => '350'

'NavBarName' => 'Admin',

'Title' => 'System Registration'

};

2.37.21. Frontend::Module###AdminServiceCenter

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminServiceCenter'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'Loader' => {

'CSS' => [

'Core.Agent.Admin.ServiceCenter.css'

]

351

'NavBarModule' => {

'Block' => 'System',

'Description' => 'Manage OTRS Group services.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Service Center',

'Prio' => '351'

'NavBarName' => 'Admin',

'Title' => 'Service Center'

};

2.37.22. Frontend::Module###AdminLog

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminLog'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'System',

'Description' => 'View system log messages.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'System Log',

'Prio' => '600'

'NavBarName' => 'Admin',

'Title' => 'System Log'

};

2.37.23. Frontend::Module###AdminSelectBox

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminSelectBox'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'System',

'Description' => 'Execute SQL statements.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'SQL Box',

'Prio' => '700'

'NavBarName' => 'Admin',

'Title' => 'SQL Box'

};

2.37.24. Frontend::Module###AdminPackageManager

Description: Frontend module registration for the agent interface.

352

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Framework

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminPackageManager'} = {

'Description' => 'Software Package Manager',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'System',

'Description' => 'Update and extend your system with software

packages.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Package Manager',

'Prio' => '1000'

'NavBarName' => 'Admin',

'Title' => 'Package Manager'

};

2.38. Frontend::Agent

2.38.1. AgentLogo

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

The logo shown in the header of the agent interface. The URL to the image can be a relative URL to the skin image directory, or a full URL to a remote web server.

Framework

Frontend::Agent

$Self->{'AgentLogo'} = {

'StyleHeight' => '67px',

'StyleRight' => '38px',

'StyleTop' => '-4px',

'StyleWidth' => '244px',

'URL' => 'skins/Agent/default/img/logo_bg.png'

};

2.38.2. AgentLoginLogo

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

The logo shown on top of the login box of the agent interface. The

URL to the image must be relative URL to the skin image directory.

Framework

Frontend::Agent

$Self->{'AgentLoginLogo'} = {

'StyleHeight' => '100px',

'URL' => 'skins/Agent/default/img/loginlogo_default.png'

};

2.38.3. LoginURL

Description: Defines an alternate URL, where the login link refers to.

353

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Framework

Frontend::Agent

$Self->{'LoginURL'} = 'http://host.example.com/login.html';

2.38.4. LogoutURL

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines an alternate URL, where the logout link refers to.

Framework

Frontend::Agent

$Self->{'LogoutURL'} = 'http://host.example.com/thanks-for-usingotrs.html';

2.38.5. PreApplicationModule###AgentInfo

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

2.38.6. InfoKey

Defines a useful module to load specific user options or to display news.

Framework

Frontend::Agent

$Self->{'PreApplicationModule'}->{'AgentInfo'} =

'Kernel::Modules::AgentInfo';

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

2.38.7. InfoFile

Defines the key to be checked with Kernel::Modules::AgentInfo module. If this user preferences key is true, the message is accepted by the system.

Framework

Frontend::Agent

$Self->{'InfoKey'} = 'wpt22';

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

File that is displayed in the Kernel::Modules::AgentInfo module, if located under Kernel/Output/HTML/Standard/AgentInfo.dtl.

Framework

Frontend::Agent

$Self->{'InfoFile'} = 'AgentInfo';

354

2.38.8. LostPassword

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

2.38.9. ShowMotd

Activates lost password feature for agents, in the agent interface.

Framework

Frontend::Agent

$Self->{'LostPassword'} = '1';

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows the message of the day on login screen of the agent interface.

Framework

Frontend::Agent

$Self->{'ShowMotd'} = '0';

2.38.10. NotificationSubjectLostPasswordToken

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the subject for notification mails sent to agents, with token about new requested password.

Framework

Frontend::Agent

$Self->{'NotificationSubjectLostPasswordToken'} = 'New OTRS

password request';

2.38.11. NotificationBodyLostPasswordToken

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the body text for notification mails sent to agents, with token about new requested password (after using this link the new password will be sent).

Framework

Frontend::Agent

$Self->{'NotificationBodyLostPasswordToken'} = 'Hi

<OTRS_USERFIRSTNAME>,

You or someone impersonating you has requested to change your OTRS password.

If you want to do this, click on the link below. You will receive

another email containing the password.

<OTRS_CONFIG_HttpType>://<OTRS_CONFIG_FQDN>/

<OTRS_CONFIG_ScriptAlias>index.pl?

Action=LostPassword;Token=<OTRS_TOKEN>

355

If you did not request a new password, please ignore this email.

2.38.12. NotificationSubjectLostPassword

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the subject for notification mails sent to agents, about new password.

Framework

Frontend::Agent

$Self->{'NotificationSubjectLostPassword'} = 'New OTRS password';

2.38.13. NotificationBodyLostPassword

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the body text for notification mails sent to agents, about new password (after using this link the new password will be sent).

Framework

Frontend::Agent

$Self->{'NotificationBodyLostPassword'} = 'Hi

<OTRS_USERFIRSTNAME>,

Here\'s your new OTRS password.

New password: <OTRS_NEWPW>

You can log in via the following URL:

<OTRS_CONFIG_HttpType>://<OTRS_CONFIG_FQDN>/

<OTRS_CONFIG_ScriptAlias>index.pl

2.38.14. OpenMainMenuOnHover

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If enabled, the first level of the main menu opens on mouse hover

(instead of click only).

Framework

Frontend::Agent

$Self->{'OpenMainMenuOnHover'} = '0';

2.38.15. FirstnameLastnameOrder

Description:

Group:

SubGroup:

Specifies the order in which the firstname and the lastname of agents will be displayed.

Framework

Frontend::Agent

356

Valid:

Required:

Config-Setting:

$Self->{'FirstnameLastnameOrder'} = '0';

2.38.16. Loader::Agent::Skin###000-default

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Default skin for the agent interface.

Framework

Frontend::Agent

$Self->{'Loader::Agent::Skin'}->{'000-default'} = {

'Description' => 'This is the default orange - black skin.',

'HomePage' => 'www.otrs.org',

'InternalName' => 'default',

'VisibleName' => 'Default'

};

2.38.17. Loader::Agent::Skin###001-slim

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Default skin for the agent interface (slim version).

Framework

Frontend::Agent

$Self->{'Loader::Agent::Skin'}->{'001-slim'} = {

'Description' => '"Slim" skin which tries to save screen space for

power users.',

'HomePage' => 'www.otrs.org',

'InternalName' => 'slim',

'VisibleName' => 'Default (Slim)'

};

2.38.18. Loader::Agent::Skin###001-ivory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Balanced white skin by Felix Niklas.

Framework

Frontend::Agent

$Self->{'Loader::Agent::Skin'}->{'001-ivory'} = {

'Description' => 'Balanced white skin by Felix Niklas.',

'HomePage' => 'www.felixniklas.de',

'InternalName' => 'ivory',

'VisibleName' => 'Ivory'

};

2.38.19. Loader::Agent::Skin###001-ivory-slim

Description:

Group:

SubGroup:

Balanced white skin by Felix Niklas (slim version).

Framework

Frontend::Agent

357

Valid:

Required:

Config-Setting:

$Self->{'Loader::Agent::Skin'}->{'001-ivory-slim'} = {

'Description' => 'Balanced white skin by Felix Niklas (slim

version).',

'HomePage' => 'www.felixniklas.de',

'InternalName' => 'ivory-slim',

'VisibleName' => 'Ivory (Slim)'

};

2.38.20.

Loader::Agent::DefaultSelectedSkin::HostBased

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

It is possible to configure different skins, for example to distinguish between diferent agents, to be used on a per-domain basis within the application. Using a regular expression (regex), you can configure a Key/Content pair to match a domain. The value in "Key" should match the domain, and the value in "Content" should be a valid skin on your system. Please see the example entries for the proper form of the regex.

Framework

Frontend::Agent

$Self->{'Loader::Agent::DefaultSelectedSkin::HostBased'} = {

'host1\\.example\\.com' => 'SomeSkin1',

'host2\\.example\\.com' => 'SomeSkin2'

};

2.38.21. AutoComplete::Agent###Default

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the config options for the autocompletion feature.

Framework

Frontend::Agent

$Self->{'AutoComplete::Agent'}->{'Default'} = {

'AutoCompleteActive' => '1',

'ButtonText' => 'Search',

'MaxResultsDisplayed' => '20',

'MinQueryLength' => '2',

'QueryDelay' => '100'

};

2.38.22. AutoComplete::Agent###CustomerSearch

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the config options for the autocompletion feature.

Framework

Frontend::Agent

$Self->{'AutoComplete::Agent'}->{'CustomerSearch'} = {

'AutoCompleteActive' => '1',

358

'ButtonText' => 'Search Customer',

'MaxResultsDisplayed' => '20',

'MinQueryLength' => '2',

'QueryDelay' => '100'

};

2.38.23. AutoComplete::Agent###UserSearch

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the config options for the autocompletion feature.

Framework

Frontend::Agent

$Self->{'AutoComplete::Agent'}->{'UserSearch'} = {

'AutoCompleteActive' => '1',

'ButtonText' => 'Search User',

'MaxResultsDisplayed' => '20',

'MinQueryLength' => '2',

'QueryDelay' => '100'

};

2.38.24. PossibleNextActions

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the list of possible next actions on an error screen.

Framework

Frontend::Agent

$Self->{'PossibleNextActions'} = {

'Go to dashboard!' => '$Env{"CGIHandle"}?Action=AgentDashboard'

};

2.39. Frontend::Agent::Dashboard

2.39.1.

AgentCustomerInformationCenter::Backend###0600-

CIC-CustomerCompanyInformation

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Parameters for the dashboard backend of the customer company information of the agent interface . "Group" is used to restrict the access to the plugin (e. g. Group: admin;group1;group2;).

"Default" determines if the plugin is enabled by default or if the user needs to enable it manually. "CacheTTLLocal" is the cache time in minutes for the plugin.

Framework

Frontend::Agent::Dashboard

$Self->{'AgentCustomerInformationCenter::Backend'}->{'0600-CIC-

CustomerCompanyInformation'} = {

'Attributes' => '',

'Block' => 'ContentSmall',

'Default' => '1',

359

'Description' => 'Customer Company Information',

'Group' => '',

'Module' =>

'Kernel::Output::HTML::DashboardCustomerCompanyInformation',

'Title' => 'Customer Company Information'

};

2.39.2. DashboardBackend###0000-ProductNotify

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the parameters for the dashboard backend. "Group" is used to restrict access to the plugin (e. g. Group: admin;group1;group2;). "Default" indicates if the plugin is enabled by default or if the user needs to enable it manually. "CacheTTLLocal" defines the cache expiration period in minutes for the plugin.

Framework

Frontend::Agent::Dashboard

$Self->{'DashboardBackend'}->{'0000-ProductNotify'} = {

'Block' => 'ContentLarge',

'CacheTTLLocal' => '1440',

'Default' => '1',

'Description' => 'News about OTRS releases!',

'Group' => 'admin',

'Module' => 'Kernel::Output::HTML::DashboardProductNotify',

'Title' => 'Product News',

'URL' => 'http://www.otrs.com/product.xml'

};

2.39.3. DashboardBackend###0390-UserOutOfOffice

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the parameters for the dashboard backend. "Limit" defines the number of entries displayed by default. "Group" is used to restrict access to the plugin (e. g. Group: admin;group1;group2;).

"Default" indicates if the plugin is enabled by default or if the user needs to enable it manually. "CacheTTLLocal" defines the cache expiration period in minutes for the plugin.

Framework

Frontend::Agent::Dashboard

$Self->{'DashboardBackend'}->{'0390-UserOutOfOffice'} = {

'Block' => 'ContentSmall',

'CacheTTLLocal' => '5',

'Default' => '1',

'Description' => '',

'Group' => '',

'IdleMinutes' => '60',

'Limit' => '10',

'Module' => 'Kernel::Output::HTML::DashboardUserOutOfOffice',

'SortBy' => 'UserFullname',

'Title' => 'Out Of Office'

};

2.39.4. DashboardBackend###0400-UserOnline

Description: Defines the parameters for the dashboard backend. "Limit" defines the number of entries displayed by default. "Group" is used to

360

Group:

SubGroup:

Valid:

Required:

Config-Setting: restrict access to the plugin (e. g. Group: admin;group1;group2;).

"Default" indicates if the plugin is enabled by default or if the user needs to enable it manually. "CacheTTLLocal" defines the cache expiration period in minutes for the plugin.

Framework

Frontend::Agent::Dashboard

$Self->{'DashboardBackend'}->{'0400-UserOnline'} = {

'Block' => 'ContentSmall',

'CacheTTLLocal' => '5',

'Default' => '0',

'Description' => '',

'Filter' => 'Agent',

'Group' => '',

'IdleMinutes' => '60',

'Limit' => '10',

'Module' => 'Kernel::Output::HTML::DashboardUserOnline',

'ShowEmail' => '0',

'SortBy' => 'UserFullname',

'Title' => 'Online'

};

2.39.5. DashboardBackend###0410-RSS

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the parameters for the dashboard backend. "Limit" defines the number of entries displayed by default. "Group" is used to restrict access to the plugin (e. g. Group: admin;group1;group2;).

"Default" indicates if the plugin is enabled by default or if the user needs to enable it manually. "CacheTTL" indicates the cache expiration period in minutes for the plugin.

Framework

Frontend::Agent::Dashboard

$Self->{'DashboardBackend'}->{'0410-RSS'} = {

'Block' => 'ContentSmall',

'CacheTTL' => '360',

'Default' => '1',

'Description' => '',

'Group' => '',

'Limit' => '6',

'Module' => 'Kernel::Output::HTML::DashboardRSS',

'Title' => 'OTRS News',

'URL' => 'http://www.otrs.com/en/rss.xml',

'URL_de' => 'http://www.otrs.com/de/rss.xml',

'URL_es' => 'http://www.otrs.com/es/rss.xml',

'URL_nl' => 'http://www.otrs.com/nl/rss.xml',

'URL_ru' => 'http://www.otrs.com/ru/rss.xml',

'URL_zh' => 'http://www.otrs.com/cn/rss.xml'

};

2.39.6. DashboardBackend###0200-Image

Description: Defines the parameters for the dashboard backend. "Group" is used to restrict access to the plugin (e. g. Group: admin;group1;group2;). "Default" indicates if the plugin is enabled by default or if the user needs to enable it manually. "CacheTTL" indicates the cache expiration period in minutes for the plugin.

361

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Framework

Frontend::Agent::Dashboard

$Self->{'DashboardBackend'}->{'0200-Image'} = {

'Block' => 'ContentLarge',

'Default' => '1',

'Description' => 'Some picture description!',

'Group' => '',

'Height' => '140',

'Link' => 'http://otrs.org/',

'LinkTitle' => 'http://otrs.org/',

'Module' => 'Kernel::Output::HTML::DashboardImage',

'Title' => 'A picture',

'URL' => 'http://www.otrs.com/uploads/pics/ jointhecommunity_02.jpg',

'Width' => '198'

};

2.39.7. DashboardBackend###0210-MOTD

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows the message of the day (MOTD) in the agent dashboard.

"Group" is used to restrict access to the plugin (e. g. Group: admin;group1;group2;). "Default" indicates if the plugin is enabled by default or if the user needs to enable it manually.

Framework

Frontend::Agent::Dashboard

$Self->{'DashboardBackend'}->{'0210-MOTD'} = {

'Block' => 'ContentLarge',

'Default' => '1',

'Group' => '',

'Module' => 'Kernel::Output::HTML::DashboardMOTD',

'Title' => 'Message of the Day'

};

2.39.8. DashboardBackend###0300-IFrame

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the parameters for the dashboard backend. "Group" is used to restrict access to the plugin (e. g. Group: admin;group1;group2;). "Default" indicates if the plugin is enabled by default or if the user needs to enable it manually. "CacheTTL" indicates the cache expiration period in minutes for the plugin.

Framework

Frontend::Agent::Dashboard

$Self->{'DashboardBackend'}->{'0300-IFrame'} = {

'Align' => 'left',

'Block' => 'ContentLarge',

'Default' => '1',

'Description' => 'Some description!',

'Frameborder' => '1',

'Group' => '',

'Height' => '800',

'Link' => 'http://otrs.org/',

'LinkTitle' => 'OTRS.org/',

362

'Marginheight' => '5',

'Marginwidth' => '5',

'Module' => 'Kernel::Output::HTML::DashboardIFrame',

'Scrolling' => 'auto',

'Title' => 'A Website',

'URL' => 'http://www.otrs.org/',

'Width' => '1024'

};

2.39.9.

AgentCustomerInformationCenter::Backend###0050-

CIC-CustomerUserList

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Parameters for the dashboard backend of the customer user list overview of the agent interface . "Limit" is the number of entries shown by default. "Group" is used to restrict the access to the plugin (e. g. Group: admin;group1;group2;). "Default" determines if the plugin is enabled by default or if the user needs to enable it manually. "CacheTTLLocal" is the cache time in minutes for the plugin.

Framework

Frontend::Agent::Dashboard

$Self->{'AgentCustomerInformationCenter::Backend'}->{'0050-CIC-

CustomerUserList'} = {

'Attributes' => '',

'Block' => 'ContentLarge',

'CacheTTLLocal' => '0.5',

'Default' => '1',

'Description' => 'All customer users of a CustomerID',

'Group' => '',

'Limit' => '10',

'Module' => 'Kernel::Output::HTML::DashboardCustomerUserList',

'Permission' => 'ro',

'Title' => 'Customer Users'

};

2.40. Frontend::Agent::LinkObject

2.40.1. Frontend::AgentLinkObject::WildcardSearch

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Starts a wildcard search of the active object after the link object mask is started.

Framework

Frontend::Agent::LinkObject

$Self->{'Frontend::AgentLinkObject::WildcardSearch'} = '0';

2.41. Frontend::Agent::ModuleMetaHead

2.41.1. Frontend::HeaderMetaModule###100-Refresh

Description: Defines the module to generate html refresh headers of html sites.

363

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Framework

Frontend::Agent::ModuleMetaHead

$Self->{'Frontend::HeaderMetaModule'}->{'100-Refresh'} = {

'Module' => 'Kernel::Output::HTML::HeaderMetaRefresh'

};

2.42. Frontend::Agent::ModuleNotify

2.42.1. Frontend::NotifyModule###200-UID-Check

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the module to display a notification in the agent interface, if the system is used by the admin user (normally you shouldn't work as admin).

Framework

Frontend::Agent::ModuleNotify

$Self->{'Frontend::NotifyModule'}->{'200-UID-Check'} = {

'Module' => 'Kernel::Output::HTML::NotificationUIDCheck'

};

2.42.2. Frontend::NotifyModule###300-ShowAgentOnline

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the module that shows all the currently logged in agents in the agent interface.

Framework

Frontend::Agent::ModuleNotify

$Self->{'Frontend::NotifyModule'}->{'300-ShowAgentOnline'} = {

'IdleMinutes' => '60',

'Module' => 'Kernel::Output::HTML::NotificationAgentOnline',

'ShowEmail' => '1'

};

2.42.3. Frontend::NotifyModule###400-ShowCustomerOnline

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the module that shows all the currently loged in customers in the agent interface.

Framework

Frontend::Agent::ModuleNotify

$Self->{'Frontend::NotifyModule'}->{'400-ShowCustomerOnline'} = {

'IdleMinutes' => '60',

'Module' => 'Kernel::Output::HTML::NotificationCustomerOnline',

364

2.42.4. Frontend::NotifyModule###500-OutofOffice-Check

Description:

'ShowEmail' => '1'

};

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the module to display a notification in the agent interface, if the agent is logged in while having out-of-office active.

Framework

Frontend::Agent::ModuleNotify

$Self->{'Frontend::NotifyModule'}->{'500-OutofOffice-Check'} = {

'Module' => 'Kernel::Output::HTML::NotificationOutofOfficeCheck'

};

2.42.5. Frontend::NotifyModule###900-Generic

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the module that shows a generic notification in the agent interface. Either "Text" - if configured - or the contents of "File" will be displayed.

Framework

Frontend::Agent::ModuleNotify

$Self->{'Frontend::NotifyModule'}->{'900-Generic'} = {

'File' => '<OTRS_CONFIG_Home>/var/notify.txt',

'Link' => 'http://www.otrs.com',

'Module' => 'Kernel::Output::HTML::NotificationGeneric',

'Priority' => 'Warning',

'Text' => 'The OTRS Website'

};

2.43. Frontend::Agent::ModuleRegistration

2.43.1. Frontend::Module###Logout

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'Logout'} = {

'Description' => 'Logout',

'NavBarName' => '',

'Title' => ''

};

2.43.2. Frontend::Module###AgentDashboard

Description:

Group:

Frontend module registration for the agent interface.

Framework

365

SubGroup:

Valid:

Required:

Config-Setting:

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentDashboard'} = {

'Description' => 'Agent Dashboard',

'Loader' => {

'CSS' => [

'Core.Agent.Dashboard.css',

'Core.AllocationList.css',

'thirdparty/fullcalendar-1.6.1/fullcalendar.css',

'thirdparty/d3js/nv.d3.css'

'JavaScript' => [

'thirdparty/flot-0.8.1/excanvas.js',

'thirdparty/flot-0.8.1/jquery.flot.js',

'thirdparty/fullcalendar-1.6.1/fullcalendar.min.js',

'thirdparty/d3js/d3.v3.min.js',

'thirdparty/d3js/nv.d3.min.js',

'thirdparty/d3js/models/OTRSmultiBarChart.js',

'thirdparty/d3js/models/OTRSstackedAreaChart.js',

'Core.UI.Chart.js',

'Core.UI.AdvancedChart.js',

'Core.UI.DnD.js',

'Core.UI.AllocationList.js',

'Core.Agent.TableFilters.js',

'Core.Agent.Dashboard.js'

]

'NavBar' => [

{

'AccessKey' => 'd',

'Block' => 'ItemArea',

'Description' => '',

'Link' => 'Action=AgentDashboard',

'LinkOption' => '',

'Name' => 'Dashboard',

'NavBar' => 'Dashboard',

'Prio' => '50',

'Type' => 'Menu'

}

'NavBarName' => 'Dashboard',

'Title' => ''

};

2.43.3.

Frontend::Module###AgentCustomerInformationCenter

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentCustomerInformationCenter'} =

{

'Description' => 'Customer Information Center',

'Loader' => {

'CSS' => [

'Core.AllocationList.css'

'JavaScript' => [

'thirdparty/flot-0.8.1/excanvas.js',

'thirdparty/flot-0.8.1/jquery.flot.js',

'Core.UI.Chart.js',

366

'Core.UI.DnD.js',

'Core.UI.AllocationList.js',

'Core.Agent.Dashboard.js',

'Core.Agent.TableFilters.js'

]

'NavBar' => [

{

'AccessKey' => '',

'Block' => 'ItemArea',

'Description' => 'Customer Information Center.',

'Link' => 'Action=AgentCustomerInformationCenter',

'LinkOption' => 'onclick="window.setTimeout(function()

{Core.Agent.CustomerInformationCenterSearch.OpenSearchDialog();},

0); return false;"',

'Name' => 'Customer Information Center',

'NavBar' => 'Customers',

'Prio' => '50',

'Type' => ''

{

'AccessKey' => 'c',

'Block' => 'ItemArea',

'Description' => 'Customer Information Center.',

'Link' => 'Action=AgentCustomerInformationCenter',

'LinkOption' => '',

'Name' => 'Customers',

'NavBar' => 'Customers',

'Prio' => '60',

'Type' => 'Menu'

}

'NavBarName' => 'Customer Information Center',

'Title' => ''

};

2.43.4.

Frontend::Module###AgentCustomerInformationCenterSearch

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}-

>{'AgentCustomerInformationCenterSearch'} = {

'Description' => 'Customer Information Center Search',

'Title' => ''

};

2.43.5. Frontend::Module###AgentPreferences

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentPreferences'} = {

'Description' => 'Agent Preferences',

'NavBarName' => 'Preferences',

'Title' => ''

367

};

2.43.6. Frontend::Module###PictureUpload

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'PictureUpload'} = {

'Description' => 'Picture upload module',

'NavBarName' => 'Ticket',

'Title' => 'Picture-Upload'

};

2.43.7. Frontend::Module###AgentSpelling

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentSpelling'} = {

'Description' => 'Spell checker',

'Loader' => {

'JavaScript' => [

'Core.Agent.TicketAction.js'

]

'NavBarName' => '',

'Title' => 'Spell Checker'

};

2.43.8. Frontend::Module###SpellingInline

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'SpellingInline'} = {

'Description' => 'Spell checker',

'NavBarName' => '',

'Title' => 'Spell Checker'

};

2.43.9. Frontend::Module###AgentBook

Description:

Group:

SubGroup:

Valid:

Required:

Frontend module registration for the agent interface.

Framework

Frontend::Agent::ModuleRegistration

368

Config-Setting:

$Self->{'Frontend::Module'}->{'AgentBook'} = {

'Description' => 'Address book of CustomerUser sources',

'Loader' => {

'JavaScript' => [

'Core.Agent.CustomerSearch.js',

'Core.Agent.TicketAction.js'

]

'NavBarName' => '',

'Title' => 'Address Book'

};

2.43.10. Frontend::Module###AgentLinkObject

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentLinkObject'} = {

'Description' => 'Link Object',

'NavBarName' => '',

'Title' => 'Link Object'

};

2.43.11. Frontend::Module###AgentInfo

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentInfo'} = {

'Description' => 'Generic Info module',

'NavBarName' => '',

'Title' => 'Info'

};

2.43.12. Frontend::Module###AgentSearch

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentSearch'} = {

'Description' => 'Global Search Module',

'NavBarName' => '',

'Title' => 'Search'

};

2.43.13. CustomerFrontend::Module###SpellingInline

Description:

Group:

Frontend module registration for the customer interface.

Framework

369

SubGroup:

Valid:

Required:

Config-Setting:

Frontend::Agent::ModuleRegistration

$Self->{'CustomerFrontend::Module'}->{'SpellingInline'} = {

'Description' => 'Spell checker',

'NavBarName' => '',

'Title' => 'Spell Checker'

};

2.43.14. Frontend::Module###AgentHTMLReference

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentHTMLReference'} = {

'Description' => 'HTML Reference',

'Group' => [

'users'

'GroupRo' => [

'users'

'Loader' => {

'CSS' => [

'Core.Agent.HTMLReference.css'

]

'NavBarName' => '',

'Title' => 'HTML Reference'

};

2.43.15. Frontend::Module###AgentStats

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentStats'} = {

'Description' => 'Stats',

'Group' => [

'stats'

'GroupRo' => [

'stats'

'Loader' => {

'JavaScript' => [

'Core.Agent.Stats.js'

]

'NavBar' => [

{

'AccessKey' => '',

'Block' => 'ItemArea',

'Description' => '',

'Link' => 'Action=AgentStats;Subaction=Overview',

'LinkOption' => '',

370

'Name' => 'Statistics',

'NavBar' => 'Stats',

'Prio' => '8500',

'Type' => 'Menu'

{

'AccessKey' => '',

'Block' => '',

'Description' => 'Overview',

'GroupRo' => [

'stats'

'Link' => 'Action=AgentStats;Subaction=Overview',

'LinkOption' => '',

'Name' => 'Overview',

'NavBar' => 'Stats',

'Prio' => '100',

'Type' => ''

{

'AccessKey' => '',

'Block' => '',

'Description' => 'New',

'Group' => [

'stats'

'Link' => 'Action=AgentStats;Subaction=Add',

'LinkOption' => '',

'Name' => 'New',

'NavBar' => 'Stats',

'Prio' => '200',

'Type' => ''

{

'AccessKey' => '',

'Block' => '',

'Description' => 'Import',

'Group' => [

'stats'

'Link' => 'Action=AgentStats;Subaction=Import',

'LinkOption' => '',

'Name' => 'Import',

'NavBar' => 'Stats',

'Prio' => '300',

'Type' => ''

}

'NavBarName' => 'Stats',

'Title' => 'Stats'

};

2.44. Frontend::Agent::NavBarModule

2.44.1. Frontend::NavBarModule###6-CustomerCompany

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration (disable company link if no company feature is used).

Framework

Frontend::Agent::NavBarModule

$Self->{'Frontend::NavBarModule'}->{'6-CustomerCompany'} = {

'Module' => 'Kernel::Output::HTML::NavBarCustomerCompany'

371

};

2.45. Frontend::Agent::Preferences

2.45.1. PreferencesTableValue

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the name of the column to store the data in the preferences table.

Framework

Frontend::Agent::Preferences

$Self->{'PreferencesTableValue'} = 'preferences_value';

2.45.2. PreferencesTableUserID

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the name of the column to store the user identifier in the preferences table.

Framework

Frontend::Agent::Preferences

$Self->{'PreferencesTableUserID'} = 'user_id';

2.45.3. PreferencesView

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the display order of the different items in the preferences view.

Framework

Frontend::Agent::Preferences

$Self->{'PreferencesView'} = [

'User Profile',

'Email Settings',

'Other Settings'

];

2.45.4. PreferencesGroups###Password

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the config parameters of this item, to be shown in the preferences view.

Framework

Frontend::Agent::Preferences

$Self->{'PreferencesGroups'}->{'Password'} = {

'Active' => '1',

'Area' => 'Agent',

'Column' => 'User Profile',

372

'Label' => 'Change password',

'Module' => 'Kernel::Output::HTML::PreferencesPassword',

'PasswordMaxLoginFailed' => '0',

'PasswordMin2Characters' => '0',

'PasswordMin2Lower2UpperCharacters' => '0',

'PasswordMinSize' => '0',

'PasswordNeedDigit' => '0',

'PasswordRegExp' => '',

'Prio' => '0500'

};

2.45.5. PreferencesGroups###SpellDict

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the config parameters of this item, to be shown in the preferences view. Take care to maintain the dictionaries installed in the system in the data section.

Framework

Frontend::Agent::Preferences

$Self->{'PreferencesGroups'}->{'SpellDict'} = {

'Active' => '1',

'Column' => 'User Profile',

'Data' => {

'deutsch' => 'Deutsch',

'english' => 'English'

'DataSelected' => 'english',

'Key' => 'Default spelling dictionary',

'Label' => 'Spelling Dictionary',

'Module' => 'Kernel::Output::HTML::PreferencesGeneric',

'PrefKey' => 'UserSpellDict',

'Prio' => '2000'

};

2.45.6. PreferencesGroups###Comment

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the config parameters of this item, to be shown in the preferences view.

Framework

Frontend::Agent::Preferences

$Self->{'PreferencesGroups'}->{'Comment'} = {

'Active' => '0',

'Block' => 'Input',

'Column' => 'Other Settings',

'Data' => '$Env{"UserComment"}',

'Key' => 'Comment',

'Label' => 'Comment',

'Module' => 'Kernel::Output::HTML::PreferencesGeneric',

'PrefKey' => 'UserComment',

'Prio' => '6000'

};

2.45.7. PreferencesGroups###Language

Description: Defines the config parameters of this item, to be shown in the preferences view.

373

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Framework

Frontend::Agent::Preferences

$Self->{'PreferencesGroups'}->{'Language'} = {

'Active' => '1',

'Column' => 'User Profile',

'Key' => 'Frontend language',

'Label' => 'Language',

'Module' => 'Kernel::Output::HTML::PreferencesLanguage',

'PrefKey' => 'UserLanguage',

'Prio' => '1000'

};

2.45.8. PreferencesGroups###Skin

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the config parameters of this item, to be shown in the preferences view.

Framework

Frontend::Agent::Preferences

$Self->{'PreferencesGroups'}->{'Skin'} = {

'Active' => '1',

'Column' => 'User Profile',

'Key' => 'Wear this frontend skin',

'Label' => 'Skin',

'Module' => 'Kernel::Output::HTML::PreferencesSkin',

'PrefKey' => 'UserSkin',

'Prio' => '2000'

};

2.45.9. PreferencesGroups###Theme

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the config parameters of this item, to be shown in the preferences view.

Framework

Frontend::Agent::Preferences

$Self->{'PreferencesGroups'}->{'Theme'} = {

'Active' => '1',

'Column' => 'User Profile',

'Key' => 'Frontend theme',

'Label' => 'Theme',

'Module' => 'Kernel::Output::HTML::PreferencesTheme',

'PrefKey' => 'UserTheme',

'Prio' => '3000'

};

2.45.10. PreferencesGroups###OutOfOffice

Description:

Group:

Defines the config parameters of this item, to be shown in the preferences view.

Framework

374

SubGroup:

Valid:

Required:

Config-Setting:

Frontend::Agent::Preferences

$Self->{'PreferencesGroups'}->{'OutOfOffice'} = {

'Active' => '1',

'Block' => 'OutOfOffice',

'Column' => 'User Profile',

'Key' => '',

'Label' => 'Out Of Office Time',

'Module' => 'Kernel::Output::HTML::PreferencesOutOfOffice',

'PrefKey' => 'UserOutOfOffice',

'Prio' => '4000'

};

2.45.11. PreferencesGroups###TimeZone

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the config parameters of this item, to be shown in the preferences view.

Framework

Frontend::Agent::Preferences

$Self->{'PreferencesGroups'}->{'TimeZone'} = {

'Active' => '1',

'Column' => 'User Profile',

'Key' => 'Time Zone',

'Label' => 'Time Zone',

'Module' => 'Kernel::Output::HTML::PreferencesTimeZone',

'PrefKey' => 'UserTimeZone',

'Prio' => '5000'

};

2.45.12. PreferencesGroups###CSVSeparator

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Gives end users the possibility to override the separator character for CSV files, defined in the translation files.

Framework

Frontend::Agent::Preferences

$Self->{'PreferencesGroups'}->{'CSVSeparator'} = {

'Active' => '1',

'Column' => 'Other Settings',

'Data' => {

'' => '',

',' => ',',

';' => ';',

'\\t' => 'tab',

'|' => '|'

'DataSelected' => '0',

'Desc' => 'Select the separator character used in CSV files (stats

and searches). If you don\'t select a separator here, the default

separator for your language will be used.',

'Key' => 'CSV Separator',

'Label' => 'CSV Separator',

'Module' => 'Kernel::Output::HTML::PreferencesGeneric',

'PrefKey' => 'UserCSVSeparator',

'Prio' => '4000'

375

};

2.46. Frontend::Agent::SearchRouter

2.46.1. Frontend::SearchDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Search backend default router.

Framework

Frontend::Agent::SearchRouter

$Self->{'Frontend::SearchDefault'} =

'Action=AgentTicketSearch;Subaction=AJAX';

2.47. Frontend::Agent::Stats

2.47.1. Stats::SearchPageShown

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default maximum number of search results shown on the overview page.

Framework

Frontend::Agent::Stats

$Self->{'Stats::SearchPageShown'} = '20';

2.47.2. Stats::DefaultSelectedDynamicObject

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default selection at the drop down menu for dynamic objects (Form: Common Specification).

Framework

Frontend::Agent::Stats

$Self->{'Stats::DefaultSelectedDynamicObject'} = 'Ticket';

2.47.3. Stats::DefaultSelectedPermissions

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default selection at the drop down menu for permissions (Form: Common Specification).

Framework

Frontend::Agent::Stats

$Self->{'Stats::DefaultSelectedPermissions'} = [

'stats'

];

376

2.47.4. Stats::DefaultSelectedFormat

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default selection at the drop down menu for stats format (Form: Common Specification). Please insert the format key

(see Stats::Format).

Framework

Frontend::Agent::Stats

$Self->{'Stats::DefaultSelectedFormat'} = [

'Print',

'CSV'

];

2.47.5. Stats::SearchLimit

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the search limit for the stats.

Framework

Frontend::Agent::Stats

$Self->{'Stats::SearchLimit'} = '500';

2.47.6. Stats::Format

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines all the possible stats output formats.

Framework

Frontend::Agent::Stats

$Self->{'Stats::Format'} = {

'CSV' => 'CSV',

'GD::Graph::area' => 'graph-area',

'GD::Graph::bars' => 'graph-bars',

'GD::Graph::hbars' => 'graph-hbars',

'GD::Graph::lines' => 'graph-lines',

'GD::Graph::linespoints' => 'graph-lines-points',

'GD::Graph::pie' => 'graph-pie',

'GD::Graph::points' => 'graph-points',

'Print' => 'Print'

};

2.47.7. Stats::GraphSize

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the size of the statistic graph.

Framework

Frontend::Agent::Stats

$Self->{'Stats::GraphSize'} = {

'1200x800' => '1200x800',

377

'1600x1200' => '1600x1200',

'800x600' => '800x600'

};

2.47.8. Stats::TimeType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the time type which should be shown.

Framework

Frontend::Agent::Stats

$Self->{'Stats::TimeType'} = 'Extended';

2.47.9. Stats::ExchangeAxis

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Allows agents to exchange the axis of a stat if they generate one.

Framework

Frontend::Agent::Stats

$Self->{'Stats::ExchangeAxis'} = '0';

2.47.10. Stats::UseAgentElementInStats

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Allows agents to generate individual-related stats.

Framework

Frontend::Agent::Stats

$Self->{'Stats::UseAgentElementInStats'} = '0';

2.47.11. Stats::UseInvalidAgentInStats

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Allows invalid agents to generate individual-related stats.

Framework

Frontend::Agent::Stats

$Self->{'Stats::UseInvalidAgentInStats'} = '1';

2.47.12. Stats::CustomerIDAsMultiSelect

Description:

Group:

SubGroup:

Shows all the customer identifiers in a multi-select field (not useful if you have a lot of customer identifiers).

Framework

Frontend::Agent::Stats

378

Valid:

Required:

Config-Setting:

$Self->{'Stats::CustomerIDAsMultiSelect'} = '1';

2.48. Frontend::Customer

2.48.1. CustomerHeadline

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

The headline shown in the customer interface.

Framework

Frontend::Customer

$Self->{'CustomerHeadline'} = 'Example Company Support';

2.48.2. CustomerLogo

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

The logo shown in the header of the customer interface. The URL to the image can be a relative URL to the skin image directory, or a full URL to a remote web server.

Framework

Frontend::Customer

$Self->{'CustomerLogo'} = {

'StyleHeight' => '50px',

'StyleRight' => '25px',

'StyleTop' => '2px',

'StyleWidth' => '135px',

'URL' => 'skins/Customer/default/img/logo.png'

};

2.48.3. CustomerPanelUserID

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the user identifier for the customer panel.

Framework

Frontend::Customer

$Self->{'CustomerPanelUserID'} = '1';

2.48.4. CustomerGroupSupport

Description:

Group:

SubGroup:

Valid:

Required:

Activates support for customer groups.

Framework

Frontend::Customer

379

Config-Setting:

$Self->{'CustomerGroupSupport'} = '0';

2.48.5. CustomerGroupAlwaysGroups

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the groups every customer user will be in (if Customer-

GroupSupport is enabled and you don't want to manage every user for these groups).

Framework

Frontend::Customer

$Self->{'CustomerGroupAlwaysGroups'} = [

'users'

];

2.48.6. CustomerPanelLoginURL

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines an alternate login URL for the customer panel..

Framework

Frontend::Customer

$Self->{'CustomerPanelLoginURL'} = 'http://host.example.com/cgibin/login.pl';

2.48.7. CustomerPanelLogoutURL

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines an alternate logout URL for the customer panel.

Framework

Frontend::Customer

$Self->{'CustomerPanelLogoutURL'} = 'http://host.example.com/cgibin/login.pl';

2.48.8. Frontend::CustomerUser::Item###1-Google-

Maps

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines a customer item, which generates a google maps icon at the end of a customer info block.

Framework

Frontend::Customer

$Self->{'Frontend::CustomerUser::Item'}->{'1-GoogleMaps'} = {

'Attributes' => 'UserStreet;UserCity;UserCountry;',

'CSS' => 'Core.Agent.CustomerUser.GoogleMaps.css',

'CSSClass' => 'GoogleMaps',

'Module' => 'Kernel::Output::HTML::CustomerUserGeneric',

380

'Required' => 'UserStreet;UserCity;',

'Target' => '_blank',

'Text' => 'Location',

'URL' => 'http://maps.google.com/maps?z=7&q='

};

2.48.9. Frontend::CustomerUser::Item###2-Google

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines a customer item, which generates a google icon at the end of a customer info block.

Framework

Frontend::Customer

$Self->{'Frontend::CustomerUser::Item'}->{'2-Google'} = {

'Attributes' => 'UserFirstname;UserLastname;',

'CSS' => 'Core.Agent.CustomerUser.Google.css',

'CSSClass' => 'Google',

'Module' => 'Kernel::Output::HTML::CustomerUserGeneric',

'Required' => 'UserFirstname;UserLastname;',

'Target' => '_blank',

'Text' => 'Google',

'URL' => 'http://google.com/search?q='

};

2.48.10. Frontend::CustomerUser::Item###2-LinkedIn

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines a customer item, which generates a LinkedIn icon at the end of a customer info block.

Framework

Frontend::Customer

$Self->{'Frontend::CustomerUser::Item'}->{'2-LinkedIn'} = {

'Attributes' => 'UserFirstname;UserLastname;',

'CSS' => 'Core.Agent.CustomerUser.LinkedIn.css',

'CSSClass' => 'LinkedIn',

'Module' => 'Kernel::Output::HTML::CustomerUserGeneric',

'Required' => 'UserFirstname;UserLastname;',

'Target' => '_blank',

'Text' => 'LinkedIn',

'URL' => 'http://www.linkedin.com/commonSearch?

type=people&keywords='

};

2.48.11. Frontend::CustomerUser::Item###3-XING

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines a customer item, which generates a XING icon at the end of a customer info block.

Framework

Frontend::Customer

$Self->{'Frontend::CustomerUser::Item'}->{'3-XING'} = {

'Attributes' => 'UserFirstname;UserLastname;',

381

'CSS' => 'Core.Agent.CustomerUser.Xing.css',

'CSSClass' => 'Xing',

'Module' => 'Kernel::Output::HTML::CustomerUserGeneric',

'Required' => 'UserFirstname;UserLastname;',

'Target' => '_blank',

'Text' => 'XING',

'URL' => 'https://www.xing.com/app/search?op=search;keywords='

};

2.48.12.

CustomerPanelPreApplicationModule###CustomerAccept

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

This module and its PreRun() function will be executed, if defined, for every request. This module is useful to check some user options or to display news about new applications.

Framework

Frontend::Customer

$Self->{'CustomerPanelPreApplicationModule'}->{'CustomerAccept'} =

'Kernel::Modules::CustomerAccept';

2.48.13. CustomerPanel::InfoKey

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the key to check with CustomerAccept. If this user preferences key is true, then the message is accepted by the system.

Framework

Frontend::Customer

$Self->{'CustomerPanel::InfoKey'} = 'CustomerAccept1';

2.48.14. CustomerPanel::InfoFile

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the path of the shown info file, that is located under Kernel/Output/HTML/Standard/CustomerAccept.dtl.

Framework

Frontend::Customer

$Self->{'CustomerPanel::InfoFile'} = 'CustomerAccept';

2.48.15. CustomerPanelLostPassword

Description:

Group:

SubGroup:

Valid:

Required:

Activates lost password feature for customers.

Framework

Frontend::Customer

382

Config-Setting:

$Self->{'CustomerPanelLostPassword'} = '1';

2.48.16. CustomerPanelCreateAccount

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Enables customers to create their own accounts.

Framework

Frontend::Customer

$Self->{'CustomerPanelCreateAccount'} = '1';

2.48.17. CustomerPanelSubjectLostPasswordToken

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the subject for notification mails sent to customers, with token about new requested password.

Framework

Frontend::Customer

$Self->{'CustomerPanelSubjectLostPasswordToken'} = 'New OTRS

password request';

2.48.18. CustomerPanelBodyLostPasswordToken

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the body text for notification mails sent to customers, with token about new requested password (after using this link the new password will be sent).

Framework

Frontend::Customer

$Self->{'CustomerPanelBodyLostPasswordToken'} = 'Hi

<OTRS_USERFIRSTNAME>,

You or someone impersonating you has requested to change your OTRS password.

If you want to do this, click on this link. You will receive another

email containing the password.

<OTRS_CONFIG_HttpType>://<OTRS_CONFIG_FQDN>/

<OTRS_CONFIG_ScriptAlias>customer.pl?

Action=CustomerLostPassword;Token=<OTRS_TOKEN>

If you did not request a new password, please ignore this email.

2.48.19. CustomerPanelSubjectLostPassword

Description:

Group:

Defines the subject for notification mails sent to customers, about new password.

Framework

383

SubGroup:

Valid:

Required:

Config-Setting:

Frontend::Customer

$Self->{'CustomerPanelSubjectLostPassword'} = 'New OTRS password';

2.48.20. CustomerPanelBodyLostPassword

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the body text for notification mails sent to customers, about new password (after using this link the new password will be sent).

Framework

Frontend::Customer

$Self->{'CustomerPanelBodyLostPassword'} = 'Hi

<OTRS_USERFIRSTNAME>,

New password: <OTRS_NEWPW>

<OTRS_CONFIG_HttpType>://<OTRS_CONFIG_FQDN>/

<OTRS_CONFIG_ScriptAlias>customer.pl

2.48.21. CustomerPanelSubjectNewAccount

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the subject for notification mails sent to customers, about new account.

Framework

Frontend::Customer

$Self->{'CustomerPanelSubjectNewAccount'} = 'New OTRS Account!';

2.48.22. CustomerPanelBodyNewAccount

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the body text for notification mails sent to customers, about new account.

Framework

Frontend::Customer

$Self->{'CustomerPanelBodyNewAccount'} = 'Hi <OTRS_USERFIRSTNAME>,

You or someone impersonating you has created a new OTRS account for you.

Full name: <OTRS_USERFIRSTNAME> <OTRS_USERLASTNAME>

User name: <OTRS_USERLOGIN>

Password : <OTRS_USERPASSWORD>

You can log in via the following URL. We encourage you to change

your password via the Preferences button after logging in.

384

<OTRS_CONFIG_HttpType>://<OTRS_CONFIG_FQDN>/

<OTRS_CONFIG_ScriptAlias>customer.pl

2.48.23. Loader::Customer::Skin###000-default

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Default skin for OTRS 3.0 interface.

Framework

Frontend::Customer

$Self->{'Loader::Customer::Skin'}->{'000-default'} = {

'Description' => 'This is the default orange - black skin for OTRS

3.0.',

'HomePage' => 'www.otrs.org',

'InternalName' => 'default',

'VisibleName' => 'Default'

};

2.48.24. Loader::Customer::SelectedSkin

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

The customer skin's InternalName which should be used in the customer interface. Please check the available skins in

Frontend::Customer::Skins.

Framework

Frontend::Customer

$Self->{'Loader::Customer::SelectedSkin'} = 'default';

2.48.25. AutoComplete::Customer###Default

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the config options for the autocompletion feature.

Framework

Frontend::Customer

$Self->{'AutoComplete::Customer'}->{'Default'} = {

'AutoCompleteActive' => '1',

'ButtonText' => 'Search',

'MaxResultsDisplayed' => '20',

'MinQueryLength' => '2',

'QueryDelay' => '100'

};

2.49. Frontend::Customer::Auth

2.49.1. Customer::AuthModule

Description:

Group:

Defines the module to authenticate customers.

Framework

385

SubGroup:

Valid:

Required:

Config-Setting:

Frontend::Customer::Auth

$Self->{'Customer::AuthModule'} =

'Kernel::System::CustomerAuth::DB';

2.49.2. Customer::AuthModule::DB::CryptType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If "DB" was selected for Customer::AuthModule, the crypt type of passwords must be specified.

Framework

Frontend::Customer::Auth

$Self->{'Customer::AuthModule::DB::CryptType'} = 'sha2';

2.49.3. Customer::AuthModule::DB::Table

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If "DB" was selected for Customer::AuthModule, the name of the table where your customer data should be stored must be specified.

Framework

Frontend::Customer::Auth

$Self->{'Customer::AuthModule::DB::Table'} = 'customer_user';

2.49.4. Customer::AuthModule::DB::CustomerKey

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If "DB" was selected for Customer::AuthModule, the name of the column for the CustomerKey in the customer table must be specified.

Framework

Frontend::Customer::Auth

$Self->{'Customer::AuthModule::DB::CustomerKey'} = 'login';

2.49.5. Customer::AuthModule::DB::CustomerPassword

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If "DB" was selected for Customer::AuthModule, the column name for the CustomerPassword in the customer table must be specified.

Framework

Frontend::Customer::Auth

$Self->{'Customer::AuthModule::DB::CustomerPassword'} = 'pw';

386

2.49.6. Customer::AuthModule::DB::DSN

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If "DB" was selected for Customer::AuthModule, the DSN for the connection to the customer table must be specified.

Framework

Frontend::Customer::Auth

$Self->{'Customer::AuthModule::DB::DSN'} =

'DBI:mysql:database=customerdb;host=customerdbhost';

2.49.7. Customer::AuthModule::DB::User

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If "DB" was selected for Customer::AuthModule, a username to connect to the customer table can be specified.

Framework

Frontend::Customer::Auth

$Self->{'Customer::AuthModule::DB::User'} = 'some_user';

2.49.8. Customer::AuthModule::DB::Password

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If "DB" was selected for Customer::AuthModule, a password to connect to the customer table can be specified.

Framework

Frontend::Customer::Auth

$Self->{'Customer::AuthModule::DB::Password'} = 'some_password';

2.49.9. Customer::AuthModule::DB::Type

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If "DB" was selected for Customer::AuthModule, a database driver

(normally autodetection is used) can be specified.

Framework

Frontend::Customer::Auth

$Self->{'Customer::AuthModule::DB::Type'} = 'mysql';

2.49.10.

Customer::AuthModule::HTTPBasicAuth::Replace

Description: If "HTTPBasicAuth" was selected for Customer::AuthModule, you can specify to strip leading parts of user names (e. g. for domains like example_domain\user to user).

387

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Framework

Frontend::Customer::Auth

$Self->{'Customer::AuthModule::HTTPBasicAuth::Replace'} =

'example_domain\\\\';

2.49.11.

Customer::AuthModule::HTTPBasicAuth::ReplaceRegExp

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If "HTTPBasicAuth" was selected for Customer::AuthModule, you can specify (by using a RegExp) to strip parts of REMOTE_USER

(e. g. for to remove trailing domains). RegExp-Note, $1 will be the new Login.

Framework

Frontend::Customer::Auth

$Self->{'Customer::AuthModule::HTTPBasicAuth::ReplaceRegExp'} =

'^(.+?)@.+?$';

2.49.12. Customer::AuthModule::LDAP::Host

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If "LDAP" was selected for Customer::AuthModule, the LDAP host can be specified.

Framework

Frontend::Customer::Auth

$Self->{'Customer::AuthModule::LDAP::Host'} = 'ldap.example.com';

2.49.13. Customer::AuthModule::LDAP::BaseDN

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If "LDAP" was selected for Customer::AuthModule, the BaseDN must be specified.

Framework

Frontend::Customer::Auth

$Self->{'Customer::AuthModule::LDAP::BaseDN'} =

'dc=example,dc=com';

2.49.14. Customer::AuthModule::LDAP::UID

Description:

Group:

SubGroup:

If "LDAP" was selected for Customer::AuthModule, the user identifier must be specified.

Framework

Frontend::Customer::Auth

388

Valid:

Required:

Config-Setting:

$Self->{'Customer::AuthModule::LDAP::UID'} = 'uid';

2.49.15. Customer::AuthModule::LDAP::GroupDN

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If "LDAP" was selected for Customer::Authmodule, you can check if the user is allowed to authenticate because he is in a posixGroup, e.g. user needs to be in a group xyz to use OTRS. Specify the group, who may access the system.

Framework

Frontend::Customer::Auth

$Self->{'Customer::AuthModule::LDAP::GroupDN'} =

'cn=otrsallow,ou=posixGroups,dc=example,dc=com';

2.49.16. Customer::AuthModule::LDAP::AccessAttr

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If "LDAP" was selected for Customer::AuthModule, you can specify access attributes here.

Framework

Frontend::Customer::Auth

$Self->{'Customer::AuthModule::LDAP::AccessAttr'} = 'memberUid';

2.49.17. Customer::AuthModule::LDAP::UserAttr

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If "LDAP" was selected for Customer::AuthModule, user attributes can be specified. For LDAP posixGroups use UID, for non LDAP posixGroups use full user DN.

Framework

Frontend::Customer::Auth

$Self->{'Customer::AuthModule::LDAP::UserAttr'} = 'UID';

2.49.18. Customer::AuthModule::LDAP::SearchUserDN

Description:

Group:

SubGroup:

Valid:

If "LDAP" was selected for Customer::AuthModule and your users have only anonymous access to the LDAP tree, but you want to search through the data, you can do this with a user who has access to the LDAP directory. Specify the username for this special user here.

Framework

Frontend::Customer::Auth

389

Required:

Config-Setting:

$Self->{'Customer::AuthModule::LDAP::SearchUserDN'} =

'cn=binduser,ou=users,dc=example,dc=com';

2.49.19. Customer::AuthModule::LDAP::SearchUserPw

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Framework

Frontend::Customer::Auth

$Self->{'Customer::AuthModule::LDAP::SearchUserPw'} =

'some_password';

2.49.20. Customer::AuthModule::LDAP::AlwaysFilter

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If "LDAP" was selected, you can add a filter to each LDAP query, e.g. (mail=*), (objectclass=user) or (!objectclass=computer).

Framework

Frontend::Customer::Auth

$Self->{'Customer::AuthModule::LDAP::AlwaysFilter'} = '(!

objectclass=computer)';

2.49.21. Customer::AuthModule::LDAP::UserSuffix

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If "LDAP" was selected for Customer::AuthModule and if you want to add a suffix to every customer login name, specifiy it here, e. g.

you just want to write the username user but in your LDAP directory exists user@domain.

Framework

Frontend::Customer::Auth

$Self->{'Customer::AuthModule::LDAP::UserSuffix'} = '@domain.com';

2.49.22. Customer::AuthModule::LDAP::Params

Description:

Group:

SubGroup:

If "LDAP" was selected for Customer::AuthModule and special paramaters are needed for the Net::LDAP perl module, you can specify them here. See "perldoc Net::LDAP" for more information about the parameters.

Framework

Frontend::Customer::Auth

390

Valid:

Required:

Config-Setting:

$Self->{'Customer::AuthModule::LDAP::Params'} = {

'async' => '0',

'port' => '389',

'timeout' => '120',

'version' => '3'

};

2.49.23. Customer::AuthModule::LDAP::Die

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If "LDAP" was selected for Customer::AuthModule, you can specify if the applications will stop if e. g. a connection to a server can't be established due to network problems.

Framework

Frontend::Customer::Auth

$Self->{'Customer::AuthModule::LDAP::Die'} = '1';

2.49.24. Customer::AuthModule::Radius::Host

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If "Radius" was selected for Customer::AuthModule, the radius host must be specified.

Framework

Frontend::Customer::Auth

$Self->{'Customer::AuthModule::Radius::Host'} = 'radiushost';

2.49.25. Customer::AuthModule::Radius::Password

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If "Radius" was selected for Customer::AuthModule, the password to authenticate to the radius host must be specified.

Framework

Frontend::Customer::Auth

$Self->{'Customer::AuthModule::Radius::Password'} =

'radiussecret';

2.49.26. Customer::AuthModule::Radius::Die

Description:

Group:

SubGroup:

Valid:

If "Radius" was selected for Customer::AuthModule, you can specify if the applications will stop if e. g. a connection to a server can't be established due to network problems.

Framework

Frontend::Customer::Auth

391

Required:

Config-Setting:

$Self->{'Customer::AuthModule::Radius::Die'} = '1';

2.50. Frontend::Customer::ModuleMetaHead

2.50.1. CustomerFrontend::HeaderMetaModule###1-

Refresh

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the module to generate html refresh headers of html sites, in the customer interface.

Framework

Frontend::Customer::ModuleMetaHead

$Self->{'CustomerFrontend::HeaderMetaModule'}->{'1-Refresh'} = {

'Module' => 'Kernel::Output::HTML::HeaderMetaRefresh'

};

2.51. Frontend::Customer::ModuleNotify

2.51.1. CustomerFrontend::NotifyModule###1-ShowAgentOnline

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the module that shows the currently loged in agents in the customer interface.

Framework

Frontend::Customer::ModuleNotify

$Self->{'CustomerFrontend::NotifyModule'}->{'1-ShowAgentOnline'} =

{

'IdleMinutes' => '60',

'Module' => 'Kernel::Output::HTML::NotificationAgentOnline',

'ShowEmail' => '1'

};

2.51.2. CustomerFrontend::NotifyModule###1-Show-

CustomerOnline

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the module that shows the currently loged in customers in the customer interface.

Framework

Frontend::Customer::ModuleNotify

$Self->{'CustomerFrontend::NotifyModule'}->{'1-ShowCustomerOnline'}

= {

'Module' => 'Kernel::Output::HTML::NotificationCustomerOnline',

'ShowEmail' => '1'

};

392

2.52.

Frontend::Customer::ModuleRegistration

2.52.1. CustomerFrontend::Module###Logout

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the customer interface.

Framework

Frontend::Customer::ModuleRegistration

$Self->{'CustomerFrontend::Module'}->{'Logout'} = {

'Description' => 'Logout of customer panel',

'NavBarName' => '',

'Title' => ''

};

2.52.2.

CustomerFrontend::Module###CustomerPreferences

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the customer interface.

Framework

Frontend::Customer::ModuleRegistration

$Self->{'CustomerFrontend::Module'}->{'CustomerPreferences'} = {

'Description' => 'Customer preferences',

'NavBarName' => '',

'Title' => 'Preferences'

};

2.52.3.

CustomerFrontend::Module###CustomerAccept

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the customer interface.

Framework

Frontend::Customer::ModuleRegistration

$Self->{'CustomerFrontend::Module'}->{'CustomerAccept'} = {

'Description' => 'To accept login information, such as an EULA or

license.',

'NavBarName' => '',

'Title' => 'Info'

};

2.52.4. CustomerFrontend::Module###PictureUpload

Description:

Group:

SubGroup:

Frontend module registration for the customer interface.

Framework

Frontend::Customer::ModuleRegistration

393

Valid:

Required:

Config-Setting:

$Self->{'CustomerFrontend::Module'}->{'PictureUpload'} = {

'Description' => 'Picture upload module',

'NavBarName' => 'Ticket',

'Title' => 'Picture-Upload'

};

2.53. Frontend::Customer::Preferences

2.53.1. PreferencesTable

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the name of the table, where the customer preferences are stored.

Framework

Frontend::Customer::Preferences

$Self->{'PreferencesTable'} = 'user_preferences';

2.53.2. PreferencesTableKey

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the column to store the keys for the preferences table.

Framework

Frontend::Customer::Preferences

$Self->{'PreferencesTableKey'} = 'preferences_key';

2.53.3. CustomerPreferences

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the parameters for the customer preferences table.

Framework

Frontend::Customer::Preferences

$Self->{'CustomerPreferences'} = {

'Module' => 'Kernel::System::CustomerUser::Preferences::DB',

'Params' => {

'Table' => 'customer_preferences',

'TableKey' => 'preferences_key',

'TableUserID' => 'user_id',

'TableValue' => 'preferences_value'

}

};

2.53.4. CustomerPreferencesView

Description: Sets the order of the different items in the customer preferences view.

394

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Framework

Frontend::Customer::Preferences

$Self->{'CustomerPreferencesView'} = [

'User Profile',

'Other Settings'

];

2.53.5. CustomerPreferencesGroups###Password

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines all the parameters for this item in the customer preferences.

Framework

Frontend::Customer::Preferences

$Self->{'CustomerPreferencesGroups'}->{'Password'} = {

'Active' => '1',

'Area' => 'Customer',

'Column' => 'Other Settings',

'Label' => 'Change password',

'Module' => 'Kernel::Output::HTML::PreferencesPassword',

'PasswordMin2Characters' => '0',

'PasswordMin2Lower2UpperCharacters' => '0',

'PasswordMinSize' => '0',

'PasswordNeedDigit' => '0',

'PasswordRegExp' => '',

'Prio' => '1000'

};

2.53.6. CustomerPreferencesGroups###Language

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines all the parameters for this item in the customer preferences.

Framework

Frontend::Customer::Preferences

$Self->{'CustomerPreferencesGroups'}->{'Language'} = {

'Active' => '1',

'Column' => 'User Profile',

'Key' => 'Language',

'Label' => 'Interface language',

'Module' => 'Kernel::Output::HTML::PreferencesLanguage',

'PrefKey' => 'UserLanguage',

'Prio' => '2000'

};

2.53.7. CustomerPreferencesGroups###Theme

Description:

Group:

Defines all the parameters for this item in the customer preferences.

Framework

395

SubGroup:

Valid:

Required:

Config-Setting:

Frontend::Customer::Preferences

$Self->{'CustomerPreferencesGroups'}->{'Theme'} = {

'Active' => '0',

'Column' => 'User Profile',

'Key' => 'Select your frontend Theme.',

'Label' => 'Theme',

'Module' => 'Kernel::Output::HTML::PreferencesTheme',

'PrefKey' => 'UserTheme',

'Prio' => '1000'

};

2.53.8. CustomerPreferencesGroups###TimeZone

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines all the parameters for this item in the customer preferences.

Framework

Frontend::Customer::Preferences

$Self->{'CustomerPreferencesGroups'}->{'TimeZone'} = {

'Active' => '1',

'Column' => 'User Profile',

'Key' => 'Time Zone',

'Label' => 'Time Zone',

'Module' => 'Kernel::Output::HTML::PreferencesTimeZone',

'PrefKey' => 'UserTimeZone',

'Prio' => '5000'

};

2.53.9. CustomerPreferencesGroups###PGP

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines all the parameters for this item in the customer preferences.

Framework

Frontend::Customer::Preferences

$Self->{'CustomerPreferencesGroups'}->{'PGP'} = {

'Active' => '1',

'Column' => 'Other Settings',

'Key' => 'PGP Key Upload',

'Label' => 'PGP Key',

'Module' => 'Kernel::Output::HTML::PreferencesPGP',

'PrefKey' => 'UserPGPKey',

'Prio' => '10000'

};

2.53.10. CustomerPreferencesGroups###SMIME

Description:

Group:

SubGroup:

Defines all the parameters for this item in the customer preferences.

Framework

Frontend::Customer::Preferences

396

Valid:

Required:

Config-Setting:

$Self->{'CustomerPreferencesGroups'}->{'SMIME'} = {

'Active' => '1',

'Column' => 'Other Settings',

'Key' => 'S/MIME Certificate Upload',

'Label' => 'S/MIME Certificate',

'Module' => 'Kernel::Output::HTML::PreferencesSMIME',

'PrefKey' => 'UserSMIMEKey',

'Prio' => '11000'

};

2.54. Frontend::Public

2.54.1. PublicFrontend::CommonParam###Action

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default value for the action parameter for the public frontend. The action parameter is used in the scripts of the system.

Framework

Frontend::Public

$Self->{'PublicFrontend::CommonParam'}->{'Action'} =

'PublicDefault';

2.55. Frontend::Public::ModuleRegistration

2.55.1. PublicFrontend::Module###PublicDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Public::ModuleRegistration

$Self->{'PublicFrontend::Module'}->{'PublicDefault'} = {

'Description' => 'PublicDefault',

'NavBarName' => '',

'Title' => 'PublicDefault'

};

2.55.2. PublicFrontend::Module###PublicRepository

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Public::ModuleRegistration

$Self->{'PublicFrontend::Module'}->{'PublicRepository'} = {

'Description' => 'PublicRepository',

'NavBarName' => '',

'Title' => 'PublicRepository'

};

397

2.55.3.

PublicFrontend::Module###PublicSupportDataCollector

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Framework

Frontend::Public::ModuleRegistration

$Self->{'PublicFrontend::Module'}->{'PublicSupportDataCollector'} =

{

'Description' => 'PublicSupportDataCollector',

'NavBarName' => '',

'Title' => 'PublicSupportDataCollector'

};

3. GenericInterface

3.1. Core::CustomerCompany

3.1.1. CustomerCompany::EventModulePost###1000-

GenericInterface

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Performs the configured action for each event (as an Invoker) for each configured Webservice.

GenericInterface

Core::CustomerCompany

$Self->{'CustomerCompany::EventModulePost'}->{'1000-

GenericInterface'} = {

'Event' => '',

'Module' => 'Kernel::GenericInterface::Event::Handler',

'Transaction' => '1'

};

3.2. Core::CustomerUser

3.2.1. CustomerUser::EventModulePost###1000-GenericInterface

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Performs the configured action for each event (as an Invoker) for each configured Webservice.

GenericInterface

Core::CustomerUser

$Self->{'CustomerUser::EventModulePost'}->{'1000-GenericInterface'}

= {

'Event' => '',

398

'Module' => 'Kernel::GenericInterface::Event::Handler',

'Transaction' => '1'

};

3.3. Core::Package

3.3.1. Package::EventModulePost###1000-GenericInterface

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Performs the configured action for each event (as an Invoker) for each configured Webservice.

GenericInterface

Core::Package

$Self->{'Package::EventModulePost'}->{'1000-GenericInterface'} = {

'Event' => '',

'Module' => 'Kernel::GenericInterface::Event::Handler',

'Transaction' => '1'

};

3.4. Core::Ticket

3.4.1. Ticket::EventModulePost###1000-GenericInterface

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Performs the configured action for each event (as an Invoker) for each configured Webservice.

GenericInterface

Core::Ticket

$Self->{'Ticket::EventModulePost'}->{'1000-GenericInterface'} = {

'Event' => '',

'Module' => 'Kernel::GenericInterface::Event::Handler',

'Transaction' => '1'

};

3.5. Frontend::Admin::ModuleRegistration

3.5.1.

Frontend::Module###AdminGenericInterfaceDebugger

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

GenericInterface

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminGenericInterfaceDebugger'} = {

399

'Description' => 'Admin',

'Group' => [

'admin'

'Loader' => {

'CSS' => [

'Core.Agent.Admin.GenericInterface.css'

'CSS_IE7' => 'Core.Agent.Admin.GenericInterface.IE7.css',

'JavaScript' => [

'Core.Agent.Admin.GenericInterfaceDebugger.js'

]

'Title' => 'GenericInterface Debugger GUI'

};

3.5.2.

Frontend::Module###AdminGenericInterfaceWebservice

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

GenericInterface

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminGenericInterfaceWebservice'} =

{

'Description' => 'Admin',

'Group' => [

'admin'

'Loader' => {

'CSS' => [

'Core.Agent.Admin.GenericInterface.css'

'JavaScript' => [

'Core.Agent.Admin.GenericInterfaceWebservice.js'

]

'NavBarModule' => {

'Block' => 'System',

'Description' => 'Create and manage web services.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Web Services',

'Prio' => '1000'

'NavBarName' => 'Admin',

'Title' => 'GenericInterface Web Service GUI'

};

3.5.3.

Frontend::Module###AdminGenericInterfaceTransportHTTPSOAP

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

GenericInterface

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}-

>{'AdminGenericInterfaceTransportHTTPSOAP'} = {

'Description' => 'Admin',

400

'Group' => [

'admin'

'Loader' => {

'CSS' => [

'Core.Agent.Admin.GenericInterface.css'

]

'Title' => 'GenericInterface TransportHTTPSOAP GUI'

};

3.5.4.

Frontend::Module###AdminGenericInterfaceWebserviceHistory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

GenericInterface

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}-

>{'AdminGenericInterfaceWebserviceHistory'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'Loader' => {

'CSS' => [

'Core.Agent.Admin.GenericInterface.css'

'JavaScript' => [

'Core.Agent.Admin.GenericInterfaceWebserviceHistory.js'

]

'Title' => 'GenericInterface Webservice History GUI'

};

3.5.5.

Frontend::Module###AdminGenericInterfaceOperationDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

GenericInterface

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}-

>{'AdminGenericInterfaceOperationDefault'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'Loader' => {

'CSS' => [

'Core.Agent.Admin.GenericInterface.css'

'JavaScript' => [

'Core.Agent.Admin.GenericInterfaceOperation.js'

]

'Title' => 'GenericInterface Operation GUI'

};

401

3.5.6.

Frontend::Module###AdminGenericInterfaceInvokerDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

GenericInterface

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}-

>{'AdminGenericInterfaceInvokerDefault'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'Loader' => {

'CSS' => [

'Core.Agent.Admin.GenericInterface.css'

'JavaScript' => [

'Core.Agent.Admin.GenericInterfaceInvoker.js'

]

'Title' => 'GenericInterface Invoker GUI'

};

3.5.7.

Frontend::Module###AdminGenericInterfaceMappingSimple

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

GenericInterface

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminGenericInterfaceMappingSimple'}

= {

'Description' => 'Admin',

'Group' => [

'admin'

'Loader' => {

'CSS' => [

'Core.Agent.Admin.GenericInterface.css'

'CSS_IE7' => 'Core.Agent.Admin.GenericInterface.IE7.css',

'JavaScript' => [

'Core.Agent.Admin.GenericInterfaceMappingSimple.js'

]

'Title' => 'GenericInterface Webservice Mapping GUI'

};

3.6.

GenericInterface::Invoker::ModuleRegistration

3.6.1. GenericInterface::Invoker::Module###Test::Test

Description: GenericInterface module registration for the invoker layer.

402

Group:

SubGroup:

Valid:

Required:

Config-Setting:

GenericInterface

GenericInterface::Invoker::ModuleRegistration

$Self->{'GenericInterface::Invoker::Module'}->{'Test::Test'} = {

'ConfigDialog' => 'AdminGenericInterfaceInvokerDefault',

'Controller' => 'Test',

'Name' => 'Test'

};

3.6.2.

GenericInterface::Invoker::Module###Test::TestSimple

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

GenericInterface module registration for the invoker layer.

GenericInterface

GenericInterface::Invoker::ModuleRegistration

$Self->{'GenericInterface::Invoker::Module'}->{'Test::TestSimple'}

= {

'ConfigDialog' => 'AdminGenericInterfaceInvokerDefault',

'Controller' => 'Test',

'Name' => 'TestSimple'

};

3.7.

GenericInterface::Mapping::ModuleRegistration

3.7.1. GenericInterface::Mapping::Module###Test

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

GenericInterface module registration for the mapping layer.

GenericInterface

GenericInterface::Mapping::ModuleRegistration

$Self->{'GenericInterface::Mapping::Module'}->{'Test'} = {

'ConfigDialog' => ''

};

3.7.2. GenericInterface::Mapping::Module###Simple

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

GenericInterface module registration for the mapping layer.

GenericInterface

GenericInterface::Mapping::ModuleRegistration

$Self->{'GenericInterface::Mapping::Module'}->{'Simple'} = {

'ConfigDialog' => 'AdminGenericInterfaceMappingSimple'

};

403

3.8.

GenericInterface::Operation::ModuleRegistration

3.8.1.

GenericInterface::Operation::Module###Test::Test

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

GenericInterface module registration for the operation layer.

GenericInterface

GenericInterface::Operation::ModuleRegistration

$Self->{'GenericInterface::Operation::Module'}->{'Test::Test'} = {

'ConfigDialog' => 'AdminGenericInterfaceOperationDefault',

'Controller' => 'Test',

'Name' => 'Test'

};

3.8.2.

GenericInterface::Operation::Module###Session::SessionCreate

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

GenericInterface module registration for the operation layer.

GenericInterface

GenericInterface::Operation::ModuleRegistration

$Self->{'GenericInterface::Operation::Module'}-

>{'Session::SessionCreate'} = {

'ConfigDialog' => 'AdminGenericInterfaceOperationDefault',

'Controller' => 'Session',

'Name' => 'SessionCreate'

};

3.8.3.

GenericInterface::Operation::Module###Ticket::TicketCreate

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

GenericInterface module registration for the operation layer.

GenericInterface

GenericInterface::Operation::ModuleRegistration

$Self->{'GenericInterface::Operation::Module'}-

>{'Ticket::TicketCreate'} = {

'ConfigDialog' => 'AdminGenericInterfaceOperationDefault',

'Controller' => 'Ticket',

'Name' => 'TicketCreate'

};

3.8.4.

GenericInterface::Operation::Module###Ticket::TicketUpdate

Description: GenericInterface module registration for the operation layer.

404

Group:

SubGroup:

Valid:

Required:

Config-Setting:

GenericInterface

GenericInterface::Operation::ModuleRegistration

$Self->{'GenericInterface::Operation::Module'}-

>{'Ticket::TicketUpdate'} = {

'ConfigDialog' => 'AdminGenericInterfaceOperationDefault',

'Controller' => 'Ticket',

'Name' => 'TicketUpdate'

};

3.8.5.

GenericInterface::Operation::Module###Ticket::TicketGet

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

GenericInterface module registration for the operation layer.

GenericInterface

GenericInterface::Operation::ModuleRegistration

$Self->{'GenericInterface::Operation::Module'}-

>{'Ticket::TicketGet'} = {

'ConfigDialog' => 'AdminGenericInterfaceOperationDefault',

'Controller' => 'Ticket',

'Name' => 'TicketGet'

};

3.8.6.

GenericInterface::Operation::Module###Ticket::TicketSearch

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

GenericInterface module registration for the operation layer.

GenericInterface

GenericInterface::Operation::ModuleRegistration

$Self->{'GenericInterface::Operation::Module'}-

>{'Ticket::TicketSearch'} = {

'ConfigDialog' => 'AdminGenericInterfaceOperationDefault',

'Controller' => 'Ticket',

'Name' => 'TicketGet'

};

3.9.

GenericInterface::Operation::TicketCreate

3.9.1.

GenericInterface::Operation::TicketCreate###ArticleType

Description:

Group:

SubGroup:

Valid:

Defines the default type of the article for this operation.

GenericInterface

GenericInterface::Operation::TicketCreate

405

Required:

Config-Setting:

$Self->{'GenericInterface::Operation::TicketCreate'}-

>{'ArticleType'} = 'webrequest';

3.9.2.

GenericInterface::Operation::TicketCreate###HistoryType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the history type for this operation, which gets used for ticket history in the agent interface.

GenericInterface

GenericInterface::Operation::TicketCreate

$Self->{'GenericInterface::Operation::TicketCreate'}-

>{'HistoryType'} = 'NewTicket';

3.9.3.

GenericInterface::Operation::TicketCreate###HistoryComment

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the history comment for this operation, which gets used for ticket history in the agent interface.

GenericInterface

GenericInterface::Operation::TicketCreate

$Self->{'GenericInterface::Operation::TicketCreate'}-

>{'HistoryComment'} = '%%GenericInterface Create';

3.9.4.

GenericInterface::Operation::TicketCreate###AutoResponseType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default auto response type of the article for this operation.

GenericInterface

GenericInterface::Operation::TicketCreate

$Self->{'GenericInterface::Operation::TicketCreate'}-

>{'AutoResponseType'} = 'auto reply';

3.10.

GenericInterface::Operation::TicketSearch

3.10.1.

GenericInterface::Operation::TicketSearch###SearchLimit

Description:

Group:

Maximum number of tickets to be displayed in the result of this operation.

GenericInterface

406

SubGroup:

Valid:

Required:

Config-Setting:

GenericInterface::Operation::TicketSearch

$Self->{'GenericInterface::Operation::TicketSearch'}-

>{'SearchLimit'} = '500';

3.10.2.

GenericInterface::Operation::TicketSearch###SortBy::Default

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default ticket attribute for ticket sorting of the ticket search result of this operation.

GenericInterface

GenericInterface::Operation::TicketSearch

$Self->{'GenericInterface::Operation::TicketSearch'}-

>{'SortBy::Default'} = 'Age';

3.10.3.

GenericInterface::Operation::TicketSearch###Order::Default

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default ticket order in the ticket search result of the this operation. Up: oldest on top. Down: latest on top.

GenericInterface

GenericInterface::Operation::TicketSearch

$Self->{'GenericInterface::Operation::TicketSearch'}-

>{'Order::Default'} = 'Down';

3.11.

GenericInterface::Operation::TicketUpdate

3.11.1.

GenericInterface::Operation::TicketUpdate###ArticleType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default type of the article for this operation.

GenericInterface

GenericInterface::Operation::TicketUpdate

$Self->{'GenericInterface::Operation::TicketUpdate'}-

>{'ArticleType'} = 'webrequest';

3.11.2.

GenericInterface::Operation::TicketUpdate###HistoryType

Description: Defines the history type for this operation, which gets used for ticket history in the agent interface.

407

Group:

SubGroup:

Valid:

Required:

Config-Setting:

GenericInterface

GenericInterface::Operation::TicketUpdate

$Self->{'GenericInterface::Operation::TicketUpdate'}-

>{'HistoryType'} = 'AddNote';

3.11.3.

GenericInterface::Operation::TicketUpdate###HistoryComment

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the history comment for this operation, which gets used for ticket history in the agent interface.

GenericInterface

GenericInterface::Operation::TicketUpdate

$Self->{'GenericInterface::Operation::TicketUpdate'}-

>{'HistoryComment'} = '%%GenericInterface Note';

3.11.4.

GenericInterface::Operation::TicketUpdate###AutoResponseType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default auto response type of the article for this operation.

GenericInterface

GenericInterface::Operation::TicketUpdate

$Self->{'GenericInterface::Operation::TicketUpdate'}-

>{'AutoResponseType'} = 'auto follow up';

3.12.

GenericInterface::Transport::ModuleRegistration

3.12.1.

GenericInterface::Transport::Module###HTTP::SOAP

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

GenericInterface module registration for the transport layer.

GenericInterface

GenericInterface::Transport::ModuleRegistration

$Self->{'GenericInterface::Transport::Module'}->{'HTTP::SOAP'} = {

'ConfigDialog' => 'AdminGenericInterfaceTransportHTTPSOAP',

'Name' => 'SOAP',

'Protocol' => 'HTTP'

};

408

3.12.2.

GenericInterface::Transport::Module###HTTP::Test

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

GenericInterface module registration for the transport layer.

GenericInterface

GenericInterface::Transport::ModuleRegistration

$Self->{'GenericInterface::Transport::Module'}->{'HTTP::Test'} = {

'ConfigDialog' => 'AdminGenericInterfaceTransportHTTPTest',

'Name' => 'Test',

'Protocol' => 'HTTP'

};

3.13. GenericInterface::Webservice

3.13.1. GenericInterface::WebserviceConfig::CacheTTL

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Cache time in seconds for the web service config backend.

GenericInterface

GenericInterface::Webservice

$Self->{'GenericInterface::WebserviceConfig::CacheTTL'} = '86400';

3.13.2.

GenericInterface::Operation::Common::CachedAuth::AgentCacheTTL

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Cache time in seconds for agent authentication in the GenericInterface.

GenericInterface

GenericInterface::Webservice

$Self-

>{'GenericInterface::Operation::Common::CachedAuth::AgentCacheTTL'}

= '300';

3.13.3.

GenericInterface::Operation::Common::CachedAuth::CustomerCacheTTL

Description:

Group:

SubGroup:

Valid:

Required:

Cache time in seconds for customer authentication in the GenericInterface.

GenericInterface

GenericInterface::Webservice

409

Config-Setting:

$Self-

>{'GenericInterface::Operation::Common::CachedAuth::CustomerCacheTTL'}

= '300';

3.13.4. GenericInterface::Webservice::Path::Separator

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Webservice path separator.

GenericInterface

GenericInterface::Webservice

$Self->{'GenericInterface::Webservice::Path::Separator'} = '»';

4. ProcessManagement

4.1. Core

4.1.1.

Process::DynamicFieldProcessManagementProcessID

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

This option defines the dynamic field in which a Process Management process entity id is stored.

ProcessManagement

Core

$Self->{'Process::DynamicFieldProcessManagementProcessID'} =

'ProcessManagementProcessID';

4.1.2.

Process::DynamicFieldProcessManagementActivityID

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

This option defines the dynamic field in which a Process Management activity entity id is stored.

ProcessManagement

Core

$Self->{'Process::DynamicFieldProcessManagementActivityID'} =

'ProcessManagementActivityID';

4.1.3. Process::DefaultQueue

Description:

Group:

SubGroup:

Valid:

Required:

This option defines the process tickets default queue.

ProcessManagement

Core

410

Config-Setting:

$Self->{'Process::DefaultQueue'} = 'Raw';

4.1.4. Process::DefaultState

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

This option defines the process tickets default state.

ProcessManagement

Core

$Self->{'Process::DefaultState'} = 'new';

4.1.5. Process::DefaultLock

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

This option defines the process tickets default lock.

ProcessManagement

Core

$Self->{'Process::DefaultLock'} = 'unlock';

4.1.6. Process::DefaultPriority

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

This option defines the process tickets default priority.

ProcessManagement

Core

$Self->{'Process::DefaultPriority'} = '3 normal';

4.1.7. Process::Entity::Prefix

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Default ProcessManagement entity prefixes for entity IDs that are automatically generated.

ProcessManagement

Core

$Self->{'Process::Entity::Prefix'} = {

'Activity' => 'A',

'ActivityDialog' => 'AD',

'Process' => 'P',

'Transition' => 'T',

'TransitionAction' => 'TA'

};

4.1.8. Process::CacheTTL

Description:

Group:

SubGroup:

Cache time in seconds for the DB process backend.

ProcessManagement

Core

411

Valid:

Required:

Config-Setting:

$Self->{'Process::CacheTTL'} = '3600';

4.1.9. Process::NavBarOutput::CacheTTL

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Cache time in seconds for the ticket process navigation bar output module.

ProcessManagement

Core

$Self->{'Process::NavBarOutput::CacheTTL'} = '900';

4.2. Core::Ticket

4.2.1.

Ticket::EventModulePost###TicketProcessTransitions

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Event module registration. For more performance you can define a trigger event (e. g. Event => TicketCreate).

ProcessManagement

Core::Ticket

$Self->{'Ticket::EventModulePost'}->{'TicketProcessTransitions'} =

{

'Event' => '',

'Module' =>

'Kernel::System::Ticket::Event::TicketProcessTransitions',

'Transaction' => '1'

};

4.3. Frontend::Admin::ModuleRegistration

4.3.1.

Frontend::Module###AdminProcessManagement

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

ProcessManagement

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminProcessManagement'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'Loader' => {

'CSS' => [

'Core.Agent.Admin.ProcessManagement.css',

'Core.AllocationList.css'

412

'JavaScript' => [

'thirdparty/jsplumb-1.5.5/jsplumb.js',

'thirdparty/farahey-0.1/farahey.js',

'thirdparty/jsplumb-labelspacer/label-spacer.js',

'Core.Agent.Admin.ProcessManagement.js',

'Core.Agent.Admin.ProcessManagement.Canvas.js',

'Core.UI.AllocationList.js'

]

'NavBarModule' => {

'Block' => 'System',

'Description' => 'Configure Processes.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Process Management',

'Prio' => '750'

'NavBarName' => 'Admin',

'Title' => 'Process Management'

};

4.3.2.

Frontend::Module###AdminProcessManagementActivity

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

ProcessManagement

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminProcessManagementActivity'} =

{

'Description' => 'Admin',

'Group' => [

'admin'

'Loader' => {

'CSS' => [

'Core.Agent.Admin.ProcessManagement.css',

'Core.AllocationList.css'

'JavaScript' => [

'Core.Agent.Admin.ProcessManagement.js',

'Core.UI.AllocationList.js'

]

'Title' => 'Process Management Activity GUI'

};

4.3.3.

Frontend::Module###AdminProcessManagementActivityDialog

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

ProcessManagement

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}-

>{'AdminProcessManagementActivityDialog'} = {

'Description' => 'Admin',

'Group' => [

'admin'

413

'Loader' => {

'CSS' => [

'Core.Agent.Admin.ProcessManagement.css',

'Core.AllocationList.css'

'JavaScript' => [

'Core.Agent.Admin.ProcessManagement.js',

'Core.UI.AllocationList.js'

]

'Title' => 'Process Management Activity Dialog GUI'

};

4.3.4.

Frontend::Module###AdminProcessManagementTransition

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

ProcessManagement

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminProcessManagementTransition'} =

{

'Description' => 'Admin',

'Group' => [

'admin'

'Loader' => {

'CSS' => [

'Core.Agent.Admin.ProcessManagement.css'

'JavaScript' => [

'Core.Agent.Admin.ProcessManagement.js'

]

'Title' => 'Process Management Transition GUI'

};

4.3.5.

Frontend::Module###AdminProcessManagementTransitionAction

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

ProcessManagement

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}-

>{'AdminProcessManagementTransitionAction'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'Loader' => {

'CSS' => [

'Core.Agent.Admin.ProcessManagement.css'

'JavaScript' => [

'Core.Agent.Admin.ProcessManagement.js'

]

414

'Title' => 'Process Management Transition Action GUI'

};

4.3.6.

Frontend::Module###AdminProcessManagementPath

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

ProcessManagement

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminProcessManagementPath'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'Loader' => {

'CSS' => [

'Core.Agent.Admin.ProcessManagement.css',

'Core.AllocationList.css'

'JavaScript' => [

'Core.Agent.Admin.ProcessManagement.js',

'Core.UI.AllocationList.js'

]

'Title' => 'Process Management Path GUI'

};

4.4. Frontend::Agent::ModuleRegistration

4.4.1. Frontend::Module###AgentTicketProcess

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

ProcessManagement

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketProcess'} = {

'Description' => 'Create new process ticket',

'Loader' => {

'CSS' => [

'Core.Agent.TicketProcess.css'

'JavaScript' => [

'Core.Agent.CustomerSearch.js',

'Core.Agent.TicketAction.js'

]

'NavBar' => [

{

'AccessKey' => 'p',

'Block' => '',

'Description' => 'Create New process ticket',

'Link' => 'Action=AgentTicketProcess',

'LinkOption' => '',

'Name' => 'New process ticket',

'NavBar' => 'Ticket',

'Prio' => '220',

'Type' => ''

}

415

'NavBarName' => 'Ticket',

'Title' => 'New process ticket'

};

4.5. Frontend::Agent::NavBarModule

4.5.1. Frontend::NavBarOutputModule###1-TicketProcesses

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration (disable ticket processes screen if no process available).

ProcessManagement

Frontend::Agent::NavBarModule

$Self->{'Frontend::NavBarOutputModule'}->{'1-TicketProcesses'} = {

'Module' =>

'Kernel::Output::HTML::NavBarOutputModuleAgentTicketProcess'

};

4.6. Frontend::Agent::Ticket::ViewProcess

4.6.1.

Ticket::Frontend::AgentTicketProcess###StateType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Determines the next possible ticket states, for process tickets in the agent interface.

ProcessManagement

Frontend::Agent::Ticket::ViewProcess

$Self->{'Ticket::Frontend::AgentTicketProcess'}->{'StateType'} = [

'new',

'open',

'pending auto',

'pending reminder',

'closed'

];

4.6.2.

Ticket::Frontend::CustomerTicketProcess###StateType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Determines the next possible ticket states, for process tickets in the agent interface.

ProcessManagement

Frontend::Agent::Ticket::ViewProcess

$Self->{'Ticket::Frontend::CustomerTicketProcess'}->{'StateType'} =

[

'new',

'open'

416

];

4.7. Frontend::Agent::Ticket::ViewZoom

4.7.1.

Ticket::Frontend::AgentTicketZoom###ProcessDisplay

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Display settings to override defaults for Process Tickets.

ProcessManagement

Frontend::Agent::Ticket::ViewZoom

$Self->{'Ticket::Frontend::AgentTicketZoom'}->{'ProcessDisplay'} =

{

'NavBarName' => 'Processes',

'WidgetTitle' => 'Process Information'

};

4.7.2.

Ticket::Frontend::AgentTicketZoom###ProcessWidgetDynamicFieldGroups

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Dynamic fields groups for process widget. The key is the name of the group, the value contains the fields to be shown. Example:

'Key => My Group', 'Content: Name_X, NameY'.

ProcessManagement

Frontend::Agent::Ticket::ViewZoom

$Self->{'Ticket::Frontend::AgentTicketZoom'}-

>{'ProcessWidgetDynamicFieldGroups'} = {};

4.7.3.

Ticket::Frontend::AgentTicketZoom###ProcessWidgetDynamicField

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Dynamic fields shown in the process widget in ticket zoom screen of the agent interface. Possible settings: 0 = Disabled, 1 = Enabled.

ProcessManagement

Frontend::Agent::Ticket::ViewZoom

$Self->{'Ticket::Frontend::AgentTicketZoom'}-

>{'ProcessWidgetDynamicField'} = {};

4.8. Frontend::Customer::ModuleRegistration

4.8.1.

CustomerFrontend::Module###CustomerTicketProcess

Description: Frontend module registration for the customer interface.

417

Group:

SubGroup:

Valid:

Required:

Config-Setting:

ProcessManagement

Frontend::Customer::ModuleRegistration

$Self->{'CustomerFrontend::Module'}->{'CustomerTicketProcess'} = {

'Description' => 'Process Ticket',

'Loader' => {

'CSS' => [

'Core.Customer.TicketProcess.css'

]

'NavBar' => [

{

'AccessKey' => 'o',

'Block' => '',

'Description' => 'Create new process ticket',

'Link' => 'Action=CustomerTicketProcess',

'LinkOption' => '',

'Name' => 'New process ticket',

'NavBar' => 'Ticket',

'Prio' => '220',

'Type' => 'Submenu'

}

'NavBarName' => 'Ticket',

'Title' => 'Process ticket'

};

4.9. Frontend::Customer::NavBarModule

4.9.1. CustomerFrontend::NavBarModule###10-CustomerTicketProcesses

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration (disable ticket processes screen if no process available) for Customer.

ProcessManagement

Frontend::Customer::NavBarModule

$Self->{'CustomerFrontend::NavBarModule'}->{'10-

CustomerTicketProcesses'} = {

'Module' =>

'Kernel::Output::HTML::NavBarOutputModuleCustomerTicketProcess'

};

5. Scheduler

5.1. Core

5.1.1. Scheduler::SleepTime

Description:

Group:

SubGroup:

Defines scheduler sleep time in seconds after processing all available tasks (floating point number).

Scheduler

Core

418

Valid:

Required:

Config-Setting:

$Self->{'Scheduler::SleepTime'} = '1.0';

5.1.2. Scheduler::PIDUpdateTime

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines scheduler PID update time in seconds.

Scheduler

Core

$Self->{'Scheduler::PIDUpdateTime'} = '600';

5.1.3. Scheduler::RestartAfterSeconds

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the time in seconds after which the Scheduler performs an automatic self-restart.

Scheduler

Core

$Self->{'Scheduler::RestartAfterSeconds'} = '86400';

5.1.4. Scheduler::TaskDataLength

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the maximum length (in characters) for a scheduler task data. WARNING: Do not modify this setting unless you are sure of the current Database length for 'task_data' filed from

'scheduler_data_list' table.

Scheduler

Core

$Self->{'Scheduler::TaskDataLength'} = '8000';

5.2. Core::Log

5.2.1. Scheduler::LogPath

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the path for scheduler to store its console output

(SchedulerOUT.log and SchedulerERR.log).

Scheduler

Core::Log

$Self->{'Scheduler::LogPath'} = '<OTRS_CONFIG_Home>/var/log';

419

5.2.2. Scheduler::Log::DaysToKeep

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the time in days to keep log backup files.

Scheduler

Core::Log

$Self->{'Scheduler::Log::DaysToKeep'} = '10';

5.3. Core::Web

5.3.1. Loader::Agent::CommonJS###000-GenericInterface

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

List of JS files to always be loaded for the agent interface.

Scheduler

Core::Web

$Self->{'Loader::Agent::CommonJS'}->{'000-GenericInterface'} = [

'Core.Agent.Admin.Scheduler.js'

];

5.4. Frontend::Admin::ModuleRegistration

5.4.1. Frontend::Module###AdminScheduler

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Group:

SubGroup:

Frontend module registration for the agent interface.

Scheduler

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminScheduler'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'Title' => 'GenericInterface Webservice Mapping GUI'

};

5.5. Frontend::Agent::ModuleNotify

5.5.1. Frontend::NotifyModule###800-Scheduler-Check

Description: Defines the module to display a notification in the agent interface if the scheduler is not running.

Scheduler

Frontend::Agent::ModuleNotify

420

Valid:

Required:

Config-Setting:

$Self->{'Frontend::NotifyModule'}->{'800-Scheduler-Check'} = {

'Module' => 'Kernel::Output::HTML::NotificationSchedulerCheck'

};

6. Ticket

6.1. Core

6.1.1. OTRSEscalationEvents::DecayTime

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

The duration in minutes after emitting an event, in which the new escalation notify and start events are suppressed.

Ticket

Core

$Self->{'OTRSEscalationEvents::DecayTime'} = '1440';

6.2. Core::CustomerCompany

6.2.1. CustomerCompany::EventModulePost###110-

UpdateTickets

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Event module that updates tickets after an update of the Customer

Company.

Ticket

Core::CustomerCompany

$Self->{'CustomerCompany::EventModulePost'}->{'110-UpdateTickets'}

= {

'Event' => 'CustomerCompanyUpdate',

'Module' =>

'Kernel::System::CustomerCompany::Event::TicketUpdate',

'Transaction' => '0'

};

6.2.2. CustomerUser::EventModulePost###120-

UpdateTickets

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Event module that updates tickets after an update of the Customer

User.

Ticket

Core::CustomerCompany

$Self->{'CustomerUser::EventModulePost'}->{'120-UpdateTickets'} =

{

421

'Event' => 'CustomerUserUpdate',

'Module' => 'Kernel::System::CustomerUser::Event::TicketUpdate',

'Transaction' => '0'

};

6.3. Core::FulltextSearch

6.3.1. Ticket::SearchIndexModule

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Helps to extend your articles full-text search (From, To, Cc, Subject and Body search). Runtime will do full-text searches on live data (it works fine for up to 50.000 tickets). StaticDB will strip all articles and will build an index after article creation, increasing fulltext searches about 50%. To create an initial index use "bin/ otrs.RebuildFulltextIndex.pl".

Ticket

Core::FulltextSearch

$Self->{'Ticket::SearchIndexModule'} =

'Kernel::System::Ticket::ArticleSearchIndex::RuntimeDB';

6.3.2. Ticket::SearchIndex::Attribute

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Basic fulltext index settings. Execute "bin/ otrs.RebuildFulltextIndex.pl" in order to generate a new index.

Ticket

Core::FulltextSearch

$Self->{'Ticket::SearchIndex::Attribute'} = {

'WordCountMax' => '1000',

'WordLengthMax' => '30',

'WordLengthMin' => '3'

};

6.3.3. Ticket::SearchIndex::Filters

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Fulltext index regex filters to remove parts of the text.

Ticket

Core::FulltextSearch

$Self->{'Ticket::SearchIndex::Filters'} = [

'[,\\&\\<\\>\\?"\\!\\*\\|;\\[\\]\$\$\\+\\$\\^=]',

'^[\':.]|[\':.]$'

];

6.3.4. Ticket::SearchIndex::StopWords

Description:

Group:

Stop words for fulltext index. These words will be removed.

Ticket

422

SubGroup:

Valid:

Required:

Config-Setting:

Core::FulltextSearch

$Self->{'Ticket::SearchIndex::StopWords'} = {

'a' => '1',

'als' => '1',

'and' => '1',

'auf' => '1',

'das' => '1',

'den' => '1',

'der' => '1',

'die' => '1',

'for' => '1',

'im' => '1',

'in' => '1',

'is' => '1',

'of' => '1',

'the' => '1',

'to' => '1',

'und' => '1',

'vom' => '1',

'zu' => '1'

};

6.3.5. Ticket::EventModulePost###98-ArticleSearchIndex

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Builds an article index right after the article's creation.

Ticket

Core::FulltextSearch

$Self->{'Ticket::EventModulePost'}->{'98-ArticleSearchIndex'} = {

'Event' => '(ArticleCreate|ArticleUpdate)',

'Module' => 'Kernel::System::Ticket::Event::ArticleSearchIndex'

};

6.4. Core::LinkObject

6.4.1. LinkObject::PossibleLink###0200

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Links 2 tickets with a "Normal" type link.

Ticket

Core::LinkObject

$Self->{'LinkObject::PossibleLink'}->{'0200'} = {

'Object1' => 'Ticket',

'Object2' => 'Ticket',

'Type' => 'Normal'

};

6.4.2. LinkObject::PossibleLink###0201

Description:

Group:

Links 2 tickets with a "ParentChild" type link.

Ticket

423

SubGroup:

Valid:

Required:

Config-Setting:

Core::LinkObject

$Self->{'LinkObject::PossibleLink'}->{'0201'} = {

'Object1' => 'Ticket',

'Object2' => 'Ticket',

'Type' => 'ParentChild'

};

6.5. Core::PostMaster

6.5.1. PostmasterMaxEmails

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Maximal auto email responses to own email-address a day (Loop-

Protection).

Ticket

Core::PostMaster

$Self->{'PostmasterMaxEmails'} = '40';

6.5.2. PostMasterMaxEmailSize

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Maximal size in KBytes for mails that can be fetched via POP3/

POP3S/IMAP/IMAPS (KBytes).

Ticket

Core::PostMaster

$Self->{'PostMasterMaxEmailSize'} = '16384';

6.5.3. PostMasterReconnectMessage

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

The "bin/PostMasterMailAccount.pl" will reconnect to POP3/POP3S/

IMAP/IMAPS host after the specified count of messages.

Ticket

Core::PostMaster

$Self->{'PostMasterReconnectMessage'} = '20';

6.5.4. LoopProtectionModule

Description:

Group:

SubGroup:

Valid:

Required:

Default loop protection module.

Ticket

Core::PostMaster

424

Config-Setting:

$Self->{'LoopProtectionModule'} =

'Kernel::System::PostMaster::LoopProtection::DB';

6.5.5. LoopProtectionLog

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Path for the log file (it only applies if "FS" was selected for Loop-

ProtectionModule and it is mandatory).

Ticket

Core::PostMaster

$Self->{'LoopProtectionLog'} = '<OTRS_CONFIG_Home>/var/log/

LoopProtection';

6.5.6. PostmasterAutoHTML2Text

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Converts HTML mails into text messages.

Ticket

Core::PostMaster

$Self->{'PostmasterAutoHTML2Text'} = '1';

6.5.7. PostmasterFollowUpSearchInReferences

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Executes follow up checks on In-Reply-To or References headers for mails that don't have a ticket number in the subject.

Ticket

Core::PostMaster

$Self->{'PostmasterFollowUpSearchInReferences'} = '0';

6.5.8. PostmasterFollowUpSearchInBody

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Executes follow up mail body checks in mails that don't have a ticket number in the subject.

Ticket

Core::PostMaster

$Self->{'PostmasterFollowUpSearchInBody'} = '0';

6.5.9. PostmasterFollowUpSearchInAttachment

Description:

Group:

Executes follow up mail attachments checks in mails that don't have a ticket number in the subject.

Ticket

425

SubGroup:

Valid:

Required:

Config-Setting:

Core::PostMaster

$Self->{'PostmasterFollowUpSearchInAttachment'} = '0';

6.5.10. PostmasterFollowUpSearchInRaw

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Executes follow up plain/raw mail checks in mails that don't have a ticket number in the subject.

Ticket

Core::PostMaster

$Self->{'PostmasterFollowUpSearchInRaw'} = '0';

6.5.11. PostmasterUserID

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies user id of the postmaster data base.

Ticket

Core::PostMaster

$Self->{'PostmasterUserID'} = '1';

6.5.12. PostmasterDefaultQueue

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the postmaster default queue.

Ticket

Core::PostMaster

$Self->{'PostmasterDefaultQueue'} = 'Raw';

6.5.13. PostmasterDefaultPriority

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default priority of new tickets.

Ticket

Core::PostMaster

$Self->{'PostmasterDefaultPriority'} = '3 normal';

6.5.14. PostmasterDefaultState

Description:

Group:

Defines the default state of new tickets.

Ticket

426

SubGroup:

Valid:

Required:

Config-Setting:

Core::PostMaster

$Self->{'PostmasterDefaultState'} = 'new';

6.5.15. PostmasterFollowUpState

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the state of a ticket if it gets a follow-up.

Ticket

Core::PostMaster

$Self->{'PostmasterFollowUpState'} = 'open';

6.5.16. PostmasterFollowUpStateClosed

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the state of a ticket if it gets a follow-up and the ticket was already closed.

Ticket

Core::PostMaster

$Self->{'PostmasterFollowUpStateClosed'} = 'open';

6.5.17. PostmasterFollowUpOnUnlockAgentNotifyOnly-

ToOwner

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sends agent follow-up notification only to the owner, if a ticket is unlocked (the default is to send the notification to all agents).

Ticket

Core::PostMaster

$Self->{'PostmasterFollowUpOnUnlockAgentNotifyOnlyToOwner'} = '0';

6.5.18. PostmasterX-Header

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines all the X-headers that should be scanned.

Ticket

Core::PostMaster

$Self->{'PostmasterX-Header'} = [

'From',

'To',

'Cc',

'Reply-To',

'ReplyTo',

427

'Subject',

'Message-ID',

'Message-Id',

'Resent-To',

'Resent-From',

'Precedence',

'Mailing-List',

'List-Id',

'List-Archive',

'Errors-To',

'References',

'In-Reply-To',

'Auto-Submitted',

'X-Loop',

'X-Spam-Flag',

'X-Spam-Level',

'X-Spam-Score',

'X-Spam-Status',

'X-No-Loop',

'X-Priority',

'Importance',

'X-Mailer',

'User-Agent',

'Organization',

'X-Original-To',

'Delivered-To',

'Envelope-To',

'Return-Path',

'X-OTRS-Owner',

'X-OTRS-OwnerID',

'X-OTRS-Responsible',

'X-OTRS-ResponsibleID',

'X-OTRS-Loop',

'X-OTRS-Priority',

'X-OTRS-Queue',

'X-OTRS-Lock',

'X-OTRS-Ignore',

'X-OTRS-State',

'X-OTRS-State-PendingTime',

'X-OTRS-Type',

'X-OTRS-Service',

'X-OTRS-SLA',

'X-OTRS-CustomerNo',

'X-OTRS-CustomerUser',

'X-OTRS-SenderType',

'X-OTRS-ArticleType',

'X-OTRS-FollowUp-Priority',

'X-OTRS-FollowUp-Queue',

'X-OTRS-FollowUp-Lock',

'X-OTRS-FollowUp-State',

'X-OTRS-FollowUp-State-PendingTime',

'X-OTRS-FollowUp-Type',

'X-OTRS-FollowUp-Service',

'X-OTRS-FollowUp-SLA',

'X-OTRS-FollowUp-SenderType',

'X-OTRS-FollowUp-ArticleType'

];

6.5.19. PostMaster::PreFilterModule###1-Match

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Module to filter and manipulate incoming messages. Block/ignore all spam email with From: noreply@ address.

Ticket

Core::PostMaster

$Self->{'PostMaster::PreFilterModule'}->{'1-Match'} = {

428

'Match' => {

'From' => 'noreply@'

'Module' => 'Kernel::System::PostMaster::Filter::Match',

'Set' => {

'X-OTRS-Ignore' => 'yes'

'StopAfterMatch' => '0'

};

6.5.20. PostMaster::PreFilterModule###2-Match

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Module to filter and manipulate incoming messages. Get a 4 digit number to ticket free text, use regex in Match e. g. From => '(.

+?)@.+?', and use () as [***] in Set =>.

Ticket

Core::PostMaster

$Self->{'PostMaster::PreFilterModule'}->{'2-Match'} = {

'Match' => {

'Subject' => 'SomeNumber:(\\d\\d\\d\\d)'

'Module' => 'Kernel::System::PostMaster::Filter::Match',

'Set' => {

'X-OTRS-DynamicField-TicketFreeKey1' => 'SomeNumber',

'X-OTRS-DynamicField-TicketFreeText1' => '[***]'

'StopAfterMatch' => '0'

};

6.5.21. PostMaster::PreFilterModule###3-NewTicketReject

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Blocks all the incoming emails that do not have a valid ticket number in subject with From: @example.com address.

Ticket

Core::PostMaster

$Self->{'PostMaster::PreFilterModule'}->{'3-NewTicketReject'} = {

'Match' => {

'From' => '@example.com'

'Module' => 'Kernel::System::PostMaster::Filter::NewTicketReject',

'Set' => {

'X-OTRS-Ignore' => 'yes'

'StopAfterMatch' => '0'

};

6.5.22.

PostMaster::PreFilterModule::NewTicketReject::Sender

Description:

Group:

SubGroup:

Defines the sender for rejected emails.

Ticket

Core::PostMaster

429

Valid:

Required:

Config-Setting:

$Self->{'PostMaster::PreFilterModule::NewTicketReject::Sender'} =

'[email protected]';

6.5.23.

PostMaster::PreFilterModule::NewTicketReject::Subject

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the subject for rejected emails.

Ticket

Core::PostMaster

$Self->{'PostMaster::PreFilterModule::NewTicketReject::Subject'} =

'Email Rejected';

6.5.24.

PostMaster::PreFilterModule::NewTicketReject::Body

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the body text for rejected emails.

Ticket

Core::PostMaster

$Self->{'PostMaster::PreFilterModule::NewTicketReject::Body'} = '

Dear Customer,

Unfortunately we could not detect a valid ticket number in your subject, so this email can\'t be processed.

Please create a new ticket via the customer panel.

Thanks for your help!

Your Helpdesk Team

6.5.25. PostMaster::PreFilterModule###4-CMD

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

CMD example setup. Ignores emails where external CMD returns some output on STDOUT (email will be piped into STDIN of some.bin).

Ticket

Core::PostMaster

$Self->{'PostMaster::PreFilterModule'}->{'4-CMD'} = {

'CMD' => '/usr/bin/some.bin',

'Module' => 'Kernel::System::PostMaster::Filter::CMD',

'Set' => {

'X-OTRS-Ignore' => 'yes'

}

};

430

6.5.26. PostMaster::PreFilterModule###5-SpamAssassin

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Spam Assassin example setup. Ignores emails that are marked with SpamAssassin.

Ticket

Core::PostMaster

$Self->{'PostMaster::PreFilterModule'}->{'5-SpamAssassin'} = {

'CMD' => '/usr/bin/spamassassin | grep -i "X-Spam-Status: yes"',

'Module' => 'Kernel::System::PostMaster::Filter::CMD',

'Set' => {

'X-OTRS-Ignore' => 'yes'

}

};

6.5.27. PostMaster::PreFilterModule###6-SpamAssassin

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Spam Assassin example setup. Moves marked mails to spam queue.

Ticket

Core::PostMaster

$Self->{'PostMaster::PreFilterModule'}->{'6-SpamAssassin'} = {

'CMD' => '/usr/bin/spamassassin | grep -i "X-Spam-Status: yes"',

'Module' => 'Kernel::System::PostMaster::Filter::CMD',

'Set' => {

'X-OTRS-Queue' => 'spam'

}

};

6.5.28. PostMaster::PreFilterModule###000-Match-

DBSource

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Module to use database filter storage.

Ticket

Core::PostMaster

$Self->{'PostMaster::PreFilterModule'}->{'000-MatchDBSource'} = {

'Module' => 'Kernel::System::PostMaster::Filter::MatchDBSource'

};

6.5.29. PostMaster::PostFilterModule###000-FollowUpArticleTypeCheck

Description: Module to check if arrived emails should be marked as email-internal (because of original forwarded internal email). ArticleType and

SenderType define the values for the arrived email/article.

431

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Core::PostMaster

$Self->{'PostMaster::PostFilterModule'}->{'000-

FollowUpArticleTypeCheck'} = {

'ArticleType' => 'email-internal',

'Module' =>

'Kernel::System::PostMaster::Filter::FollowUpArticleTypeCheck',

'SenderType' => 'customer'

};

6.5.30. PostMaster::PreFilterModule###000-External-

TicketNumberRecognition1

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Recognize if a ticket is a follow up to an existing ticket using an external ticket number.

Ticket

Core::PostMaster

$Self->{'PostMaster::PreFilterModule'}->{'000-

ExternalTicketNumberRecognition1'} = {

'ArticleType' => 'note-report',

'DynamicFieldName' => 'Name_X',

'FromAddressRegExp' => '\\s*@example.com',

'Module' =>

'Kernel::System::PostMaster::Filter::ExternalTicketNumberRecognition',

'Name' => 'Some Description',

'NumberRegExp' => '\\s*Incident-(\\d.*)\\s*',

'SearchInBody' => '1',

'SearchInSubject' => '1',

'SenderType' => 'system',

'TicketStateTypes' => 'new;open'

};

6.5.31. PostMaster::PreFilterModule###000-External-

TicketNumberRecognition2

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Recognize if a ticket is a follow up to an existing ticket using an external ticket number.

Ticket

Core::PostMaster

$Self->{'PostMaster::PreFilterModule'}->{'000-

ExternalTicketNumberRecognition2'} = {

'ArticleType' => 'note-report',

'DynamicFieldName' => 'Name_X',

'FromAddressRegExp' => '\\s*@example.com',

'Module' =>

'Kernel::System::PostMaster::Filter::ExternalTicketNumberRecognition',

'Name' => 'Some Description',

'NumberRegExp' => '\\s*Incident-(\\d.*)\\s*',

'SearchInBody' => '1',

'SearchInSubject' => '1',

'SenderType' => 'system',

432

'TicketStateTypes' => 'new;open'

};

6.5.32. PostMaster::PreFilterModule###000-External-

TicketNumberRecognition3

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Recognize if a ticket is a follow up to an existing ticket using an external ticket number.

Ticket

Core::PostMaster

$Self->{'PostMaster::PreFilterModule'}->{'000-

ExternalTicketNumberRecognition3'} = {

'ArticleType' => 'note-report',

'DynamicFieldName' => 'Name_X',

'FromAddressRegExp' => '\\s*@example.com',

'Module' =>

'Kernel::System::PostMaster::Filter::ExternalTicketNumberRecognition',

'Name' => 'Some Description',

'NumberRegExp' => '\\s*Incident-(\\d.*)\\s*',

'SearchInBody' => '1',

'SearchInSubject' => '1',

'SenderType' => 'system',

'TicketStateTypes' => 'new;open'

};

6.5.33. PostMaster::PreFilterModule###000-External-

TicketNumberRecognition4

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Recognize if a ticket is a follow up to an existing ticket using an external ticket number.

Ticket

Core::PostMaster

$Self->{'PostMaster::PreFilterModule'}->{'000-

ExternalTicketNumberRecognition4'} = {

'ArticleType' => 'note-report',

'DynamicFieldName' => 'Name_X',

'FromAddressRegExp' => '\\s*@example.com',

'Module' =>

'Kernel::System::PostMaster::Filter::ExternalTicketNumberRecognition',

'Name' => 'Some Description',

'NumberRegExp' => '\\s*Incident-(\\d.*)\\s*',

'SearchInBody' => '1',

'SearchInSubject' => '1',

'SenderType' => 'system',

'TicketStateTypes' => 'new;open'

};

6.5.34. SendNoAutoResponseRegExp

Description:

Group:

If this regex matches, no message will be send by the autoresponder.

Ticket

433

SubGroup:

Valid:

Required:

Config-Setting:

Core::PostMaster

$Self->{'SendNoAutoResponseRegExp'} = '(MAILER-DAEMON|postmaster| abuse)@.+?\\..+?';

6.5.35. AutoResponseForWebTickets

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If this option is set to 'Yes', tickets created via the web interface, via

Customers or Agents, will receive an autoresponse if configured.

If this option is set to 'No', no autoresponses will be sent.

Ticket

Core::PostMaster

$Self->{'AutoResponseForWebTickets'} = '1';

6.6. Core::Stats

6.6.1. Stats::DynamicObjectRegistration###Ticket

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Module to generate ticket statistics.

Ticket

Core::Stats

$Self->{'Stats::DynamicObjectRegistration'}->{'Ticket'} = {

'Module' => 'Kernel::System::Stats::Dynamic::Ticket'

};

6.6.2. Stats::DynamicObjectRegistration###TicketList

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Determines if the statistics module may generate ticket lists.

Ticket

Core::Stats

$Self->{'Stats::DynamicObjectRegistration'}->{'TicketList'} = {

'Module' => 'Kernel::System::Stats::Dynamic::TicketList'

};

6.6.3.

Stats::DynamicObjectRegistration###TicketAccountedTime

Description:

Group:

SubGroup:

Module to generate accounted time ticket statistics.

Ticket

Core::Stats

434

Valid:

Required:

Config-Setting:

$Self->{'Stats::DynamicObjectRegistration'}-

>{'TicketAccountedTime'} = {

'Module' => 'Kernel::System::Stats::Dynamic::TicketAccountedTime'

};

6.6.4.

Stats::DynamicObjectRegistration###TicketSolutionResponseTime

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Module to generate ticket solution and response time statistics.

Ticket

Core::Stats

$Self->{'Stats::DynamicObjectRegistration'}-

>{'TicketSolutionResponseTime'} = {

'Module' =>

'Kernel::System::Stats::Dynamic::TicketSolutionResponseTime'

};

6.7. Core::Ticket

6.7.1. Ticket::Hook

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

The identifier for a ticket, e.g. Ticket#, Call#, MyTicket#. The default is Ticket#.

Ticket

Core::Ticket

$Self->{'Ticket::Hook'} = 'Ticket#';

6.7.2. Ticket::HookDivider

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

The divider between TicketHook and ticket number. E.g ': '.

Ticket

Core::Ticket

$Self->{'Ticket::HookDivider'} = '';

6.7.3. Ticket::SubjectSize

Description:

Group:

SubGroup:

Valid:

Max size of the subjects in an email reply.

Ticket

Core::Ticket

435

Required:

Config-Setting:

$Self->{'Ticket::SubjectSize'} = '100';

6.7.4. Ticket::SubjectRe

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

The text at the beginning of the subject in an email reply, e.g. RE,

AW, or AS.

Ticket

Core::Ticket

$Self->{'Ticket::SubjectRe'} = 'Re';

6.7.5. Ticket::SubjectFwd

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

The text at the beginning of the subject when an email is forwarded, e.g. FW, Fwd, or WG.

Ticket

Core::Ticket

$Self->{'Ticket::SubjectFwd'} = 'Fwd';

6.7.6. Ticket::SubjectFormat

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

The format of the subject. 'Left' means '[TicketHook#:12345]

Some Subject', 'Right' means 'Some Subject [Ticket-

Hook#:12345]', 'None' means 'Some Subject' and no ticket number. In the last case you should enable PostmasterFollowupSearchInRaw or PostmasterFollowUpSearchInReferences to recognize followups based on email headers and/or body.

Ticket

Core::Ticket

$Self->{'Ticket::SubjectFormat'} = 'Left';

6.7.7. Ticket::CustomQueue

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Name of custom queue. The custom queue is a queue selection of your preferred queues and can be selected in the preferences settings.

Ticket

Core::Ticket

$Self->{'Ticket::CustomQueue'} = 'My Queues';

436

6.7.8. Ticket::NewArticleIgnoreSystemSender

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ignore article with system sender type for new article feature (e.

g. auto responses or email notifications).

Ticket

Core::Ticket

$Self->{'Ticket::NewArticleIgnoreSystemSender'} = '0';

6.7.9. Ticket::ChangeOwnerToEveryone

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Changes the owner of tickets to everyone (useful for ASP). Normally only agent with rw permissions in the queue of the ticket will be shown.

Ticket

Core::Ticket

$Self->{'Ticket::ChangeOwnerToEveryone'} = '0';

6.7.10. Ticket::Responsible

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Enables ticket responsible feature, to keep track of a specific ticket.

Ticket

Core::Ticket

$Self->{'Ticket::Responsible'} = '0';

6.7.11. Ticket::ResponsibleAutoSet

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Automatically sets the owner of a ticket as the responsible for it

(if ticket responsible feature is enabled).

Ticket

Core::Ticket

$Self->{'Ticket::ResponsibleAutoSet'} = '1';

6.7.12. Ticket::Type

Description:

Group:

Allows defining new types for ticket (if ticket type feature is enabled).

Ticket

437

SubGroup:

Valid:

Required:

Config-Setting:

Core::Ticket

$Self->{'Ticket::Type'} = '0';

6.7.13. Ticket::Service

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Allows defining services and SLAs for tickets (e. g. email, desktop, network, ...), and escalation attributes for SLAs (if ticket service/SLA feature is enabled).

Ticket

Core::Ticket

$Self->{'Ticket::Service'} = '0';

6.7.14. Ticket::Service::Default::UnknownCustomer

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Allows default services to be selected also for non existing customers.

Ticket

Core::Ticket

$Self->{'Ticket::Service::Default::UnknownCustomer'} = '0';

6.7.15. Ticket::ArchiveSystem

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Activates the ticket archive system to have a faster system by moving some tickets out of the daily scope. To search for these tickets, the archive flag has to be enabled in the ticket search.

Ticket

Core::Ticket

$Self->{'Ticket::ArchiveSystem'} = '0';

6.7.16. Ticket::ArchiveSystem::RemoveSeenFlags

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Controls if the ticket and article seen flags are removed when a ticket is archived.

Ticket

Core::Ticket

$Self->{'Ticket::ArchiveSystem::RemoveSeenFlags'} = '1';

438

6.7.17. Ticket::ArchiveSystem::RemoveTicketWatchers

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Removes the ticket watcher information when a ticket is archived.

Ticket

Core::Ticket

$Self->{'Ticket::ArchiveSystem::RemoveTicketWatchers'} = '1';

6.7.18. Ticket::CustomerArchiveSystem

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Activates the ticket archive system search in the customer interface.

Ticket

Core::Ticket

$Self->{'Ticket::CustomerArchiveSystem'} = '0';

6.7.19. Ticket::NumberGenerator

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Selects the ticket number generator module. "AutoIncrement" increments the ticket number, the SystemID and the counter are used with SystemID.counter format (e.g. 1010138, 1010139).

With "Date" the ticket numbers will be generated by the current date, the SystemID and the counter. The format looks like Year.Month.Day.SystemID.counter (e.g. 200206231010138,

200206231010139). With "DateChecksum" the counter will be appended as checksum to the string of date and SystemID. The checksum will be rotated on a daily basis. The format looks like Year.Month.Day.SystemID.Counter.CheckSum

(e.g. 2002070110101520, 2002070110101535). "Random" generates randomized ticket numbers in the format

"SystemID.Random" (e.g. 100057866352, 103745394596).

Ticket

Core::Ticket

$Self->{'Ticket::NumberGenerator'} =

'Kernel::System::Ticket::Number::DateChecksum';

6.7.20. Ticket::NumberGenerator::CheckSystemID

Description:

Group:

SubGroup:

Valid:

Required:

Checks the SystemID in ticket number detection for follow-ups

(use "No" if SystemID has been changed after using the system).

Ticket

Core::Ticket

439

Config-Setting:

$Self->{'Ticket::NumberGenerator::CheckSystemID'} = '1';

6.7.21. Ticket::NumberGenerator::MinCounterSize

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the minimal ticket counter size (if "AutoIncrement" was selected as TicketNumberGenerator). Default is 5, this means the counter starts from 10000.

Ticket

Core::Ticket

$Self->{'Ticket::NumberGenerator::MinCounterSize'} = '5';

6.7.22.

Ticket::NumberGenerator::Date::UseFormattedCounter

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Enables the minimal ticket counter size (if "Date" was selected as

TicketNumberGenerator).

Ticket

Core::Ticket

$Self->{'Ticket::NumberGenerator::Date::UseFormattedCounter'} =

'0';

6.7.23. Ticket::CounterLog

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Log file for the ticket counter.

Ticket

Core::Ticket

$Self->{'Ticket::CounterLog'} = '<OTRS_CONFIG_Home>/var/log/

TicketCounter.log';

6.7.24. Ticket::IndexModule

Description:

Group:

SubGroup:

Valid:

IndexAccelerator: to choose your backend TicketViewAccelerator module. "RuntimeDB" generates each queue view on the fly from ticket table (no performance problems up to approx. 60.000

tickets in total and 6.000 open tickets in the system). "StaticDB" is the most powerful module, it uses an extra ticket-index table that works like a view (recommended if more than 80.000 and

6.000 open tickets are stored in the system). Use the script "bin/ otrs.RebuildTicketIndex.pl" for initial index update.

Ticket

Core::Ticket

440

Required:

Config-Setting:

$Self->{'Ticket::IndexModule'} =

'Kernel::System::Ticket::IndexAccelerator::RuntimeDB';

6.7.25. Ticket::StorageModule

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Saves the attachments of articles. "DB" stores all data in the database (not recommended for storing big attachments). "FS" stores the data on the filesystem; this is faster but the webserver should run under the OTRS user. You can switch between the modules even on a system that is already in production without any loss of data.

Ticket

Core::Ticket

$Self->{'Ticket::StorageModule'} =

'Kernel::System::Ticket::ArticleStorageDB';

6.7.26. ArticleDir

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the directory to store the data in, if "FS" was selected for

TicketStorageModule.

Ticket

Core::Ticket

$Self->{'ArticleDir'} = '<OTRS_CONFIG_Home>/var/article';

6.7.27. Ticket::EventModulePost###100-ArchiveRestore

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Restores a ticket from the archive (only if the event is a state change, from closed to any open available state).

Ticket

Core::Ticket

$Self->{'Ticket::EventModulePost'}->{'100-ArchiveRestore'} = {

'Event' => 'TicketStateUpdate',

'Module' => 'Kernel::System::Ticket::Event::ArchiveRestore'

};

6.7.28. Ticket::EventModulePost###110-AcceleratorUpdate

Description:

Group:

SubGroup:

Updates the ticket index accelerator.

Ticket

Core::Ticket

441

Valid:

Required:

Config-Setting:

$Self->{'Ticket::EventModulePost'}->{'110-AcceleratorUpdate'} = {

'Event' => 'TicketStateUpdate|TicketQueueUpdate|TicketLockUpdate',

'Module' =>

'Kernel::System::Ticket::Event::TicketAcceleratorUpdate'

};

6.7.29. Ticket::EventModulePost###120-ForceOwner-

ResetOnMove

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Resets and unlocks the owner of a ticket if it was moved to another queue.

Ticket

Core::Ticket

$Self->{'Ticket::EventModulePost'}->{'120-ForceOwnerResetOnMove'} =

{

'Event' => 'TicketQueueUpdate',

'Module' => 'Kernel::System::Ticket::Event::ForceOwnerReset'

};

6.7.30. Ticket::EventModulePost###130-ForceStateChangeOnLock

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Forces to choose a different ticket state (from current) after lock action. Define the current state as key, and the next state after lock action as content.

Ticket

Core::Ticket

$Self->{'Ticket::EventModulePost'}->{'130-ForceStateChangeOnLock'}

= {

'Event' => 'TicketLockUpdate',

'Module' => 'Kernel::System::Ticket::Event::ForceState',

'new' => 'open'

};

6.7.31. Ticket::EventModulePost###140-ResponsibleAutoSet

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Automatically sets the responsible of a ticket (if it is not set yet) after the first owner update.

Ticket

Core::Ticket

$Self->{'Ticket::EventModulePost'}->{'140-ResponsibleAutoSet'} = {

'Event' => 'TicketOwnerUpdate',

'Module' => 'Kernel::System::Ticket::Event::ResponsibleAutoSet'

442

};

6.7.32. Ticket::EventModulePost###150-TicketPendingTimeReset

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the PendingTime of a ticket to 0 if the state is changed to a non-pending state.

Ticket

Core::Ticket

$Self->{'Ticket::EventModulePost'}->{'150-TicketPendingTimeReset'}

= {

'Event' => 'TicketStateUpdate',

'Module' =>

'Kernel::System::Ticket::Event::TicketPendingTimeReset'

};

6.7.33. Ticket::EventModulePost###500-NotificationEvent

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sends the notifications which are configured in the admin interface under "Notfication (Event)".

Ticket

Core::Ticket

$Self->{'Ticket::EventModulePost'}->{'500-NotificationEvent'} = {

'Event' => '',

'Module' => 'Kernel::System::Ticket::Event::NotificationEvent',

'Transaction' => '1'

};

6.7.34. Ticket::EventModulePost###900-EscalationIndex

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Updates the ticket escalation index after a ticket attribute got updated.

Ticket

Core::Ticket

$Self->{'Ticket::EventModulePost'}->{'900-EscalationIndex'} = {

'Event' => 'TicketSLAUpdate|TicketQueueUpdate|TicketStateUpdate|

TicketCreate|ArticleCreate',

'Module' => 'Kernel::System::Ticket::Event::TicketEscalationIndex'

};

6.7.35. Ticket::EventModulePost###900-EscalationStopEvents

Description: Ticket event module that triggers the escalation stop events.

443

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Core::Ticket

$Self->{'Ticket::EventModulePost'}->{'900-EscalationStopEvents'} =

{

'Event' => 'TicketSLAUpdate|TicketQueueUpdate|TicketStateUpdate|

ArticleCreate',

'Module' =>

'Kernel::System::Ticket::Event::TriggerEscalationStopEvents'

};

6.7.36. Ticket::EventModulePost###910-ForceUnlockOnMove

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Forces to unlock tickets after being moved to another queue.

Ticket

Core::Ticket

$Self->{'Ticket::EventModulePost'}->{'910-ForceUnlockOnMove'} = {

'Event' => 'TicketQueueUpdate',

'Module' => 'Kernel::System::Ticket::Event::ForceUnlock'

};

6.7.37. Ticket::EventModulePost###920-TicketArticle-

NewMessageUpdate

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Update Ticket "Seen" flag if every article got seen or a new Article got created.

Ticket

Core::Ticket

$Self->{'Ticket::EventModulePost'}->{'920-

TicketArticleNewMessageUpdate'} = {

'Event' => 'ArticleCreate|ArticleFlagSet',

'Module' =>

'Kernel::System::Ticket::Event::TicketNewMessageUpdate'

};

6.7.38. DynamicFieldFromCustomerUser::Mapping

Description:

Group:

Define a mapping between variables of the customer user data

(keys) and dynamic fields of a ticket (values). The purpose is to store customer user data in ticket dynamic fields. The dynamic fields must be present in the system and should be enabled for Agent-

TicketFreeText, so that they can be set/updated manually by the agent. They mustn't be enabled for AgentTicketPhone, AgentTicketEmail and AgentTicketCustomer. If they were, they would have precedence over the automatically set values. To use this mapping, you have to also activate the next setting below.

Ticket

444

SubGroup:

Valid:

Required:

Config-Setting:

Core::Ticket

$Self->{'DynamicFieldFromCustomerUser::Mapping'} = {

'UserFirstname' => 'CustomerFirstname'

};

6.7.39. Ticket::EventModulePost###930-DynamicField-

FromCustomerUser

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

This event module stores attributes from CustomerUser as DynamicFields tickets. Please see the setting above for how to configure the mapping.

Ticket

Core::Ticket

$Self->{'Ticket::EventModulePost'}->{'930-

DynamicFieldFromCustomerUser'} = {

'Event' => '(TicketCreate|TicketCustomerUpdate)',

'Module' =>

'Kernel::System::Ticket::Event::DynamicFieldFromCustomerUser'

};

6.7.40. Ticket::CustomModule###001-CustomModule

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Overloads (redefines) existing functions in Kernel::System::Ticket.

Used to easily add customizations.

Ticket

Core::Ticket

$Self->{'Ticket::CustomModule'}->{'001-CustomModule'} =

'Kernel::System::Ticket::Custom';

6.7.41. Ticket::ViewableSenderTypes

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default viewable sender types of a ticket (default: customer).

Ticket

Core::Ticket

$Self->{'Ticket::ViewableSenderTypes'} = [

'\'customer\''

];

6.7.42. Ticket::ViewableLocks

Description: Defines the viewable locks of a ticket. Default: unlock, tmp_lock.

445

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Core::Ticket

$Self->{'Ticket::ViewableLocks'} = [

'\'unlock\'',

'\'tmp_lock\''

];

6.7.43. Ticket::ViewableStateType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the valid state types for a ticket.

Ticket

Core::Ticket

$Self->{'Ticket::ViewableStateType'} = [

'new',

'open',

'pending reminder',

'pending auto'

];

6.7.44. Ticket::UnlockStateType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the valid states for unlocked tickets. To unlock tickets the script "bin/otrs.UnlockTickets.pl" can be used.

Ticket

Core::Ticket

$Self->{'Ticket::UnlockStateType'} = [

'new',

'open'

];

6.7.45. Ticket::PendingNotificationOnlyToOwner

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sends reminder notifications of unlocked ticket after reaching the reminder date (only sent to ticket owner).

Ticket

Core::Ticket

$Self->{'Ticket::PendingNotificationOnlyToOwner'} = '0';

6.7.46. Ticket::PendingNotificationNotToResponsible

Description: Disables sending reminder notifications to the responsible agent of a ticket (Ticket::Responsible needs to be activated).

446

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Core::Ticket

$Self->{'Ticket::PendingNotificationNotToResponsible'} = '0';

6.7.47. Ticket::PendingReminderStateType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the state type of the reminder for pending tickets.

Ticket

Core::Ticket

$Self->{'Ticket::PendingReminderStateType'} = [

'pending reminder'

];

6.7.48. Ticket::PendingAutoStateType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Determines the possible states for pending tickets that changed state after reaching time limit.

Ticket

Core::Ticket

$Self->{'Ticket::PendingAutoStateType'} = [

'pending auto'

];

6.7.49. Ticket::StateAfterPending

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines which states should be set automatically (Content), after the pending time of state (Key) has been reached.

Ticket

Core::Ticket

$Self->{'Ticket::StateAfterPending'} = {

'pending auto close+' => 'closed successful',

'pending auto close-' => 'closed unsuccessful'

};

6.7.50. System::Permission

Description: Standard available permissions for agents within the application. If more permissions are needed, they can be entered here. Permissions must be defined to be effective. Some other good permissions have also been provided built-in: note, close, pending, customer, freetext, move, compose, responsible, forward, and bounce. Make sure that "rw" is always the last registered permission.

447

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Core::Ticket

$Self->{'System::Permission'} = [

'ro',

'move_into',

'create',

'note',

'owner',

'priority',

'rw'

];

6.7.51. Ticket::Permission###1-OwnerCheck

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Module to check the owner of a ticket.

Ticket

Core::Ticket

$Self->{'Ticket::Permission'}->{'1-OwnerCheck'} = {

'Granted' => '1',

'Module' => 'Kernel::System::Ticket::Permission::OwnerCheck',

'Required' => '0'

};

6.7.52. Ticket::Permission###2-ResponsibleCheck

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Module to check the agent responsible of a ticket.

Ticket

Core::Ticket

$Self->{'Ticket::Permission'}->{'2-ResponsibleCheck'} = {

'Granted' => '1',

'Module' =>

'Kernel::System::Ticket::Permission::ResponsibleCheck',

'Required' => '0'

};

6.7.53. Ticket::Permission###3-GroupCheck

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Module to check if a user is in a special group. Access is granted, if the user is in the specified group and has ro and rw permissions.

Ticket

Core::Ticket

$Self->{'Ticket::Permission'}->{'3-GroupCheck'} = {

'Granted' => '1',

'Module' => 'Kernel::System::Ticket::Permission::GroupCheck',

'Required' => '0'

};

448

6.7.54. Ticket::Permission###4-WatcherCheck

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Module to check the watcher agents of a ticket.

Ticket

Core::Ticket

$Self->{'Ticket::Permission'}->{'4-WatcherCheck'} = {

'Granted' => '1',

'Module' => 'Kernel::System::Ticket::Permission::WatcherCheck',

'Required' => '0'

};

6.7.55. CustomerTicket::Permission###1-GroupCheck

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Module to check the group permissions for the access to customer tickets.

Ticket

Core::Ticket

$Self->{'CustomerTicket::Permission'}->{'1-GroupCheck'} = {

'Granted' => '0',

'Module' =>

'Kernel::System::Ticket::CustomerPermission::GroupCheck',

'Required' => '1'

};

6.7.56. CustomerTicket::Permission###2-CustomerUserIDCheck

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Grants access, if the customer ID of the ticket matches the customer user's ID and the customer user has group permissions on the queue the ticket is in.

Ticket

Core::Ticket

$Self->{'CustomerTicket::Permission'}->{'2-CustomerUserIDCheck'} =

{

'Granted' => '1',

'Module' =>

'Kernel::System::Ticket::CustomerPermission::CustomerUserIDCheck',

'Required' => '0'

};

6.7.57. CustomerTicket::Permission###3-CustomerID-

Check

Description:

Group:

SubGroup:

Module to check customer permissions.

Ticket

Core::Ticket

449

Valid:

Required:

Config-Setting:

$Self->{'CustomerTicket::Permission'}->{'3-CustomerIDCheck'} = {

'Granted' => '1',

'Module' =>

'Kernel::System::Ticket::CustomerPermission::CustomerIDCheck',

'Required' => '0'

};

6.7.58. Ticket::DefineEmailFrom

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines how the From field from the emails (sent from answers and email tickets) should look like.

Ticket

Core::Ticket

$Self->{'Ticket::DefineEmailFrom'} = 'SystemAddressName';

6.7.59. Ticket::DefineEmailFromSeparator

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the separator between the agents real name and the given queue email address.

Ticket

Core::Ticket

$Self->{'Ticket::DefineEmailFromSeparator'} = 'via';

6.7.60. CustomerNotifyJustToRealCustomer

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sends customer notifications just to the mapped customer. Normally, if no customer is mapped, the latest customer sender gets the notification.

Ticket

Core::Ticket

$Self->{'CustomerNotifyJustToRealCustomer'} = '0';

6.7.61. AgentSelfNotifyOnAction

Description:

Group:

SubGroup:

Valid:

Required:

Specifies if an agent should receive email notification of his own actions.

Ticket

Core::Ticket

450

Config-Setting:

$Self->{'AgentSelfNotifyOnAction'} = '0';

6.7.62. Ticket::EventModulePost###900-GenericAgent

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Event module registration. For more performance you can define a trigger event (e. g. Event => TicketCreate).

Ticket

Core::Ticket

$Self->{'Ticket::EventModulePost'}->{'900-GenericAgent'} = {

'Event' => '',

'Module' => 'Kernel::System::Ticket::Event::GenericAgent',

'Transaction' => '1'

};

6.7.63. StandardTemplate::Types

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the list of types for templates.

Ticket

Core::Ticket

$Self->{'StandardTemplate::Types'} = {

'Answer' => 'Answer',

'Create' => 'Create',

'Forward' => 'Forward',

'PhoneCall' => 'Phone call'

};

6.8. Core::TicketACL

6.8.1. Ticket::Acl::Module###1-Ticket::Acl::Module

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

ACL module that allows closing parent tickets only if all its children are already closed ("State" shows which states are not available for the parent ticket until all child tickets are closed).

Ticket

Core::TicketACL

$Self->{'Ticket::Acl::Module'}->{'1-Ticket::Acl::Module'} = {

'Module' =>

'Kernel::System::Ticket::Acl::CloseParentAfterClosedChilds',

'State' => [

'closed successful',

'closed unsuccessful'

]

};

6.8.2. TicketACL::Default::Action

Description: Default ACL values for ticket actions.

451

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Core::TicketACL

$Self->{'TicketACL::Default::Action'} = {};

6.8.3. ACLKeysLevel1Match

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines which items are available in first level of the ACL structure.

Ticket

Core::TicketACL

$Self->{'ACLKeysLevel1Match'} = {

'Properties' => 'Properties',

'PropertiesDatabase' => 'PropertiesDatabase'

};

6.8.4. ACLKeysLevel1Change

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines which items are available in first level of the ACL structure.

Ticket

Core::TicketACL

$Self->{'ACLKeysLevel1Change'} = {

'Possible' => 'Possible',

'PossibleNot' => 'PossibleNot'

};

6.8.5. ACLKeysLevel2::Possible

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines which items are available in second level of the ACL structure.

Ticket

Core::TicketACL

$Self->{'ACLKeysLevel2::Possible'} = {

'Action' => 'Action',

'ActivityDialog' => 'ActivityDialog',

'Process' => 'Process',

'Ticket' => 'Ticket'

};

6.8.6. ACLKeysLevel2::PossibleNot

Description: Defines which items are available in second level of the ACL structure.

452

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Core::TicketACL

$Self->{'ACLKeysLevel2::PossibleNot'} = {

'ActivityDialog' => 'ActivityDialog',

'Process' => 'Process',

'Ticket' => 'Ticket'

};

6.8.7. ACLKeysLevel2::Properties

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines which items are available in second level of the ACL structure.

Ticket

Core::TicketACL

$Self->{'ACLKeysLevel2::Properties'} = {

'CustomerUser' => 'CustomerUser',

'DynamicField' => 'DynamicField',

'Frontend' => 'Frontend',

'Owner' => 'Owner',

'Priority' => 'Priority',

'Process' => 'Process',

'Queue' => 'Queue',

'Responsible' => 'Responsible',

'SLA' => 'SLA',

'Service' => 'Service',

'State' => 'State',

'Ticket' => 'Ticket',

'Type' => 'Type',

'User' => 'User'

};

6.8.8. ACLKeysLevel2::PropertiesDatabase

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines which items are available in second level of the ACL structure.

Ticket

Core::TicketACL

$Self->{'ACLKeysLevel2::PropertiesDatabase'} = {

'CustomerUser' => 'CustomerUser',

'DynamicField' => 'DynamicField',

'Owner' => 'Owner',

'Priority' => 'Priority',

'Process' => 'Process',

'Queue' => 'Queue',

'Responsible' => 'Responsible',

'SLA' => 'SLA',

'Service' => 'Service',

'State' => 'State',

'Ticket' => 'Ticket',

'Type' => 'Type',

'User' => 'User'

};

453

6.8.9. ACLKeysLevel3::Actions###100-Default

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines which items are available for 'Action' in third level of the

ACL structure.

Ticket

Core::TicketACL

$Self->{'ACLKeysLevel3::Actions'}->{'100-Default'} = [

'AgentTicketBounce',

'AgentTicketClose',

'AgentTicketCompose',

'AgentTicketCustomer',

'AgentTicketForward',

'AgentTicketFreeText',

'AgentTicketHistory',

'AgentTicketLink',

'AgentTicketLock',

'AgentTicketMerge',

'AgentTicketMove',

'AgentTicketNote',

'AgentTicketOwner',

'AgentTicketPending',

'AgentTicketPhone',

'AgentTicketPhoneInbound',

'AgentTicketPhoneOutbound',

'AgentTicketPrint',

'AgentTicketPriority',

'AgentTicketResponsible',

'AgentTicketWatcher',

'AgentTicketZoom',

'AgentLinkObject',

'CustomerTicketMessage',

'CustomerTicketPrint',

'CustomerTicketProcess',

'CustomerTicketZoom'

];

6.8.10. ACL::CacheTTL

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Cache time in seconds for the DB ACL backend.

Ticket

Core::TicketACL

$Self->{'ACL::CacheTTL'} = '3600';

6.9. Core::TicketBulkAction

6.9.1. Ticket::Frontend::BulkFeature

Description:

Group:

SubGroup:

Valid:

Enables ticket bulk action feature for the agent frontend to work on more than one ticket at a time.

Ticket

Core::TicketBulkAction

454

Required:

Config-Setting:

$Self->{'Ticket::Frontend::BulkFeature'} = '1';

6.9.2. Ticket::Frontend::BulkFeatureGroup

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Enables ticket bulk action feature only for the listed groups.

Ticket

Core::TicketBulkAction

$Self->{'Ticket::Frontend::BulkFeatureGroup'} = [

'admin',

'users'

];

6.10. Core::TicketDynamicFieldDefault

6.10.1.

Ticket::EventModulePost###TicketDynamicFieldDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Event module registration. For more performance you can define a trigger event (e. g. Event => TicketCreate). This is only possible if all Ticket dynamic fields need the same event.

Ticket

Core::TicketDynamicFieldDefault

$Self->{'Ticket::EventModulePost'}->{'TicketDynamicFieldDefault'} =

{

'Module' =>

'Kernel::System::Ticket::Event::TicketDynamicFieldDefault',

'Transaction' => '1'

};

6.10.2.

Ticket::TicketDynamicFieldDefault###Element1

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Configures a default TicketDynamicField setting. "Name" defines the dynamic field which should be used, "Value" is the data that will be set, and "Event" defines the trigger event. Please check the developer manual (http://doc.otrs.org/), chapter "Ticket Event

Module".

Ticket

Core::TicketDynamicFieldDefault

$Self->{'Ticket::TicketDynamicFieldDefault'}->{'Element1'} = {

'Event' => 'TicketCreate',

'Name' => 'Field1',

'Value' => 'Default'

};

455

6.10.3.

Ticket::TicketDynamicFieldDefault###Element2

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Module".

Ticket

Core::TicketDynamicFieldDefault

$Self->{'Ticket::TicketDynamicFieldDefault'}->{'Element2'} = {

'Event' => '',

'Name' => '',

'Value' => ''

};

6.10.4.

Ticket::TicketDynamicFieldDefault###Element3

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Module".

Ticket

Core::TicketDynamicFieldDefault

$Self->{'Ticket::TicketDynamicFieldDefault'}->{'Element3'} = {

'Event' => '',

'Name' => '',

'Value' => ''

};

6.10.5.

Ticket::TicketDynamicFieldDefault###Element4

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Module".

Ticket

Core::TicketDynamicFieldDefault

$Self->{'Ticket::TicketDynamicFieldDefault'}->{'Element4'} = {

'Event' => '',

'Name' => '',

'Value' => ''

456

};

6.10.6.

Ticket::TicketDynamicFieldDefault###Element5

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Module".

Ticket

Core::TicketDynamicFieldDefault

$Self->{'Ticket::TicketDynamicFieldDefault'}->{'Element5'} = {

'Event' => '',

'Name' => '',

'Value' => ''

};

6.10.7.

Ticket::TicketDynamicFieldDefault###Element6

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Module".

Ticket

Core::TicketDynamicFieldDefault

$Self->{'Ticket::TicketDynamicFieldDefault'}->{'Element6'} = {

'Event' => '',

'Name' => '',

'Value' => ''

};

6.10.8.

Ticket::TicketDynamicFieldDefault###Element7

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Module".

Ticket

Core::TicketDynamicFieldDefault

$Self->{'Ticket::TicketDynamicFieldDefault'}->{'Element7'} = {

457

'Event' => '',

'Name' => '',

'Value' => ''

};

6.10.9.

Ticket::TicketDynamicFieldDefault###Element8

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Module".

Ticket

Core::TicketDynamicFieldDefault

$Self->{'Ticket::TicketDynamicFieldDefault'}->{'Element8'} = {

'Event' => '',

'Name' => '',

'Value' => ''

};

6.10.10.

Ticket::TicketDynamicFieldDefault###Element9

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Module".

Ticket

Core::TicketDynamicFieldDefault

$Self->{'Ticket::TicketDynamicFieldDefault'}->{'Element9'} = {

'Event' => '',

'Name' => '',

'Value' => ''

};

6.10.11.

Ticket::TicketDynamicFieldDefault###Element10

Description:

Group:

SubGroup:

Valid:

Module".

Ticket

Core::TicketDynamicFieldDefault

458

Required:

Config-Setting:

$Self->{'Ticket::TicketDynamicFieldDefault'}->{'Element10'} = {

'Event' => '',

'Name' => '',

'Value' => ''

};

6.10.12.

Ticket::TicketDynamicFieldDefault###Element11

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Module".

Ticket

Core::TicketDynamicFieldDefault

$Self->{'Ticket::TicketDynamicFieldDefault'}->{'Element11'} = {

'Event' => '',

'Name' => '',

'Value' => ''

};

6.10.13.

Ticket::TicketDynamicFieldDefault###Element12

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Module".

Ticket

Core::TicketDynamicFieldDefault

$Self->{'Ticket::TicketDynamicFieldDefault'}->{'Element12'} = {

'Event' => '',

'Name' => '',

'Value' => ''

};

6.10.14.

Ticket::TicketDynamicFieldDefault###Element13

Description:

Group:

Module".

Ticket

459

SubGroup:

Valid:

Required:

Config-Setting:

Core::TicketDynamicFieldDefault

$Self->{'Ticket::TicketDynamicFieldDefault'}->{'Element13'} = {

'Event' => '',

'Name' => '',

'Value' => ''

};

6.10.15.

Ticket::TicketDynamicFieldDefault###Element14

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Module".

Ticket

Core::TicketDynamicFieldDefault

$Self->{'Ticket::TicketDynamicFieldDefault'}->{'Element14'} = {

'Event' => '',

'Name' => '',

'Value' => ''

};

6.10.16.

Ticket::TicketDynamicFieldDefault###Element15

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Module".

Ticket

Core::TicketDynamicFieldDefault

$Self->{'Ticket::TicketDynamicFieldDefault'}->{'Element15'} = {

'Event' => '',

'Name' => '',

'Value' => ''

};

6.10.17.

Ticket::TicketDynamicFieldDefault###Element16

Description: Configures a default TicketDynamicField setting. "Name" defines the dynamic field which should be used, "Value" is the data that will be set, and "Event" defines the trigger event. Please check the developer manual (http://doc.otrs.org/), chapter "Ticket Event

Module".

460

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Core::TicketDynamicFieldDefault

$Self->{'Ticket::TicketDynamicFieldDefault'}->{'Element16'} = {

'Event' => '',

'Name' => '',

'Value' => ''

};

6.11. Core::TicketWatcher

6.11.1. Ticket::Watcher

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Enables or disables the ticket watcher feature, to keep track of tickets without being the owner nor the responsible.

Ticket

Core::TicketWatcher

$Self->{'Ticket::Watcher'} = '0';

6.11.2. Ticket::WatcherGroup

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Enables ticket watcher feature only for the listed groups.

Ticket

Core::TicketWatcher

$Self->{'Ticket::WatcherGroup'} = [

'admin',

'users'

];

6.12. Frontend::Admin

6.12.1. Events###Ticket

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

List of all ticket events to be displayed in the GUI.

Ticket

Frontend::Admin

$Self->{'Events'}->{'Ticket'} = [

'TicketCreate',

'TicketDelete',

'TicketTitleUpdate',

'TicketUnlockTimeoutUpdate',

'TicketQueueUpdate',

'TicketTypeUpdate',

'TicketServiceUpdate',

461

'TicketSLAUpdate',

'TicketCustomerUpdate',

'TicketPendingTimeUpdate',

'TicketLockUpdate',

'TicketArchiveFlagUpdate',

'TicketStateUpdate',

'TicketOwnerUpdate',

'TicketResponsibleUpdate',

'TicketPriorityUpdate',

'HistoryAdd',

'HistoryDelete',

'TicketAccountTime',

'TicketMerge',

'TicketSubscribe',

'TicketUnsubscribe',

'TicketFlagSet',

'TicketFlagDelete',

'TicketSlaveLinkAdd',

'TicketSlaveLinkDelete',

'TicketMasterLinkDelete',

'EscalationResponseTimeNotifyBefore',

'EscalationUpdateTimeNotifyBefore',

'EscalationSolutionTimeNotifyBefore',

'EscalationResponseTimeStart',

'EscalationUpdateTimeStart',

'EscalationSolutionTimeStart',

'EscalationResponseTimeStop',

'EscalationUpdateTimeStop',

'EscalationSolutionTimeStop'

];

6.12.2. Events###Article

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

List of all article events to be displayed in the GUI.

Ticket

Frontend::Admin

$Self->{'Events'}->{'Article'} = [

'ArticleCreate',

'ArticleUpdate',

'ArticleSend',

'ArticleBounce',

'ArticleAgentNotification',

'ArticleCustomerNotification',

'ArticleAutoResponse',

'ArticleFlagSet',

'ArticleFlagDelete',

'ArticleAgentNotification',

'ArticleCustomerNotification'

];

6.13. Frontend::Admin::ModuleRegistration

6.13.1. Frontend::Module###AdminACL

Description:

Group:

SubGroup:

Valid:

Required:

Frontend module registration for the agent interface.

Ticket

Frontend::Admin::ModuleRegistration

462

Config-Setting:

$Self->{'Frontend::Module'}->{'AdminACL'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'Loader' => {

'CSS' => [

'Core.Agent.Admin.ACL.css'

'JavaScript' => [

'Core.Agent.Admin.ACL.js'

]

'NavBarModule' => {

'Block' => 'Ticket',

'Description' => 'Configure and manage ACLs.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Access Control Lists (ACL)',

'Prio' => '750'

'NavBarName' => 'Admin',

'Title' => 'Access Control Lists (ACL)'

};

6.13.2. Frontend::Module###AdminQueue

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminQueue'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'Queue',

'Description' => 'Create and manage queues.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Queues',

'Prio' => '100'

'NavBarName' => 'Admin',

'Title' => 'Queues'

};

6.13.3. Frontend::Module###AdminTemplate

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminTemplate'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'Queue',

'Description' => 'Create and manage templates.',

463

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Templates',

'Prio' => '200'

'NavBarName' => 'Admin',

'Title' => 'Templates'

};

6.13.4. Frontend::Module###AdminQueueTemplates

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminQueueTemplates'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'Queue',

'Description' => 'Link templates to queues.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Templates <-> Queues',

'Prio' => '300'

'NavBarName' => 'Admin',

'Title' => 'Templates <-> Queues'

};

6.13.5. Frontend::Module###AdminAutoResponse

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminAutoResponse'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'Queue',

'Description' => 'Create and manage responses that are

automatically sent.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Auto Responses',

'Prio' => '400'

'NavBarName' => 'Admin',

'Title' => 'Auto Responses'

};

6.13.6.

Frontend::Module###AdminQueueAutoResponse

Description: Frontend module registration for the agent interface.

464

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminQueueAutoResponse'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'Queue',

'Description' => 'Link queues to auto responses.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Auto Responses <-> Queues',

'Prio' => '500'

'NavBarName' => 'Admin',

'Title' => 'Auto Responses <-> Queues'

};

6.13.7. Frontend::Module###AdminAttachment

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminAttachment'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'Queue',

'Description' => 'Create and manage attachments.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Attachments',

'Prio' => '600'

'NavBarName' => 'Admin',

'Title' => 'Attachments'

};

6.13.8.

Frontend::Module###AdminTemplateAttachment

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminTemplateAttachment'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'Queue',

465

'Description' => 'Link attachments to templates.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Attachments <-> Templates',

'Prio' => '700'

'NavBarName' => 'Admin',

'Title' => 'Attachments <-> Templates'

};

6.13.9. Frontend::Module###AdminSalutation

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminSalutation'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'Queue',

'Description' => 'Create and manage salutations.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Salutations',

'Prio' => '800'

'NavBarName' => 'Admin',

'Title' => 'Salutations'

};

6.13.10. Frontend::Module###AdminSignature

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminSignature'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'Queue',

'Description' => 'Create and manage signatures.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Signatures',

'Prio' => '900'

'NavBarName' => 'Admin',

'Title' => 'Signatures'

};

6.13.11. Frontend::Module###AdminSystemAddress

Description:

Group:

Frontend module registration for the agent interface.

Ticket

466

SubGroup:

Valid:

Required:

Config-Setting:

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminSystemAddress'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'Email',

'Description' => 'Set sender email addresses for this system.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Email Addresses',

'Prio' => '300'

'NavBarName' => 'Admin',

'Title' => 'Email Addresses'

};

6.13.12. Frontend::Module###AdminNotification

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminNotification'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'Ticket',

'Description' => 'Manage notifications that are sent to

agents.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Agent Notifications',

'Prio' => '400'

'NavBarName' => 'Admin',

'Title' => 'Agent Notifications'

};

6.13.13. Frontend::Module###AdminNotificationEvent

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminNotificationEvent'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'Ticket',

'Description' => 'Create and manage event based notifications.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

467

'Name' => 'Notifications (Event)',

'Prio' => '400'

'NavBarName' => 'Admin',

'Title' => 'Notifications (Event)'

};

6.13.14. Frontend::Module###AdminService

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminService'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'Ticket',

'Description' => 'Create and manage services.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Services',

'Prio' => '900'

'NavBarName' => 'Admin',

'Title' => 'Services'

};

6.13.15. Frontend::Module###AdminSLA

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminSLA'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'Ticket',

'Description' => 'Create and manage Service Level Agreements

(SLAs).',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Service Level Agreements',

'Prio' => '1000'

'NavBarName' => 'Admin',

'Title' => 'Service Level Agreements'

};

6.13.16. Frontend::Module###AdminType

Description:

Group:

Frontend module registration for the agent interface.

Ticket

468

SubGroup:

Valid:

Required:

Config-Setting:

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminType'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'Ticket',

'Description' => 'Create and manage ticket types.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Types',

'Prio' => '700'

'NavBarName' => 'Admin',

'Title' => 'Types'

};

6.13.17. Frontend::Module###AdminState

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminState'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'Ticket',

'Description' => 'Create and manage ticket states.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'States',

'Prio' => '800'

'NavBarName' => 'Admin',

'Title' => 'States'

};

6.13.18. Frontend::Module###AdminPriority

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminPriority'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'NavBarModule' => {

'Block' => 'Ticket',

'Description' => 'Create and manage ticket priorities.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'Priorities',

'Prio' => '850'

469

'NavBarName' => 'Admin',

'Title' => 'Priorities'

};

6.13.19. Frontend::Module###AdminGenericAgent

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Admin::ModuleRegistration

$Self->{'Frontend::Module'}->{'AdminGenericAgent'} = {

'Description' => 'Admin',

'Group' => [

'admin'

'Loader' => {

'JavaScript' => [

'Core.Agent.Admin.GenericAgent.js'

]

'NavBarModule' => {

'Block' => 'System',

'Description' => 'Manage tasks triggered by event or time based

execution.',

'Module' => 'Kernel::Output::HTML::NavBarModuleAdmin',

'Name' => 'GenericAgent',

'Prio' => '300'

'NavBarName' => 'Admin',

'Title' => 'GenericAgent'

};

6.14. Frontend::Agent

6.14.1. Ticket::Frontend::PendingDiffTime

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Time in seconds that gets added to the actual time if setting a pending-state (default: 86400 = 1 day).

Ticket

Frontend::Agent

$Self->{'Ticket::Frontend::PendingDiffTime'} = '86400';

6.14.2. Ticket::Frontend::MaxQueueLevel

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Define the max depth of queues.

Ticket

Frontend::Agent

$Self->{'Ticket::Frontend::MaxQueueLevel'} = '5';

470

6.14.3. Ticket::Frontend::ListType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows existing parent/child queue lists in the system in the form of a tree or a list.

Ticket

Frontend::Agent

$Self->{'Ticket::Frontend::ListType'} = 'tree';

6.14.4. Ticket::Frontend::TextAreaEmail

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Permitted width for compose email windows.

Ticket

Frontend::Agent

$Self->{'Ticket::Frontend::TextAreaEmail'} = '82';

6.14.5. Ticket::Frontend::TextAreaNote

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Permitted width for compose note windows.

Ticket

Frontend::Agent

$Self->{'Ticket::Frontend::TextAreaNote'} = '78';

6.14.6. Ticket::Frontend::InformAgentMaxSize

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Max size (in rows) of the informed agents box in the agent interface.

Ticket

Frontend::Agent

$Self->{'Ticket::Frontend::InformAgentMaxSize'} = '3';

6.14.7. Ticket::Frontend::InvolvedAgentMaxSize

Description:

Group:

SubGroup:

Valid:

Required:

Max size (in rows) of the involved agents box in the agent interface.

Ticket

Frontend::Agent

471

Config-Setting:

$Self->{'Ticket::Frontend::InvolvedAgentMaxSize'} = '3';

6.14.8. Ticket::Frontend::CustomerInfoCompose

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows the customer user information (phone and email) in the compose screen.

Ticket

Frontend::Agent

$Self->{'Ticket::Frontend::CustomerInfoCompose'} = '1';

6.14.9.

Ticket::Frontend::CustomerInfoComposeMaxSize

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Max size (in characters) of the customer information table (phone and email) in the compose screen.

Ticket

Frontend::Agent

$Self->{'Ticket::Frontend::CustomerInfoComposeMaxSize'} = '22';

6.14.10. Ticket::Frontend::CustomerInfoZoom

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows the customer user's info in the ticket zoom view.

Ticket

Frontend::Agent

$Self->{'Ticket::Frontend::CustomerInfoZoom'} = '1';

6.14.11. Ticket::Frontend::CustomerInfoZoomMaxSize

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Maximum size (in characters) of the customer information table in the ticket zoom view.

Ticket

Frontend::Agent

$Self->{'Ticket::Frontend::CustomerInfoZoomMaxSize'} = '22';

6.14.12.

Ticket::Frontend::DynamicFieldsZoomMaxSizeSidebar

Description: Maximum length (in characters) of the dynamic field in the sidebar of the ticket zoom view.

472

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Agent

$Self->{'Ticket::Frontend::DynamicFieldsZoomMaxSizeSidebar'} =

'18';

6.14.13.

Ticket::Frontend::DynamicFieldsZoomMaxSizeArticle

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Maximum length (in characters) of the dynamic field in the article of the ticket zoom view.

Ticket

Frontend::Agent

$Self->{'Ticket::Frontend::DynamicFieldsZoomMaxSizeArticle'} =

'160';

6.14.14. Ticket::Frontend::AccountTime

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Activates time accounting.

Ticket

Frontend::Agent

$Self->{'Ticket::Frontend::AccountTime'} = '1';

6.14.15. Ticket::Frontend::TimeUnits

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the prefered time units (e.g. work units, hours, minutes).

Ticket

Frontend::Agent

$Self->{'Ticket::Frontend::TimeUnits'} = ' (work units)';

6.14.16. Ticket::Frontend::NeedAccountedTime

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines if time accounting is mandatory in the agent interface.

Ticket

Frontend::Agent

$Self->{'Ticket::Frontend::NeedAccountedTime'} = '0';

473

6.14.17. Ticket::Frontend::BulkAccountedTime

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines if time accounting must be set to all tickets in bulk action.

Ticket

Frontend::Agent

$Self->{'Ticket::Frontend::BulkAccountedTime'} = '1';

6.14.18. Ticket::Frontend::NeedSpellCheck

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines if composed messages have to be spell checked in the agent interface.

Ticket

Frontend::Agent

$Self->{'Ticket::Frontend::NeedSpellCheck'} = '0';

6.14.19. Ticket::Frontend::NewOwnerSelection

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows an owner selection in phone and email tickets in the agent interface.

Ticket

Frontend::Agent

$Self->{'Ticket::Frontend::NewOwnerSelection'} = '1';

6.14.20. Ticket::Frontend::NewResponsibleSelection

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Show a responsible selection in phone and email tickets in the agent interface.

Ticket

Frontend::Agent

$Self->{'Ticket::Frontend::NewResponsibleSelection'} = '1';

6.14.21. Ticket::Frontend::NewQueueSelectionType

Description:

Group:

SubGroup:

Valid:

Defines the receipent target of the phone ticket and the sender of the email ticket ("Queue" shows all queues, "SystemAddress" displays all system addresses) in the agent interface.

Ticket

Frontend::Agent

474

Required:

Config-Setting:

$Self->{'Ticket::Frontend::NewQueueSelectionType'} = 'Queue';

6.14.22. Ticket::Frontend::NewQueueSelectionString

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Determines the strings that will be shown as receipent (To:) of the phone ticket and as sender (From:) of the email ticket in the agent interface. For Queue as NewQueueSelectionType

"<Queue>" shows the names of the queues and for SystemAddress "<Realname> <<Email>>" shows the name and email of the receipent.

Ticket

Frontend::Agent

$Self->{'Ticket::Frontend::NewQueueSelectionString'} = '<Queue>';

6.14.23. Ticket::Frontend::NewQueueOwnSelection

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Determines which options will be valid of the recepient (phone ticket) and the sender (email ticket) in the agent interface.

Ticket

Frontend::Agent

$Self->{'Ticket::Frontend::NewQueueOwnSelection'} = {

'1' => 'First Queue!',

'2' => 'Second Queue!'

};

6.14.24. Ticket::Frontend::ShowCustomerTickets

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows customer history tickets in AgentTicketPhone, AgentTicketEmail and AgentTicketCustomer.

Ticket

Frontend::Agent

$Self->{'Ticket::Frontend::ShowCustomerTickets'} = '1';

6.14.25. NewTicketInNewWindow::Enabled

Description:

Group:

SubGroup:

Valid:

Required:

If enabled, TicketPhone and TicketEmail will be open in new windows.

Ticket

Frontend::Agent

475

Config-Setting:

$Self->{'NewTicketInNewWindow::Enabled'} = '0';

6.14.26. CustomerDBLink

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines an external link to the database of the customer (e.g.

'http://yourhost/customer.php?CID=$Data{"CustomerID"}' or '').

Ticket

Frontend::Agent

$Self->{'CustomerDBLink'} = '$Env{"CGIHandle"}?

Action=AgentCustomerInformationCenter;CustomerID=

$LQData{"CustomerID"}';

6.14.27. CustomerDBLinkTarget

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the target attribute in the link to external customer database. E.g. 'target="cdb"'.

Ticket

Frontend::Agent

$Self->{'CustomerDBLinkTarget'} = '';

6.14.28. CustomerDBLinkClass

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the target attribute in the link to external customer database. E.g. 'AsPopup PopupType_TicketAction'.

Ticket

Frontend::Agent

$Self->{'CustomerDBLinkClass'} = '';

6.14.29. Frontend::CommonObject###QueueObject

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Path of the file that stores all the settings for the QueueObject object for the agent interface.

Ticket

Frontend::Agent

$Self->{'Frontend::CommonObject'}->{'QueueObject'} =

'Kernel::System::Queue';

6.14.30. Frontend::CommonObject###TicketObject

Description: Path of the file that stores all the settings for the TicketObject for the agent interface.

476

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Agent

$Self->{'Frontend::CommonObject'}->{'TicketObject'} =

'Kernel::System::Ticket';

6.14.31. Frontend::CommonParam###Action

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default used Frontend-Module if no Action parameter given in the url on the agent interface.

Ticket

Frontend::Agent

$Self->{'Frontend::CommonParam'}->{'Action'} = 'AgentDashboard';

6.14.32. Frontend::CommonParam###QueueID

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Default queue ID used by the system in the agent interface.

Ticket

Frontend::Agent

$Self->{'Frontend::CommonParam'}->{'QueueID'} = '0';

6.14.33. Frontend::CommonParam###TicketID

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Default ticket ID used by the system in the agent interface.

Ticket

Frontend::Agent

$Self->{'Frontend::CommonParam'}->{'TicketID'} = '';

6.14.34. DefaultOverviewColumns

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

General ticket data shown in the ticket overviews (fall-back). Possible settings: 0 = Disabled, 1 = Available, 2 = Enabled by default.

Note that TicketNumber can not be disabled, because it is necessary.

Ticket

Frontend::Agent

$Self->{'DefaultOverviewColumns'} = {

'Age' => '2',

'Changed' => '1',

477

'CustomerID' => '2',

'CustomerName' => '1',

'CustomerUserID' => '1',

'EscalationResponseTime' => '1',

'EscalationSolutionTime' => '1',

'EscalationTime' => '1',

'EscalationUpdateTime' => '1',

'Lock' => '2',

'Owner' => '2',

'PendingTime' => '1',

'Priority' => '1',

'Queue' => '2',

'Responsible' => '1',

'SLA' => '1',

'Service' => '1',

'State' => '2',

'TicketNumber' => '2',

'Title' => '2',

'Type' => '1'

};

6.15. Frontend::Agent::Dashboard

6.15.1. DashboardBackend###0100-TicketPendingReminder

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Parameters for the dashboard backend of the ticket pending reminder overview of the agent interface . "Limit" is the number of entries shown by default. "Group" is used to restrict the access to the plugin (e. g. Group: admin;group1;group2;). "Default" determines if the plugin is enabled by default or if the user needs to enable it manually. "CacheTTLLocal" is the cache time in minutes for the plugin. Note: Only Ticket attributes and Dynamic Fields

(DynamicField_NameX) are allowed for DefaultColumns. Possible settings: 0 = Disabled, 1 = Available, 2 = Enabled by default.

Ticket

Frontend::Agent::Dashboard

$Self->{'DashboardBackend'}->{'0100-TicketPendingReminder'} = {

'Attributes' => 'TicketPendingTimeOlderMinutes=1;StateType=pending

reminder;SortBy=PendingTime;OrderBy=Down;',

'Block' => 'ContentLarge',

'CacheTTLLocal' => '0.5',

'Default' => '1',

'DefaultColumns' => {

'Age' => '2',

'Changed' => '1',

'CustomerID' => '1',

'CustomerName' => '1',

'CustomerUserID' => '1',

'EscalationResponseTime' => '1',

'EscalationSolutionTime' => '1',

'EscalationTime' => '1',

'EscalationUpdateTime' => '1',

'Lock' => '1',

'Owner' => '1',

'PendingTime' => '1',

'Priority' => '1',

'Queue' => '1',

'Responsible' => '1',

'SLA' => '1',

'Service' => '1',

'State' => '1',

478

'TicketNumber' => '2',

'Title' => '2',

'Type' => '1'

'Description' => 'All tickets with a reminder set where the

reminder date has been reached',

'Filter' => 'Locked',

'Group' => '',

'Limit' => '10',

'Module' => 'Kernel::Output::HTML::DashboardTicketGeneric',

'Permission' => 'rw',

'Time' => 'UntilTime',

'Title' => 'Reminder Tickets'

};

6.15.2. DashboardBackend###0110-TicketEscalation

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Parameters for the dashboard backend of the ticket escalation overview of the agent interface . "Limit" is the number of entries shown by default. "Group" is used to restrict the access to the plugin (e. g. Group: admin;group1;group2;). "Default" determines if the plugin is enabled by default or if the user needs to enable it manually. "CacheTTLLocal" is the cache time in minutes for the plugin. Note: Only Ticket attributes and Dynamic Fields

(DynamicField_NameX) are allowed for DefaultColumns. Possible settings: 0 = Disabled, 1 = Available, 2 = Enabled by default.

Ticket

Frontend::Agent::Dashboard

$Self->{'DashboardBackend'}->{'0110-TicketEscalation'} = {

'Attributes' =>

'TicketEscalationTimeOlderMinutes=1;SortBy=EscalationTime;OrderBy=Down;',

'Block' => 'ContentLarge',

'CacheTTLLocal' => '0.5',

'Default' => '1',

'DefaultColumns' => {

'Age' => '2',

'Changed' => '1',

'CustomerID' => '1',

'CustomerName' => '1',

'CustomerUserID' => '1',

'EscalationResponseTime' => '1',

'EscalationSolutionTime' => '1',

'EscalationTime' => '1',

'EscalationUpdateTime' => '1',

'Lock' => '1',

'Owner' => '1',

'PendingTime' => '1',

'Priority' => '1',

'Queue' => '1',

'Responsible' => '1',

'SLA' => '1',

'Service' => '1',

'State' => '1',

'TicketNumber' => '2',

'Title' => '2',

'Type' => '1'

'Description' => 'All escalated tickets',

'Filter' => 'All',

'Group' => '',

'Limit' => '10',

'Module' => 'Kernel::Output::HTML::DashboardTicketGeneric',

'Permission' => 'rw',

'Time' => 'EscalationTime',

479

'Title' => 'Escalated Tickets'

};

6.15.3. DashboardBackend###0120-TicketNew

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Parameters for the dashboard backend of the new tickets overview of the agent interface. "Limit" is the number of entries shown by default. "Group" is used to restrict the access to the plugin (e. g.

Group: admin;group1;group2;). "Default" determines if the plugin is enabled by default or if the user needs to enable it manually.

"CacheTTLLocal" is the cache time in minutes for the plugin. Note:

Only Ticket attributes and Dynamic Fields (DynamicField_NameX) are allowed for DefaultColumns. Possible settings: 0 = Disabled, 1

= Available, 2 = Enabled by default.

Ticket

Frontend::Agent::Dashboard

$Self->{'DashboardBackend'}->{'0120-TicketNew'} = {

'Attributes' => 'StateType=new;',

'Block' => 'ContentLarge',

'CacheTTLLocal' => '0.5',

'Default' => '1',

'DefaultColumns' => {

'Age' => '2',

'Changed' => '1',

'CustomerID' => '1',

'CustomerName' => '1',

'CustomerUserID' => '1',

'EscalationResponseTime' => '1',

'EscalationSolutionTime' => '1',

'EscalationTime' => '1',

'EscalationUpdateTime' => '1',

'Lock' => '1',

'Owner' => '1',

'PendingTime' => '1',

'Priority' => '1',

'Queue' => '1',

'Responsible' => '1',

'SLA' => '1',

'Service' => '1',

'State' => '1',

'TicketNumber' => '2',

'Title' => '2',

'Type' => '1'

'Description' => 'All new tickets, these tickets have not been

worked on yet',

'Filter' => 'All',

'Group' => '',

'Limit' => '10',

'Module' => 'Kernel::Output::HTML::DashboardTicketGeneric',

'Permission' => 'rw',

'Time' => 'Age',

'Title' => 'New Tickets'

};

6.15.4. DashboardBackend###0130-TicketOpen

Description: Parameters for the dashboard backend of the ticket pending reminder overview of the agent interface. "Limit" is the number of entries shown by default. "Group" is used to restrict the access to the plugin (e. g. Group: admin;group1;group2;). "Default" deter-

480

Group:

SubGroup:

Valid:

Required:

Config-Setting: mines if the plugin is enabled by default or if the user needs to enable it manually. "CacheTTLLocal" is the cache time in minutes for the plugin. Note: Only Ticket attributes and Dynamic Fields

(DynamicField_NameX) are allowed for DefaultColumns. Possible settings: 0 = Disabled, 1 = Available, 2 = Enabled by default.

Ticket

Frontend::Agent::Dashboard

$Self->{'DashboardBackend'}->{'0130-TicketOpen'} = {

'Attributes' => 'StateType=open;',

'Block' => 'ContentLarge',

'CacheTTLLocal' => '0.5',

'Default' => '1',

'DefaultColumns' => {

'Age' => '2',

'Changed' => '1',

'CustomerID' => '1',

'CustomerName' => '1',

'CustomerUserID' => '1',

'EscalationResponseTime' => '1',

'EscalationSolutionTime' => '1',

'EscalationTime' => '1',

'EscalationUpdateTime' => '1',

'Lock' => '1',

'Owner' => '1',

'PendingTime' => '1',

'Priority' => '1',

'Queue' => '1',

'Responsible' => '1',

'SLA' => '1',

'Service' => '1',

'State' => '1',

'TicketNumber' => '2',

'Title' => '2',

'Type' => '1'

'Description' => 'All open tickets, these tickets have already

been worked on, but need a response',

'Filter' => 'All',

'Group' => '',

'Limit' => '10',

'Module' => 'Kernel::Output::HTML::DashboardTicketGeneric',

'Permission' => 'rw',

'Time' => 'Age',

'Title' => 'Open Tickets / Need to be answered'

};

6.15.5. DashboardBackend###0250-TicketStats

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Parameters for the dashboard backend of the ticket stats of the agent interface. "Limit" is the number of entries shown by default. "Group" is used to restrict the access to the plugin (e. g.

Group: admin;group1;group2;). "Default" determines if the plugin is enabled by default or if the user needs to enable it manually.

"CacheTTLLocal" is the cache time in minutes for the plugin.

Ticket

Frontend::Agent::Dashboard

$Self->{'DashboardBackend'}->{'0250-TicketStats'} = {

481

'Block' => 'ContentSmall',

'CacheTTL' => '30',

'Changed' => '1',

'Closed' => '1',

'Default' => '1',

'Group' => '',

'Module' => 'Kernel::Output::HTML::DashboardTicketStatsGeneric',

'Permission' => 'rw',

'Title' => '7 Day Stats'

};

6.15.6. DashboardBackend###0260-TicketCalendar

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Parameters for the dashboard backend of the ticket calendar of the agent interface. "Limit" is the number of entries shown by default. "Group" is used to restrict the access to the plugin (e. g.

Group: admin;group1;group2;). "Default" determines if the plugin is enabled by default or if the user needs to enable it manually.

"CacheTTLLocal" is the cache time in minutes for the plugin.

Ticket

Frontend::Agent::Dashboard

$Self->{'DashboardBackend'}->{'0260-TicketCalendar'} = {

'Block' => 'ContentSmall',

'CacheTTL' => '2',

'Default' => '1',

'Group' => '',

'Limit' => '6',

'Module' => 'Kernel::Output::HTML::DashboardCalendar',

'OwnerOnly' => '',

'Permission' => 'rw',

'Title' => 'Upcoming Events'

};

6.15.7. DashboardBackend###0270-TicketQueueOverview

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Parameters for the dashboard backend of the queue overview widget of the agent interface. "Group" is used to restrict the access to the plugin (e. g. Group: admin;group1;group2;). "QueuePermissionGroup" is not mandatory, queues are only listed if they belong to this permission group if you enable it. "States" is a list of states, the key is the sort order of the state in the widget. "Default" determines if the plugin is enabled by default or if the user needs to enable it manually. "CacheTTLLocal" is the cache time in minutes for the plugin.

Ticket

Frontend::Agent::Dashboard

$Self->{'DashboardBackend'}->{'0270-TicketQueueOverview'} = {

'Block' => 'ContentLarge',

'CacheTTLLocal' => '0.5',

'Default' => '1',

'Description' => 'Provides a matrix overview of the tickets per

state per queue.',

'Group' => '',

482

'Module' => 'Kernel::Output::HTML::DashboardTicketQueueOverview',

'Permission' => 'rw',

'QueuePermissionGroup' => 'users',

'Sort' => 'SortBy=Age;OrderBy=Up',

'States' => {

'1' => 'new',

'4' => 'open',

'6' => 'pending reminder'

'Title' => 'Ticket Queue Overview'

};

6.15.8. DashboardBackend###0280-DashboardEventsTicketCalendar

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Parameters for the dashboard backend of the ticket stats of the agent interface. "Limit" is the number of entries shown by default. "Group" is used to restrict the access to the plugin (e. g.

Group: admin;group1;group2;). "Default" determines if the plugin is enabled by default or if the user needs to enable it manually.

"CacheTTLLocal" is the cache time in minutes for the plugin.

Ticket

Frontend::Agent::Dashboard

$Self->{'DashboardBackend'}->{'0280-DashboardEventsTicketCalendar'}

= {

'Block' => 'ContentLarge',

'CacheTTL' => '0',

'Default' => '0',

'Group' => '',

'Module' => 'Kernel::Output::HTML::DashboardEventsTicketCalendar',

'Title' => 'Events Ticket Calendar'

};

6.15.9.

AgentCustomerInformationCenter::Backend###0100-

CIC-TicketPendingReminder

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

(DynamicField_NameX) are allowed for DefaultColumns. Possible settings: 0 = Disabled, 1 = Available, 2 = Enabled by default.

Ticket

Frontend::Agent::Dashboard

$Self->{'AgentCustomerInformationCenter::Backend'}->{'0100-CIC-

TicketPendingReminder'} = {

'Attributes' => 'TicketPendingTimeOlderMinutes=1;StateType=pending

reminder;SortBy=PendingTime;OrderBy=Down;',

483

6.15.10.

AgentCustomerInformationCenter::Backend###0110-

CIC-TicketEscalation

Description:

'Block' => 'ContentLarge',

'CacheTTLLocal' => '0.5',

'Default' => '1',

'DefaultColumns' => {

'Age' => '2',

'Changed' => '1',

'CustomerID' => '1',

'CustomerName' => '1',

'CustomerUserID' => '1',

'EscalationResponseTime' => '1',

'EscalationSolutionTime' => '1',

'EscalationTime' => '1',

'EscalationUpdateTime' => '1',

'Lock' => '1',

'Owner' => '1',

'PendingTime' => '1',

'Priority' => '1',

'Queue' => '1',

'Responsible' => '1',

'SLA' => '1',

'Service' => '1',

'State' => '1',

'TicketNumber' => '2',

'Title' => '2',

'Type' => '1'

'Description' => 'All tickets with a reminder set where the

reminder date has been reached',

'Filter' => 'Locked',

'Group' => '',

'Limit' => '10',

'Module' => 'Kernel::Output::HTML::DashboardTicketGeneric',

'Permission' => 'ro',

'Time' => 'UntilTime',

'Title' => 'Reminder Tickets'

};

Group:

SubGroup:

Valid:

Required:

Config-Setting:

(DynamicField_NameX) are allowed for DefaultColumns. Possible settings: 0 = Disabled, 1 = Available, 2 = Enabled by default.

Ticket

Frontend::Agent::Dashboard

$Self->{'AgentCustomerInformationCenter::Backend'}->{'0110-CIC-

TicketEscalation'} = {

'Attributes' =>

'TicketEscalationTimeOlderMinutes=1;SortBy=EscalationTime;OrderBy=Down;',

'Block' => 'ContentLarge',

'CacheTTLLocal' => '0.5',

'Default' => '1',

'DefaultColumns' => {

'Age' => '2',

'Changed' => '1',

484

6.15.11.

AgentCustomerInformationCenter::Backend###0120-

CIC-TicketNew

Description:

'CustomerID' => '1',

'CustomerName' => '1',

'CustomerUserID' => '1',

'EscalationResponseTime' => '1',

'EscalationSolutionTime' => '1',

'EscalationTime' => '1',

'EscalationUpdateTime' => '1',

'Lock' => '1',

'Owner' => '1',

'PendingTime' => '1',

'Priority' => '1',

'Queue' => '1',

'Responsible' => '1',

'SLA' => '1',

'Service' => '1',

'State' => '1',

'TicketNumber' => '2',

'Title' => '2',

'Type' => '1'

'Description' => 'All escalated tickets',

'Filter' => 'All',

'Group' => '',

'Limit' => '10',

'Module' => 'Kernel::Output::HTML::DashboardTicketGeneric',

'Permission' => 'ro',

'Time' => 'EscalationTime',

'Title' => 'Escalated Tickets'

};

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Parameters for the dashboard backend of the new tickets overview of the agent interface. "Limit" is the number of entries shown by default. "Group" is used to restrict the access to the plugin (e. g.

Group: admin;group1;group2;). "Default" determines if the plugin is enabled by default or if the user needs to enable it manually.

"CacheTTLLocal" is the cache time in minutes for the plugin. Note:

Only Ticket attributes and Dynamic Fields (DynamicField_NameX) are allowed for DefaultColumns. Possible settings: 0 = Disabled, 1

= Available, 2 = Enabled by default.

Ticket

Frontend::Agent::Dashboard

$Self->{'AgentCustomerInformationCenter::Backend'}->{'0120-CIC-

TicketNew'} = {

'Attributes' => 'StateType=new;',

'Block' => 'ContentLarge',

'CacheTTLLocal' => '0.5',

'Default' => '1',

'DefaultColumns' => {

'Age' => '2',

'Changed' => '1',

'CustomerID' => '1',

'CustomerName' => '1',

'CustomerUserID' => '1',

'EscalationResponseTime' => '1',

'EscalationSolutionTime' => '1',

'EscalationTime' => '1',

'EscalationUpdateTime' => '1',

'Lock' => '1',

485

6.15.12.

AgentCustomerInformationCenter::Backend###0130-

CIC-TicketOpen

Description:

'Owner' => '1',

'PendingTime' => '1',

'Priority' => '1',

'Queue' => '1',

'Responsible' => '1',

'SLA' => '1',

'Service' => '1',

'State' => '1',

'TicketNumber' => '2',

'Title' => '2',

'Type' => '1'

'Description' => 'All new tickets, these tickets have not been

worked on yet',

'Filter' => 'All',

'Group' => '',

'Limit' => '10',

'Module' => 'Kernel::Output::HTML::DashboardTicketGeneric',

'Permission' => 'ro',

'Time' => 'Age',

'Title' => 'New Tickets'

};

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Parameters for the dashboard backend of the ticket pending reminder overview of the agent interface. "Limit" is the number of entries shown by default. "Group" is used to restrict the access to the plugin (e. g. Group: admin;group1;group2;). "Default" determines if the plugin is enabled by default or if the user needs to enable it manually. "CacheTTLLocal" is the cache time in minutes for the plugin. Note: Only Ticket attributes and Dynamic Fields

(DynamicField_NameX) are allowed for DefaultColumns. Possible settings: 0 = Disabled, 1 = Available, 2 = Enabled by default.

Ticket

Frontend::Agent::Dashboard

$Self->{'AgentCustomerInformationCenter::Backend'}->{'0130-CIC-

TicketOpen'} = {

'Attributes' => 'StateType=open;',

'Block' => 'ContentLarge',

'CacheTTLLocal' => '0.5',

'Default' => '1',

'DefaultColumns' => {

'Age' => '2',

'Changed' => '1',

'CustomerID' => '1',

'CustomerName' => '1',

'CustomerUserID' => '1',

'EscalationResponseTime' => '1',

'EscalationSolutionTime' => '1',

'EscalationTime' => '1',

'EscalationUpdateTime' => '1',

'Lock' => '1',

'Owner' => '1',

'PendingTime' => '1',

'Priority' => '1',

'Queue' => '1',

'Responsible' => '1',

'SLA' => '1',

'Service' => '1',

486

'State' => '1',

'TicketNumber' => '2',

'Title' => '2',

'Type' => '1'

'Description' => 'All open tickets, these tickets have already

been worked on, but need a response',

'Filter' => 'All',

'Group' => '',

'Limit' => '10',

'Module' => 'Kernel::Output::HTML::DashboardTicketGeneric',

'Permission' => 'ro',

'Time' => 'Age',

'Title' => 'Open Tickets / Need to be answered'

};

6.15.13.

AgentCustomerInformationCenter::Backend###0500-

CIC-CustomerIDStatus

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Parameters for the dashboard backend of the customer id status widget of the agent interface . "Group" is used to restrict the access to the plugin (e. g. Group: admin;group1;group2;).

"Default" determines if the plugin is enabled by default or if the user needs to enable it manually. "CacheTTLLocal" is the cache time in minutes for the plugin.

Ticket

Frontend::Agent::Dashboard

$Self->{'AgentCustomerInformationCenter::Backend'}->{'0500-CIC-

CustomerIDStatus'} = {

'Attributes' => '',

'Block' => 'ContentSmall',

'CacheTTLLocal' => '0.5',

'Default' => '1',

'Description' => 'Company Status',

'Group' => '',

'Module' => 'Kernel::Output::HTML::DashboardCustomerIDStatus',

'Permission' => 'ro',

'Title' => 'Company Status'

};

6.16.

Frontend::Agent::Dashboard::EventsTicketCalendar

6.16.1.

DashboardEventsTicketCalendar###CalendarWidth

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the calendar width in percent. Default is 95%.

Ticket

Frontend::Agent::Dashboard::EventsTicketCalendar

$Self->{'DashboardEventsTicketCalendar'}->{'CalendarWidth'} =

'95';

487

6.16.2. DashboardEventsTicketCalendar###Queues

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines queues that's tickets are used for displaying as calendar events.

Ticket

Frontend::Agent::Dashboard::EventsTicketCalendar

$Self->{'DashboardEventsTicketCalendar'}->{'Queues'} = [

'Raw'

];

6.16.3.

DashboardEventsTicketCalendar::DynamicFieldStartTime

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Define dynamic field name for start time. This field has to be manually added to the system as Ticket: "Date / Time" and must be activated in ticket creation screens and/or in any other ticket action screens.

Ticket

Frontend::Agent::Dashboard::EventsTicketCalendar

$Self->{'DashboardEventsTicketCalendar::DynamicFieldStartTime'} =

'TicketCalendarStartTime';

6.16.4.

DashboardEventsTicketCalendar::DynamicFieldEndTime

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Define dynamic field name for end time. This field has to be manually added to the system as Ticket: "Date / Time" and must be activated in ticket creation screens and/or in any other ticket action screens.

Ticket

Frontend::Agent::Dashboard::EventsTicketCalendar

$Self->{'DashboardEventsTicketCalendar::DynamicFieldEndTime'} =

'TicketCalendarEndTime';

6.16.5.

DashboardEventsTicketCalendar::DynamicFieldsForEvents

Description:

Group:

SubGroup:

Valid:

Required:

Defines the dynamic fields that are used for displaying on calendar events.

Ticket

Frontend::Agent::Dashboard::EventsTicketCalendar

488

Config-Setting:

$Self->{'DashboardEventsTicketCalendar::DynamicFieldsForEvents'} =

[

'TicketCalendarStartTime',

'TicketCalendarEndTime'

];

6.16.6.

DashboardEventsTicketCalendar::TicketFieldsForEvents

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the ticket fields that are going to be displayed calendar events. The "Key" defines the field or ticket attribute and the "Content" defines the display name.

Ticket

Frontend::Agent::Dashboard::EventsTicketCalendar

$Self->{'DashboardEventsTicketCalendar::TicketFieldsForEvents'} =

{

'CustomerID' => 'Customer ID',

'CustomerUserID' => 'Customer user',

'Priority' => 'Priority',

'Queue' => 'Queue',

'SLA' => 'SLA',

'Service' => 'Service',

'State' => 'State',

'Title' => 'Title',

'Type' => 'Type'

};

6.17.

Frontend::Agent::Dashboard::TicketFilters

6.17.1. OnlyValuesOnTicket

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines if the list for filters should be retrieve just from current tickets in system. Just for clarification, Customers list will always came from system's tickets.

Ticket

Frontend::Agent::Dashboard::TicketFilters

$Self->{'OnlyValuesOnTicket'} = '1';

6.18. Frontend::Agent::ModuleMetaHead

6.18.1. Frontend::HeaderMetaModule###2-TicketSearch

Description:

Group:

SubGroup:

Module to generate html OpenSearch profile for short ticket search in the agent interface.

Ticket

Frontend::Agent::ModuleMetaHead

489

Valid:

Required:

Config-Setting:

$Self->{'Frontend::HeaderMetaModule'}->{'2-TicketSearch'} = {

'Action' => 'AgentTicketSearch',

'Module' => 'Kernel::Output::HTML::HeaderMetaTicketSearch'

};

6.19. Frontend::Agent::ModuleNotify

6.19.1. Frontend::NotifyModule###5-

Ticket::TicketEscalation

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Module to show notifications and escalations (ShownMax: max.

shown escalations, EscalationInMinutes: Show ticket which will escalation in, CacheTime: Cache of calculated escalations in seconds).

Ticket

Frontend::Agent::ModuleNotify

$Self->{'Frontend::NotifyModule'}->{'5-Ticket::TicketEscalation'} =

{

'CacheTime' => '40',

'EscalationInMinutes' => '120',

'Module' =>

'Kernel::Output::HTML::NotificationAgentTicketEscalation',

'ShownMax' => '25'

};

6.20. Frontend::Agent::ModuleRegistration

6.20.1. Frontend::Module###AgentTicketQueue

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketQueue'} = {

'Description' => 'Overview of all open Tickets',

'Loader' => {

'CSS' => [

'Core.AgentTicketQueue.css',

'Core.AllocationList.css'

'JavaScript' => [

'Core.UI.AllocationList.js',

'Core.Agent.TableFilters.js'

]

'NavBar' => [

{

'AccessKey' => 'o',

'Block' => '',

'Description' => 'Overview of all open Tickets',

'Link' => 'Action=AgentTicketQueue',

'LinkOption' => '',

490

'Name' => 'Queue view',

'NavBar' => 'Ticket',

'Prio' => '100',

'Type' => ''

{

'AccessKey' => 't',

'Block' => 'ItemArea',

'Description' => '',

'Link' => 'Action=AgentTicketQueue',

'LinkOption' => '',

'Name' => 'Tickets',

'NavBar' => 'Ticket',

'Prio' => '200',

'Type' => 'Menu'

}

'NavBarName' => 'Ticket',

'Title' => 'QueueView'

};

6.20.2. Frontend::Module###AgentTicketPhone

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketPhone'} = {

'Description' => 'Create new phone ticket',

'Loader' => {

'JavaScript' => [

'Core.Agent.CustomerSearch.js',

'Core.Agent.TicketAction.js'

]

'NavBar' => [

{

'AccessKey' => 'n',

'Block' => '',

'Description' => 'Create new phone ticket (inbound)',

'Link' => 'Action=AgentTicketPhone',

'LinkOption' => '',

'Name' => 'New phone ticket',

'NavBar' => 'Ticket',

'Prio' => '200',

'Type' => ''

}

'NavBarName' => 'Ticket',

'Title' => 'New phone ticket'

};

6.20.3.

Frontend::Module###AgentTicketPhoneOutbound

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketPhoneOutbound'} = {

491

'Description' => 'Phone Call',

'Loader' => {

'JavaScript' => [

'Core.Agent.TicketAction.js'

]

'NavBarName' => 'Ticket',

'Title' => 'Phone-Ticket'

};

6.20.4.

Frontend::Module###AgentTicketPhoneInbound

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketPhoneInbound'} = {

'Description' => 'Incoming Phone Call',

'Loader' => {

'JavaScript' => [

'Core.Agent.TicketAction.js'

]

'NavBarName' => 'Ticket',

'Title' => 'Phone-Ticket'

};

6.20.5. Frontend::Module###AgentTicketEmail

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketEmail'} = {

'Description' => 'Create new email ticket',

'Loader' => {

'JavaScript' => [

'Core.Agent.CustomerSearch.js',

'Core.Agent.TicketAction.js'

]

'NavBar' => [

{

'AccessKey' => 'm',

'Block' => '',

'Description' => 'Create new email ticket and send this out

(outbound)',

'Link' => 'Action=AgentTicketEmail',

'LinkOption' => '',

'Name' => 'New email ticket',

'NavBar' => 'Ticket',

'Prio' => '210',

'Type' => ''

}

'NavBarName' => 'Ticket',

'Title' => 'New email ticket'

};

492

6.20.6. Frontend::Module###AgentTicketSearch

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketSearch'} = {

'Description' => 'Search Ticket',

'Loader' => {

'JavaScript' => [

'Core.UI.AllocationList.js',

'Core.Agent.TableFilters.js'

]

'NavBar' => [

{

'AccessKey' => 's',

'Block' => '',

'Description' => 'Search Tickets',

'Link' => 'Action=AgentTicketSearch',

'LinkOption' => 'onclick="window.setTimeout(function()

{Core.Agent.Search.OpenSearchDialog(\'AgentTicketSearch\');}, 0);

return false;"',

'Name' => 'Search',

'NavBar' => 'Ticket',

'Prio' => '300',

'Type' => ''

}

'NavBarName' => 'Ticket',

'Title' => 'Search'

};

6.20.7. Frontend::Module###AgentTicketLockedView

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketLockedView'} = {

'Description' => 'Locked Tickets',

'Loader' => {

'CSS' => [

'Core.AgentTicketQueue.css',

'Core.AllocationList.css'

'JavaScript' => [

'Core.UI.AllocationList.js',

'Core.Agent.TableFilters.js'

]

'NavBarName' => 'Ticket',

'Title' => 'Locked Tickets'

};

6.20.8.

Frontend::Module###AgentTicketResponsibleView

Description: Frontend module registration for the agent interface.

493

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketResponsibleView'} = {

'Description' => 'Responsible Tickets',

'Loader' => {

'CSS' => [

'Core.AllocationList.css'

'JavaScript' => [

'Core.UI.AllocationList.js',

'Core.Agent.TableFilters.js'

]

'NavBarName' => 'Ticket',

'Title' => 'Responsible Tickets'

};

6.20.9. Frontend::Module###AgentTicketWatchView

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketWatchView'} = {

'Description' => 'Watched Tickets',

'Loader' => {

'CSS' => [

'Core.AgentTicketQueue.css',

'Core.AllocationList.css'

'JavaScript' => [

'Core.UI.AllocationList.js',

'Core.Agent.TableFilters.js'

]

'NavBarName' => 'Ticket',

'Title' => 'Watched Tickets'

};

6.20.10. Frontend::Module###AgentCustomerSearch

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentCustomerSearch'} = {

'Description' => 'AgentCustomerSearch',

'NavBarName' => 'Ticket',

'Title' => 'AgentCustomerSearch'

};

6.20.11. Frontend::Module###AgentUserSearch

Description: Frontend module registration for the agent interface.

494

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentUserSearch'} = {

'Description' => 'AgentUserSearch',

'NavBarName' => 'Ticket',

'Title' => 'AgentUserSearch'

};

6.20.12. Frontend::Module###AgentTicketStatusView

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketStatusView'} = {

'Description' => 'Overview of all open tickets',

'Loader' => {

'CSS' => [

'Core.AllocationList.css'

'JavaScript' => [

'Core.UI.AllocationList.js',

'Core.Agent.TableFilters.js'

]

'NavBar' => [

{

'AccessKey' => 'v',

'Block' => '',

'Description' => 'Overview of all open Tickets.',

'Link' => 'Action=AgentTicketStatusView',

'LinkOption' => '',

'Name' => 'Status view',

'NavBar' => 'Ticket',

'Prio' => '110',

'Type' => ''

}

'NavBarName' => 'Ticket',

'Title' => 'Status view'

};

6.20.13.

Frontend::Module###AgentTicketEscalationView

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketEscalationView'} = {

'Description' => 'Overview of all escalated tickets',

'Loader' => {

'CSS' => [

'Core.AllocationList.css'

495

'JavaScript' => [

'Core.UI.AllocationList.js',

'Core.Agent.TableFilters.js'

]

'NavBar' => [

{

'AccessKey' => 'e',

'Block' => '',

'Description' => 'Overview Escalated Tickets',

'Link' => 'Action=AgentTicketEscalationView',

'LinkOption' => '',

'Name' => 'Escalation view',

'NavBar' => 'Ticket',

'Prio' => '120',

'Type' => ''

}

'NavBarName' => 'Ticket',

'Title' => 'Escalation view'

};

6.20.14. Frontend::Module###AgentZoom

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentZoom'} = {

'Description' => 'compat module for AgentZoom to AgentTicketZoom',

'NavBarName' => 'Ticket',

'Title' => ''

};

6.20.15. Frontend::Module###AgentTicketZoom

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketZoom'} = {

'Description' => 'Ticket Zoom',

'Loader' => {

'CSS' => [

'Core.Agent.TicketProcess.css'

'JavaScript' => [

'thirdparty/jquery-tablesorter-2.0.5/jquery.tablesorter.js',

'Core.UI.Table.Sort.js',

'Core.Agent.TicketZoom.js'

]

'NavBarName' => 'Ticket',

'Title' => 'Zoom'

};

6.20.16. Frontend::Module###AgentTicketAttachment

Description: Frontend module registration for the agent interface.

496

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketAttachment'} = {

'Description' => 'To download attachments',

'NavBarName' => 'Ticket',

'Title' => ''

};

6.20.17. Frontend::Module###AgentTicketPlain

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketPlain'} = {

'Description' => 'Ticket plain view of an email',

'NavBarName' => 'Ticket',

'Title' => 'Plain'

};

6.20.18. Frontend::Module###AgentTicketNote

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketNote'} = {

'Description' => 'Ticket Note',

'Loader' => {

'JavaScript' => [

'Core.Agent.TicketAction.js'

]

'NavBarName' => 'Ticket',

'Title' => 'Note'

};

6.20.19. Frontend::Module###AgentTicketMerge

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketMerge'} = {

'Description' => 'Ticket Merge',

'NavBarName' => 'Ticket',

'Title' => 'Merge'

};

497

6.20.20. Frontend::Module###AgentTicketPending

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketPending'} = {

'Description' => 'Ticket Pending',

'Loader' => {

'JavaScript' => [

'Core.Agent.TicketAction.js'

]

'NavBarName' => 'Ticket',

'Title' => 'Pending'

};

6.20.21. Frontend::Module###AgentTicketWatcher

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketWatcher'} = {

'Description' => 'A TicketWatcher Module',

'NavBarName' => 'Ticket-Watcher',

'Title' => 'Ticket-Watcher'

};

6.20.22. Frontend::Module###AgentTicketPriority

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketPriority'} = {

'Description' => 'Ticket Priority',

'Loader' => {

'JavaScript' => [

'Core.Agent.TicketAction.js'

]

'NavBarName' => 'Ticket',

'Title' => 'Priority'

};

6.20.23. Frontend::Module###AgentTicketLock

Description:

Group:

SubGroup:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

498

Valid:

Required:

Config-Setting:

$Self->{'Frontend::Module'}->{'AgentTicketLock'} = {

'Description' => 'Ticket Lock',

'NavBarName' => 'Ticket',

'Title' => 'Lock'

};

6.20.24. Frontend::Module###AgentTicketMove

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketMove'} = {

'Description' => 'Ticket Move',

'Loader' => {

'JavaScript' => [

'Core.Agent.TicketAction.js'

]

'NavBarName' => 'Ticket',

'Title' => 'Move'

};

6.20.25. Frontend::Module###AgentTicketHistory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketHistory'} = {

'Description' => 'Ticket History',

'NavBarName' => 'Ticket',

'Title' => 'History'

};

6.20.26. Frontend::Module###AgentTicketOwner

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketOwner'} = {

'Description' => 'Ticket Owner',

'Loader' => {

'JavaScript' => [

'Core.Agent.TicketAction.js'

]

'NavBarName' => 'Ticket',

'Title' => 'Owner'

};

499

6.20.27. Frontend::Module###AgentTicketResponsible

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketResponsible'} = {

'Description' => 'Ticket Responsible',

'Loader' => {

'JavaScript' => [

'Core.Agent.TicketAction.js'

]

'NavBarName' => 'Ticket',

'Title' => 'Responsible'

};

6.20.28. Frontend::Module###AgentTicketCompose

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketCompose'} = {

'Description' => 'Ticket Compose email Answer',

'Loader' => {

'JavaScript' => [

'Core.Agent.CustomerSearch.js',

'Core.Agent.TicketAction.js'

]

'NavBarName' => 'Ticket',

'Title' => 'Compose'

};

6.20.29. Frontend::Module###AgentTicketBounce

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketBounce'} = {

'Description' => 'Ticket Compose Bounce Email',

'NavBarName' => 'Ticket',

'Title' => 'Bounce'

};

6.20.30. Frontend::Module###AgentTicketForward

Description:

Group:

SubGroup:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

500

Valid:

Required:

Config-Setting:

$Self->{'Frontend::Module'}->{'AgentTicketForward'} = {

'Description' => 'Ticket Forward Email',

'Loader' => {

'JavaScript' => [

'Core.Agent.CustomerSearch.js',

'Core.Agent.TicketAction.js'

]

'NavBarName' => 'Ticket',

'Title' => 'Forward'

};

6.20.31. Frontend::Module###AgentTicketCustomer

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketCustomer'} = {

'Description' => 'Ticket Customer',

'Loader' => {

'JavaScript' => [

'Core.Agent.CustomerSearch.js',

'Core.Agent.TicketAction.js'

]

'NavBarName' => 'Ticket',

'Title' => 'Customer'

};

6.20.32. Frontend::Module###AgentTicketClose

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketClose'} = {

'Description' => 'Ticket Close',

'Loader' => {

'JavaScript' => [

'Core.Agent.TicketAction.js'

]

'NavBarName' => 'Ticket',

'Title' => 'Close'

};

6.20.33. Frontend::Module###AgentTicketFreeText

Description:

Group:

SubGroup:

Valid:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

501

Required:

Config-Setting:

$Self->{'Frontend::Module'}->{'AgentTicketFreeText'} = {

'Description' => 'Ticket FreeText',

'Loader' => {

'JavaScript' => [

'Core.Agent.TicketAction.js'

]

'NavBarName' => 'Ticket',

'Title' => 'Free Fields'

};

6.20.34. Frontend::Module###AgentTicketPrint

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketPrint'} = {

'Description' => 'Ticket Print',

'NavBarName' => 'Ticket',

'Title' => 'Print'

};

6.20.35. Frontend::Module###AgentTicketBulk

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the agent interface.

Ticket

Frontend::Agent::ModuleRegistration

$Self->{'Frontend::Module'}->{'AgentTicketBulk'} = {

'Description' => 'Ticket bulk module',

'Loader' => {

'JavaScript' => [

'Core.Agent.TicketAction.js'

]

'NavBarName' => 'Ticket',

'Title' => 'Bulk-Action'

};

6.21. Frontend::Agent::Preferences

6.21.1. PreferencesGroups###NewTicketNotify

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Parameters for the NewTicketNotify object in the preferences view of the agent interface.

Ticket

Frontend::Agent::Preferences

$Self->{'PreferencesGroups'}->{'NewTicketNotify'} = {

'Active' => '1',

502

'Column' => 'Email Settings',

'Data' => {

'0' => 'No',

'1' => 'Yes'

'DataSelected' => '0',

'Desc' => 'Send me a notification if there is a new ticket in "My

Queues".',

'Key' => 'Send new ticket notifications',

'Label' => 'New ticket notification',

'Module' => 'Kernel::Output::HTML::PreferencesGeneric',

'PrefKey' => 'UserSendNewTicketNotification',

'Prio' => '1000'

};

6.21.2. PreferencesGroups###FollowUpNotify

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Parameters for the FollowUpNotify object in the preference view of the agent interface.

Ticket

Frontend::Agent::Preferences

$Self->{'PreferencesGroups'}->{'FollowUpNotify'} = {

'Active' => '1',

'Column' => 'Email Settings',

'Data' => {

'0' => 'No',

'1' => 'Yes'

'DataSelected' => '0',

'Desc' => 'Send me a notification if a customer sends a follow up

and I\'m the owner of the ticket or the ticket is unlocked and is

in one of my subscribed queues.',

'Key' => 'Send ticket follow up notifications',

'Label' => 'Ticket follow up notification',

'Module' => 'Kernel::Output::HTML::PreferencesGeneric',

'PrefKey' => 'UserSendFollowUpNotification',

'Prio' => '2000'

};

6.21.3. PreferencesGroups###LockTimeoutNotify

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Parameters for the LockTimeoutNotify object in the preference view of the agent interface.

Ticket

Frontend::Agent::Preferences

$Self->{'PreferencesGroups'}->{'LockTimeoutNotify'} = {

'Active' => '1',

'Column' => 'Email Settings',

'Data' => {

'0' => 'No',

'1' => 'Yes'

'DataSelected' => '0',

'Desc' => 'Send me a notification if a ticket is unlocked by the

system.',

'Key' => 'Send ticket lock timeout notifications',

'Label' => 'Ticket lock timeout notification',

'Module' => 'Kernel::Output::HTML::PreferencesGeneric',

503

'PrefKey' => 'UserSendLockTimeoutNotification',

'Prio' => '3000'

};

6.21.4. PreferencesGroups###MoveNotify

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Parameters for the MoveNotify object in the preference view of the agent interface.

Ticket

Frontend::Agent::Preferences

$Self->{'PreferencesGroups'}->{'MoveNotify'} = {

'Active' => '1',

'Column' => 'Email Settings',

'Data' => {

'0' => 'No',

'1' => 'Yes'

'DataSelected' => '0',

'Desc' => 'Send me a notification if a ticket is moved into one of

"My Queues".',

'Key' => 'Send ticket move notifications',

'Label' => 'Ticket move notification',

'Module' => 'Kernel::Output::HTML::PreferencesGeneric',

'PrefKey' => 'UserSendMoveNotification',

'Prio' => '4000'

};

6.21.5. PreferencesGroups###WatcherNotify

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Parameters for the WatcherNotify object in the preference view of the agent interface.

Ticket

Frontend::Agent::Preferences

$Self->{'PreferencesGroups'}->{'WatcherNotify'} = {

'Active' => '1',

'Column' => 'Email Settings',

'Data' => {

'0' => 'No',

'1' => 'Yes'

'DataSelected' => '0',

'Desc' => 'Send me the same notifications for my watched tickets

that the ticket owners will get.',

'Key' => 'Send ticket watch notifications',

'Label' => 'Ticket watch notification',

'Module' => 'Kernel::Output::HTML::PreferencesTicketWatcher',

'PrefKey' => 'UserSendWatcherNotification',

'Prio' => '5000'

};

6.21.6. PreferencesGroups###CustomQueue

Description:

Group:

Parameters for the CustomQueue object in the preference view of the agent interface.

Ticket

504

SubGroup:

Valid:

Required:

Config-Setting:

Frontend::Agent::Preferences

$Self->{'PreferencesGroups'}->{'CustomQueue'} = {

'Active' => '1',

'Column' => 'Other Settings',

'Desc' => 'Your queue selection of your favorite queues. You also

get notified about those queues via email if enabled.',

'Key' => 'My Queues',

'Label' => 'My Queues',

'Module' => 'Kernel::Output::HTML::PreferencesCustomQueue',

'Permission' => 'ro',

'Prio' => '1000'

};

6.21.7. PreferencesGroups###RefreshTime

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Parameters for the RefreshTime object in the preference view of the agent interface.

Ticket

Frontend::Agent::Preferences

$Self->{'PreferencesGroups'}->{'RefreshTime'} = {

'Active' => '1',

'Column' => 'Other Settings',

'Data' => {

'0' => 'off',

'10' => '10 minutes',

'15' => '15 minutes',

'2' => ' 2 minutes',

'5' => ' 5 minutes',

'7' => ' 7 minutes'

'DataSelected' => '0',

'Desc' => 'If enabled, the different overviews (Dashboard,

LockedView, QueueView) will automatically refresh after the

specified time.',

'Key' => 'Refresh Overviews after',

'Label' => 'Overview Refresh Time',

'Module' => 'Kernel::Output::HTML::PreferencesGeneric',

'PrefKey' => 'UserRefreshTime',

'Prio' => '2000'

};

6.21.8.

PreferencesGroups###TicketOverviewSmallPageShown

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Parameters for the pages (in which the tickets are shown) of the small ticket overview.

Ticket

Frontend::Agent::Preferences

$Self->{'PreferencesGroups'}->{'TicketOverviewSmallPageShown'} = {

'Active' => '0',

'Column' => 'Other Settings',

'Data' => {

'10' => '10',

505

'15' => '15',

'20' => '20',

'25' => '25',

'30' => '30',

'35' => '35'

'DataSelected' => '25',

'Key' => 'Ticket limit per page for Ticket Overview "Small"',

'Label' => 'Ticket Overview "Small" Limit',

'Module' => 'Kernel::Output::HTML::PreferencesGeneric',

'PrefKey' => 'UserTicketOverviewSmallPageShown',

'Prio' => '8000'

};

6.21.9.

PreferencesGroups###TicketOverviewFilterSettings

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Parameters for .

Ticket

Frontend::Agent::Preferences

$Self->{'PreferencesGroups'}->{'TicketOverviewFilterSettings'} = {

'Active' => '0',

'Column' => 'Other Settings',

'Key' => 'Column ticket filters for Ticket Overviews type

"Small".',

'Label' => 'Enabled filters.',

'Module' => 'Kernel::Output::HTML::PreferencesColumnFilters',

'PrefKey' => 'UserFilterColumnsEnabled',

'Prio' => '8100'

};

6.21.10.

PreferencesGroups###TicketOverviewMediumPageShown

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Parameters for the pages (in which the tickets are shown) of the medium ticket overview.

Ticket

Frontend::Agent::Preferences

$Self->{'PreferencesGroups'}->{'TicketOverviewMediumPageShown'} =

{

'Active' => '0',

'Column' => 'Other Settings',

'Data' => {

'10' => '10',

'15' => '15',

'20' => '20',

'25' => '25',

'30' => '30',

'35' => '35'

'DataSelected' => '20',

'Key' => 'Ticket limit per page for Ticket Overview "Medium"',

'Label' => 'Ticket Overview "Medium" Limit',

'Module' => 'Kernel::Output::HTML::PreferencesGeneric',

'PrefKey' => 'UserTicketOverviewMediumPageShown',

'Prio' => '8100'

};

506

6.21.11.

PreferencesGroups###TicketOverviewPreviewPageShown

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Parameters for the pages (in which the tickets are shown) of the ticket preview overview.

Ticket

Frontend::Agent::Preferences

$Self->{'PreferencesGroups'}->{'TicketOverviewPreviewPageShown'} =

{

'Active' => '0',

'Column' => 'Other Settings',

'Data' => {

'10' => '10',

'15' => '15',

'20' => '20',

'25' => '25',

'30' => '30',

'35' => '35'

'DataSelected' => '15',

'Key' => 'Ticket limit per page for Ticket Overview "Preview"',

'Label' => 'Ticket Overview "Preview" Limit',

'Module' => 'Kernel::Output::HTML::PreferencesGeneric',

'PrefKey' => 'UserTicketOverviewPreviewPageShown',

'Prio' => '8200'

};

6.21.12. PreferencesGroups###CreateNextMask

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Parameters for the CreateNextMask object in the preference view of the agent interface.

Ticket

Frontend::Agent::Preferences

$Self->{'PreferencesGroups'}->{'CreateNextMask'} = {

'Active' => '1',

'Column' => 'Other Settings',

'Data' => {

'' => 'CreateTicket',

'AgentTicketZoom' => 'TicketZoom'

'DataSelected' => '',

'Key' => 'Show this screen after I created a new ticket',

'Label' => 'Screen after new ticket',

'Module' => 'Kernel::Output::HTML::PreferencesGeneric',

'PrefKey' => 'UserCreateNextMask',

'Prio' => '3000'

};

6.22. Frontend::Agent::SearchRouter

6.22.1.

Frontend::Search###AgentCustomerInformationCenter

Description: Search backend router.

507

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Agent::SearchRouter

$Self->{'Frontend::Search'}->{'AgentCustomerInformationCenter'} =

{

'^AgentCustomerInformationCenter' =>

'Action=AgentCustomerInformationCenterSearch'

};

6.22.2. Frontend::Search###Ticket

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Search backend router.

Ticket

Frontend::Agent::SearchRouter

$Self->{'Frontend::Search'}->{'Ticket'} = {

'^AgentTicket' => 'Action=AgentTicketSearch;Subaction=AJAX'

};

6.23.

Frontend::Agent::Ticket::ArticleAttachmentModule

6.23.1.

Ticket::Frontend::ArticleAttachmentModule###1-

Download

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a link to download article attachments in the zoom view of the article in the agent interface.

Ticket

Frontend::Agent::Ticket::ArticleAttachmentModule

$Self->{'Ticket::Frontend::ArticleAttachmentModule'}->{'1-

Download'} = {

'Module' => 'Kernel::Output::HTML::ArticleAttachmentDownload'

};

6.23.2.

Ticket::Frontend::ArticleAttachmentModule###2-

HTML-Viewer

Description:

Group:

SubGroup:

Valid:

Shows a link to access article attachments via a html online viewer in the zoom view of the article in the agent interface.

Ticket

Frontend::Agent::Ticket::ArticleAttachmentModule

508

Required:

Config-Setting:

$Self->{'Ticket::Frontend::ArticleAttachmentModule'}->{'2-HTML-

Viewer'} = {

'Module' => 'Kernel::Output::HTML::ArticleAttachmentHTMLViewer'

};

6.24.

Frontend::Agent::Ticket::ArticleComposeModule

6.24.1. Ticket::Frontend::ArticleComposeModule###1-

SignEmail

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Module to compose signed messages (PGP or S/MIME).

Ticket

Frontend::Agent::Ticket::ArticleComposeModule

$Self->{'Ticket::Frontend::ArticleComposeModule'}->{'1-SignEmail'}

= {

'Module' => 'Kernel::Output::HTML::ArticleComposeSign'

};

6.24.2. Ticket::Frontend::ArticleComposeModule###2-

CryptEmail

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Module to crypt composed messages (PGP or S/MIME).

Ticket

Frontend::Agent::Ticket::ArticleComposeModule

$Self->{'Ticket::Frontend::ArticleComposeModule'}->{'2-CryptEmail'}

= {

'Module' => 'Kernel::Output::HTML::ArticleComposeCrypt'

};

6.25.

Frontend::Agent::Ticket::ArticleViewModule

6.25.1. Ticket::Frontend::ArticleViewModule###1-PGP

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Agent interface article notification module to check PGP.

Ticket

Frontend::Agent::Ticket::ArticleViewModule

$Self->{'Ticket::Frontend::ArticleViewModule'}->{'1-PGP'} = {

'Module' => 'Kernel::Output::HTML::ArticleCheckPGP'

};

509

6.25.2. Ticket::Frontend::ArticleViewModule###1-SMI-

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Agent interface module to check incoming emails in the Ticket-

Zoom-View if the S/MIME-key is available and true.

Ticket

Frontend::Agent::Ticket::ArticleViewModule

$Self->{'Ticket::Frontend::ArticleViewModule'}->{'1-SMIME'} = {

'Module' => 'Kernel::Output::HTML::ArticleCheckSMIME'

};

6.26.

Frontend::Agent::Ticket::ArticleViewModulePre

6.26.1. Ticket::Frontend::ArticlePreViewModule###1-

PGP

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Agent interface article notification module to check PGP.

Ticket

Frontend::Agent::Ticket::ArticleViewModulePre

$Self->{'Ticket::Frontend::ArticlePreViewModule'}->{'1-PGP'} = {

'Module' => 'Kernel::Output::HTML::ArticleCheckPGP'

};

6.26.2. Ticket::Frontend::ArticlePreViewModule###1-

SMIME

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Agent interface article notification module to check S/MIME.

Ticket

Frontend::Agent::Ticket::ArticleViewModulePre

$Self->{'Ticket::Frontend::ArticlePreViewModule'}->{'1-SMIME'} = {

'Module' => 'Kernel::Output::HTML::ArticleCheckSMIME'

};

6.27. Frontend::Agent::Ticket::MenuModule

6.27.1. Ticket::Frontend::MenuModule###000-Back

Description:

Group:

SubGroup:

Shows a link in the menu to go back in the ticket zoom view of the agent interface.

Ticket

Frontend::Agent::Ticket::MenuModule

510

Valid:

Required:

Config-Setting:

$Self->{'Ticket::Frontend::MenuModule'}->{'000-Back'} = {

'Action' => '',

'Description' => 'Back',

'Link' => '$Env{"LastScreenOverview"};TicketID=

$QData{"TicketID"}',

'Module' => 'Kernel::Output::HTML::TicketMenuGeneric',

'Name' => 'Back',

'PopupType' => '',

'Target' => ''

};

6.27.2. Ticket::Frontend::MenuModule###100-Lock

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a link in the menu to lock/unlock tickets in the ticket zoom view of the agent interface.

Ticket

Frontend::Agent::Ticket::MenuModule

$Self->{'Ticket::Frontend::MenuModule'}->{'100-Lock'} = {

'Action' => 'AgentTicketLock',

'Module' => 'Kernel::Output::HTML::TicketMenuLock',

'Name' => 'Lock',

'Target' => ''

};

6.27.3. Ticket::Frontend::MenuModule###200-History

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a link in the menu to access the history of a ticket in the ticket zoom view of the agent interface.

Ticket

Frontend::Agent::Ticket::MenuModule

$Self->{'Ticket::Frontend::MenuModule'}->{'200-History'} = {

'Action' => 'AgentTicketHistory',

'Description' => 'Show the ticket history',

'Link' => 'Action=AgentTicketHistory;TicketID=$QData{"TicketID"}',

'Module' => 'Kernel::Output::HTML::TicketMenuGeneric',

'Name' => 'History',

'PopupType' => 'TicketHistory',

'Target' => ''

};

6.27.4. Ticket::Frontend::MenuModule###210-Print

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a link in the menu to print a ticket or an article in the ticket zoom view of the agent interface.

Ticket

Frontend::Agent::Ticket::MenuModule

$Self->{'Ticket::Frontend::MenuModule'}->{'210-Print'} = {

511

'Action' => 'AgentTicketPrint',

'Description' => 'Print this ticket',

'Link' => 'Action=AgentTicketPrint;TicketID=$QData{"TicketID"}',

'LinkParam' => 'target="print"',

'Module' => 'Kernel::Output::HTML::TicketMenuGeneric',

'Name' => 'Print',

'PopupType' => 'TicketAction',

'Target' => ''

};

6.27.5. Ticket::Frontend::MenuModule###300-Priority

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a link in the menu to see the priority of a ticket in the ticket zoom view of the agent interface.

Ticket

Frontend::Agent::Ticket::MenuModule

$Self->{'Ticket::Frontend::MenuModule'}->{'300-Priority'} = {

'Action' => 'AgentTicketPriority',

'Description' => 'Change the ticket priority',

'Link' => 'Action=AgentTicketPriority;TicketID=

$QData{"TicketID"}',

'Module' => 'Kernel::Output::HTML::TicketMenuGeneric',

'Name' => 'Priority',

'PopupType' => 'TicketAction',

'Target' => ''

};

6.27.6. Ticket::Frontend::MenuModule###310-Free-

Text

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a link in the menu to add a free text field in the ticket zoom view of the agent interface.

Ticket

Frontend::Agent::Ticket::MenuModule

$Self->{'Ticket::Frontend::MenuModule'}->{'310-FreeText'} = {

'Action' => 'AgentTicketFreeText',

'Description' => 'Change the free fields for this ticket',

'Link' => 'Action=AgentTicketFreeText;TicketID=

$QData{"TicketID"}',

'Module' => 'Kernel::Output::HTML::TicketMenuGeneric',

'Name' => 'Free Fields',

'PopupType' => 'TicketAction',

'Target' => ''

};

6.27.7. Ticket::Frontend::MenuModule###320-Link

Description:

Group:

SubGroup:

Valid:

Required:

Shows a link in the menu that allows linking a ticket with another object in the ticket zoom view of the agent interface.

Ticket

Frontend::Agent::Ticket::MenuModule

512

Config-Setting:

$Self->{'Ticket::Frontend::MenuModule'}->{'320-Link'} = {

'Action' => 'AgentLinkObject',

'Description' => 'Link this ticket to other objects',

'Link' => 'Action=AgentLinkObject;SourceObject=Ticket;SourceKey=

$QData{"TicketID"}',

'Module' => 'Kernel::Output::HTML::TicketMenuGeneric',

'Name' => 'Link',

'PopupType' => 'TicketAction',

'Target' => ''

};

6.27.8. Ticket::Frontend::MenuModule###400-Owner

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a link in the menu to see the owner of a ticket in the ticket zoom view of the agent interface.

Ticket

Frontend::Agent::Ticket::MenuModule

$Self->{'Ticket::Frontend::MenuModule'}->{'400-Owner'} = {

'Action' => 'AgentTicketOwner',

'Description' => 'Change the owner for this ticket',

'Link' => 'Action=AgentTicketOwner;TicketID=$QData{"TicketID"}',

'Module' => 'Kernel::Output::HTML::TicketMenuGeneric',

'Name' => 'Owner',

'PopupType' => 'TicketAction',

'Target' => ''

};

6.27.9. Ticket::Frontend::MenuModule###410-Responsible

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a link in the menu to see the responsible agent of a ticket in the ticket zoom view of the agent interface.

Ticket

Frontend::Agent::Ticket::MenuModule

$Self->{'Ticket::Frontend::MenuModule'}->{'410-Responsible'} = {

'Action' => 'AgentTicketResponsible',

'Description' => 'Change the responsible person for this ticket',

'Link' => 'Action=AgentTicketResponsible;TicketID=

$QData{"TicketID"}',

'Module' => 'Kernel::Output::HTML::TicketMenuResponsible',

'Name' => 'Responsible',

'PopupType' => 'TicketAction',

'Target' => ''

};

6.27.10. Ticket::Frontend::MenuModule###420-Customer

Description:

Group:

SubGroup:

Shows a link in the menu to see the customer who requested the ticket in the ticket zoom view of the agent interface.

Ticket

Frontend::Agent::Ticket::MenuModule

513

Valid:

Required:

Config-Setting:

$Self->{'Ticket::Frontend::MenuModule'}->{'420-Customer'} = {

'Action' => 'AgentTicketCustomer',

'Description' => 'Change the customer for this ticket',

'Link' => 'Action=AgentTicketCustomer;TicketID=

$QData{"TicketID"}',

'Module' => 'Kernel::Output::HTML::TicketMenuGeneric',

'Name' => 'Customer',

'PopupType' => 'TicketAction',

'Target' => ''

};

6.27.11. Ticket::Frontend::MenuModule###420-Note

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a link in the menu to add a note in the ticket zoom view of the agent interface.

Ticket

Frontend::Agent::Ticket::MenuModule

$Self->{'Ticket::Frontend::MenuModule'}->{'420-Note'} = {

'Action' => 'AgentTicketNote',

'Description' => 'Add a note to this ticket',

'Link' => 'Action=AgentTicketNote;TicketID=$QData{"TicketID"}',

'Module' => 'Kernel::Output::HTML::TicketMenuGeneric',

'Name' => 'Note',

'PopupType' => 'TicketAction',

'Target' => ''

};

6.27.12. Ticket::Frontend::MenuModule###425-Phone

Call Outbound

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a link in the menu to add a note in the ticket zoom view of the agent interface.

Ticket

Frontend::Agent::Ticket::MenuModule

$Self->{'Ticket::Frontend::MenuModule'}->{'425-Phone Call

Outbound'} = {

'Action' => 'AgentTicketPhoneOutbound',

'Description' => 'Phone Call Outbound',

'Link' => 'Action=AgentTicketPhoneOutbound;TicketID=

$QData{"TicketID"}',

'Module' => 'Kernel::Output::HTML::TicketMenuGeneric',

'Name' => 'Phone Call Outbound',

'PopupType' => 'TicketAction',

'Target' => ''

};

6.27.13. Ticket::Frontend::MenuModule###426-Phone

Call Inbound

Description: Shows a link in the menu to add a note in the ticket zoom view of the agent interface.

514

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Agent::Ticket::MenuModule

$Self->{'Ticket::Frontend::MenuModule'}->{'426-Phone Call Inbound'}

= {

'Action' => 'AgentTicketPhoneInbound',

'Description' => 'Phone Call Inbound',

'Link' => 'Action=AgentTicketPhoneInbound;TicketID=

$QData{"TicketID"}',

'Module' => 'Kernel::Output::HTML::TicketMenuGeneric',

'Name' => 'Phone Call Inbound',

'PopupType' => 'TicketAction',

'Target' => ''

};

6.27.14. Ticket::Frontend::MenuModule###430-Merge

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a link in the menu that allows merging tickets in the ticket zoom view of the agent interface.

Ticket

Frontend::Agent::Ticket::MenuModule

$Self->{'Ticket::Frontend::MenuModule'}->{'430-Merge'} = {

'Action' => 'AgentTicketMerge',

'Description' => 'Merge into a different ticket',

'Link' => 'Action=AgentTicketMerge;TicketID=$QData{"TicketID"}',

'Module' => 'Kernel::Output::HTML::TicketMenuGeneric',

'Name' => 'Merge',

'PopupType' => 'TicketAction',

'Target' => ''

};

6.27.15. Ticket::Frontend::MenuModule###440-Pending

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a link in the menu to set a ticket as pending in the ticket zoom view of the agent interface.

Ticket

Frontend::Agent::Ticket::MenuModule

$Self->{'Ticket::Frontend::MenuModule'}->{'440-Pending'} = {

'Action' => 'AgentTicketPending',

'Description' => 'Set this ticket to pending',

'Link' => 'Action=AgentTicketPending;TicketID=$QData{"TicketID"}',

'Module' => 'Kernel::Output::HTML::TicketMenuGeneric',

'Name' => 'Pending',

'PopupType' => 'TicketAction',

'Target' => ''

};

6.27.16. Ticket::Frontend::MenuModule###448-Watch

Description: Shows a link in the menu for subscribing / unsubscribing from a ticket in the ticket zoom view of the agent interface.

515

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Agent::Ticket::MenuModule

$Self->{'Ticket::Frontend::MenuModule'}->{'448-Watch'} = {

'Action' => 'AgentTicketWatcher',

'Module' => 'Kernel::Output::HTML::TicketMenuTicketWatcher',

'Name' => 'Watch',

'Target' => ''

};

6.27.17. Ticket::Frontend::MenuModule###450-Close

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a link in the menu to close a ticket in the ticket zoom view of the agent interface.

Ticket

Frontend::Agent::Ticket::MenuModule

$Self->{'Ticket::Frontend::MenuModule'}->{'450-Close'} = {

'Action' => 'AgentTicketClose',

'Description' => 'Close this ticket',

'Link' => 'Action=AgentTicketClose;TicketID=$QData{"TicketID"}',

'Module' => 'Kernel::Output::HTML::TicketMenuGeneric',

'Name' => 'Close',

'PopupType' => 'TicketAction',

'Target' => ''

};

6.27.18. Ticket::Frontend::MenuModule###460-Delete

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a link in the menu to delete a ticket in the ticket zoom view of the agent interface. Additional access control to show or not show this link can be done by using Key "Group" and Content like

"rw:group1;move_into:group2".

Ticket

Frontend::Agent::Ticket::MenuModule

$Self->{'Ticket::Frontend::MenuModule'}->{'460-Delete'} = {

'Action' => 'AgentTicketMove',

'Description' => 'Delete this ticket',

'Link' => 'Action=AgentTicketMove;TicketID=

$Data{"TicketID"};DestQueue=Delete',

'Module' => 'Kernel::Output::HTML::TicketMenuGeneric',

'Name' => 'Delete',

'PopupType' => '',

'Target' => ''

};

6.27.19. Ticket::Frontend::MenuModule###470-Spam

Description: Shows a link to set a ticket as spam in the ticket zoom view of the agent interface. Additional access control to show or not

516

Group:

SubGroup:

Valid:

Required:

Config-Setting: show this link can be done by using Key "Group" and Content like

"rw:group1;move_into:group2".

Ticket

Frontend::Agent::Ticket::MenuModule

$Self->{'Ticket::Frontend::MenuModule'}->{'470-Spam'} = {

'Action' => 'AgentTicketMove',

'Description' => 'Mark as Spam!',

'Link' => 'Action=AgentTicketMove;TicketID=

$Data{"TicketID"};DestQueue=Delete',

'Module' => 'Kernel::Output::HTML::TicketMenuGeneric',

'Name' => 'Spam',

'PopupType' => '',

'Target' => ''

};

6.28.

Frontend::Agent::Ticket::MenuModulePre

6.28.1. Ticket::Frontend::PreMenuModule###100-Lock

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a link in the menu to lock / unlock a ticket in the ticket overviews of the agent interface.

Ticket

Frontend::Agent::Ticket::MenuModulePre

$Self->{'Ticket::Frontend::PreMenuModule'}->{'100-Lock'} = {

'Action' => 'AgentTicketLock',

'Module' => 'Kernel::Output::HTML::TicketMenuLock',

'Name' => 'Lock',

'PopupType' => '',

'Target' => ''

};

6.28.2. Ticket::Frontend::PreMenuModule###200-

Zoom

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a link in the menu to zoom a ticket in the ticket overviews of the agent interface.

Ticket

Frontend::Agent::Ticket::MenuModulePre

$Self->{'Ticket::Frontend::PreMenuModule'}->{'200-Zoom'} = {

'Action' => 'AgentTicketZoom',

'Description' => 'Look into a ticket!',

'Link' => 'Action=AgentTicketZoom;TicketID=$QData{"TicketID"}',

'Module' => 'Kernel::Output::HTML::TicketMenuGeneric',

'Name' => 'Zoom',

'PopupType' => '',

'Target' => ''

};

517

6.28.3. Ticket::Frontend::PreMenuModule###210-History

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a link in the menu to see the history of a ticket in every ticket overview of the agent interface.

Ticket

Frontend::Agent::Ticket::MenuModulePre

$Self->{'Ticket::Frontend::PreMenuModule'}->{'210-History'} = {

'Action' => 'AgentTicketHistory',

'Description' => 'Show the ticket history',

'Link' => 'Action=AgentTicketHistory;TicketID=$QData{"TicketID"}',

'Module' => 'Kernel::Output::HTML::TicketMenuGeneric',

'Name' => 'History',

'PopupType' => 'TicketHistory',

'Target' => ''

};

6.28.4. Ticket::Frontend::PreMenuModule###300-Priority

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a link in the menu to set the priority of a ticket in every ticket overview of the agent interface.

Ticket

Frontend::Agent::Ticket::MenuModulePre

$Self->{'Ticket::Frontend::PreMenuModule'}->{'300-Priority'} = {

'Action' => 'AgentTicketPriority',

'Description' => 'Change the priority for this ticket',

'Link' => 'Action=AgentTicketPriority;TicketID=

$QData{"TicketID"}',

'Module' => 'Kernel::Output::HTML::TicketMenuGeneric',

'Name' => 'Priority',

'PopupType' => 'TicketAction',

'Target' => ''

};

6.28.5. Ticket::Frontend::PreMenuModule###420-Note

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a link in the menu to add a note to a ticket in every ticket overview of the agent interface.

Ticket

Frontend::Agent::Ticket::MenuModulePre

$Self->{'Ticket::Frontend::PreMenuModule'}->{'420-Note'} = {

'Action' => 'AgentTicketNote',

'Description' => 'Add a note to this ticket',

'Link' => 'Action=AgentTicketNote;TicketID=$QData{"TicketID"}',

'Module' => 'Kernel::Output::HTML::TicketMenuGeneric',

'Name' => 'Note',

'PopupType' => 'TicketAction',

'Target' => ''

};

518

6.28.6. Ticket::Frontend::PreMenuModule###440-Close

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a link in the menu to close a ticket in every ticket overview of the agent interface.

Ticket

Frontend::Agent::Ticket::MenuModulePre

$Self->{'Ticket::Frontend::PreMenuModule'}->{'440-Close'} = {

'Action' => 'AgentTicketClose',

'Description' => 'Close this ticket',

'Link' => 'Action=AgentTicketClose;TicketID=$QData{"TicketID"}',

'Module' => 'Kernel::Output::HTML::TicketMenuGeneric',

'Name' => 'Close',

'PopupType' => 'TicketAction',

'Target' => ''

};

6.28.7. Ticket::Frontend::PreMenuModule###445-

Move

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a link in the menu to move a ticket in every ticket overview of the agent interface.

Ticket

Frontend::Agent::Ticket::MenuModulePre

$Self->{'Ticket::Frontend::PreMenuModule'}->{'445-Move'} = {

'Action' => 'AgentTicketMove',

'Description' => 'Change queue!',

'Module' => 'Kernel::Output::HTML::TicketMenuMove',

'Name' => 'Move'

};

6.28.8. Ticket::Frontend::PreMenuModule###450-

Delete

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a link in the menu to delete a ticket in every ticket overview of the agent interface. Additional access control to show or not show this link can be done by using Key "Group" and Content like

"rw:group1;move_into:group2".

Ticket

Frontend::Agent::Ticket::MenuModulePre

$Self->{'Ticket::Frontend::PreMenuModule'}->{'450-Delete'} = {

'Action' => 'AgentTicketMove',

'Description' => 'Delete this ticket',

'Link' => 'Action=AgentTicketMove;TicketID=

$Data{"TicketID"};DestQueue=Delete',

'Module' => 'Kernel::Output::HTML::TicketMenuGeneric',

'Name' => 'Delete',

'PopupType' => '',

'Target' => ''

519

};

6.28.9. Ticket::Frontend::PreMenuModule###460-

Spam

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a link in the menu to set a ticket as spam in every ticket overview of the agent interface. Additional access control to show or not show this link can be done by using Key "Group" and Content like "rw:group1;move_into:group2".

Ticket

Frontend::Agent::Ticket::MenuModulePre

$Self->{'Ticket::Frontend::PreMenuModule'}->{'460-Spam'} = {

'Action' => 'AgentTicketMove',

'Description' => 'Mark as Spam!',

'Link' => 'Action=AgentTicketMove;TicketID=

$Data{"TicketID"};DestQueue=Delete',

'Module' => 'Kernel::Output::HTML::TicketMenuGeneric',

'Name' => 'Spam',

'PopupType' => '',

'Target' => ''

};

6.29.

Frontend::Agent::Ticket::OverviewMenuModule

6.29.1.

Ticket::Frontend::OverviewMenuModule###001-Sort

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a select of ticket attributes to order the queue view ticket list. The possible selections can be configured via

'TicketOverviewMenuSort###SortAttributes'.

Ticket

Frontend::Agent::Ticket::OverviewMenuModule

$Self->{'Ticket::Frontend::OverviewMenuModule'}->{'001-Sort'} = {

'Module' => 'Kernel::Output::HTML::TicketOverviewMenuSort'

};

6.29.2. TicketOverviewMenuSort###SortAttributes

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines from which ticket attributes the agent can select the result order.

Ticket

Frontend::Agent::Ticket::OverviewMenuModule

$Self->{'TicketOverviewMenuSort'}->{'SortAttributes'} = {

'Age' => '1',

'Title' => '1'

};

520

6.30. Frontend::Agent::Ticket::ViewBounce

6.30.1.

Ticket::Frontend::AgentTicketBounce###Permission

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Required permissions to use the ticket bounce screen in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewBounce

$Self->{'Ticket::Frontend::AgentTicketBounce'}->{'Permission'} =

'bounce';

6.30.2.

Ticket::Frontend::AgentTicketBounce###RequiredLock

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines if a ticket lock is required in the ticket bounce screen of the agent interface (if the ticket isn't locked yet, the ticket gets locked and the current agent will be set automatically as its owner).

Ticket

Frontend::Agent::Ticket::ViewBounce

$Self->{'Ticket::Frontend::AgentTicketBounce'}->{'RequiredLock'} =

'1';

6.30.3.

Ticket::Frontend::AgentTicketBounce###StateDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default next state of a ticket after being bounced, in the ticket bounce screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewBounce

$Self->{'Ticket::Frontend::AgentTicketBounce'}->{'StateDefault'} =

'closed successful';

6.30.4.

Ticket::Frontend::AgentTicketBounce###StateType

Description:

Group:

SubGroup:

Valid:

Required:

Defines the next state of a ticket after being bounced, in the ticket bounce screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewBounce

521

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketBounce'}->{'StateType'} = [

'open',

'closed'

];

6.30.5. Ticket::Frontend::BounceText

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default ticket bounced notification for customer/sender in the ticket bounce screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewBounce

$Self->{'Ticket::Frontend::BounceText'} = 'Your email with ticket

number "<OTRS_TICKET>" is bounced to "<OTRS_BOUNCE_TO>". Contact

this address for further information.';

6.31. Frontend::Agent::Ticket::ViewBulk

6.31.1.

Ticket::Frontend::AgentTicketBulk###RequiredLock

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Automatically lock and set owner to current Agent after selecting for an Bulk Action.

Ticket

Frontend::Agent::Ticket::ViewBulk

$Self->{'Ticket::Frontend::AgentTicketBulk'}->{'RequiredLock'} =

'1';

6.31.2.

Ticket::Frontend::AgentTicketBulk###TicketType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the ticket type in the ticket bulk screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewBulk

$Self->{'Ticket::Frontend::AgentTicketBulk'}->{'TicketType'} =

'1';

6.31.3. Ticket::Frontend::AgentTicketBulk###Owner

Description:

Group:

SubGroup:

Valid:

Required:

Sets the ticket owner in the ticket bulk screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewBulk

522

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketBulk'}->{'Owner'} = '1';

6.31.4.

Ticket::Frontend::AgentTicketBulk###Responsible

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the responsible agent of the ticket in the ticket bulk screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewBulk

$Self->{'Ticket::Frontend::AgentTicketBulk'}->{'Responsible'} =

'1';

6.31.5. Ticket::Frontend::AgentTicketBulk###State

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If a note is added by an agent, sets the state of a ticket in the ticket bulk screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewBulk

$Self->{'Ticket::Frontend::AgentTicketBulk'}->{'State'} = '1';

6.31.6.

Ticket::Frontend::AgentTicketBulk###StateType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the next state of a ticket after adding a note, in the ticket bulk screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewBulk

$Self->{'Ticket::Frontend::AgentTicketBulk'}->{'StateType'} = [

'open',

'closed',

'pending reminder',

'pending auto'

];

6.31.7.

Ticket::Frontend::AgentTicketBulk###StateDefault

Description:

Group:

SubGroup:

Valid:

Required:

Defines the default next state of a ticket after adding a note, in the ticket bulk screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewBulk

523

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketBulk'}->{'StateDefault'} =

'open';

6.31.8. Ticket::Frontend::AgentTicketBulk###Priority

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows the ticket priority options in the ticket bulk screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewBulk

$Self->{'Ticket::Frontend::AgentTicketBulk'}->{'Priority'} = '1';

6.31.9.

Ticket::Frontend::AgentTicketBulk###PriorityDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default ticket priority in the ticket bulk screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewBulk

$Self->{'Ticket::Frontend::AgentTicketBulk'}->{'PriorityDefault'} =

'3 normal';

6.31.10.

Ticket::Frontend::AgentTicketBulk###ArticleTypeDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default type of the note in the ticket bulk screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewBulk

$Self->{'Ticket::Frontend::AgentTicketBulk'}-

>{'ArticleTypeDefault'} = 'note-internal';

6.31.11.

Ticket::Frontend::AgentTicketBulk###ArticleTypes

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the different note types that will be used in the system.

Ticket

Frontend::Agent::Ticket::ViewBulk

$Self->{'Ticket::Frontend::AgentTicketBulk'}->{'ArticleTypes'} = {

'note-external' => '1',

'note-internal' => '1',

'note-report' => '0'

524

};

6.32. Frontend::Agent::Ticket::ViewClose

6.32.1.

Ticket::Frontend::AgentTicketClose###Permission

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Required permissions to use the close ticket screen in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewClose

$Self->{'Ticket::Frontend::AgentTicketClose'}->{'Permission'} =

'close';

6.32.2.

Ticket::Frontend::AgentTicketClose###RequiredLock

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines if a ticket lock is required in the close ticket screen of the agent interface (if the ticket isn't locked yet, the ticket gets locked and the current agent will be set automatically as its owner).

Ticket

Frontend::Agent::Ticket::ViewClose

$Self->{'Ticket::Frontend::AgentTicketClose'}->{'RequiredLock'} =

'1';

6.32.3.

Ticket::Frontend::AgentTicketClose###TicketType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the ticket type in the close ticket screen of the agent interface

(Ticket::Type needs to be activated).

Ticket

Frontend::Agent::Ticket::ViewClose

$Self->{'Ticket::Frontend::AgentTicketClose'}->{'TicketType'} =

'0';

6.32.4. Ticket::Frontend::AgentTicketClose###Service

Description:

Group:

SubGroup:

Valid:

Required:

Sets the service in the close ticket screen of the agent interface

(Ticket::Service needs to be activated).

Ticket

Frontend::Agent::Ticket::ViewClose

525

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketClose'}->{'Service'} = '0';

6.32.5.

Ticket::Frontend::AgentTicketClose###ServiceMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets if service must be selected by the agent.

Ticket

Frontend::Agent::Ticket::ViewClose

$Self->{'Ticket::Frontend::AgentTicketClose'}->{'ServiceMandatory'}

= '0';

6.32.6.

Ticket::Frontend::AgentTicketClose###SLAMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets if SLA must be selected by the agent.

Ticket

Frontend::Agent::Ticket::ViewClose

$Self->{'Ticket::Frontend::AgentTicketClose'}->{'SLAMandatory'} =

'0';

6.32.7. Ticket::Frontend::AgentTicketClose###Queue

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the queue in the ticket close screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewClose

$Self->{'Ticket::Frontend::AgentTicketClose'}->{'Queue'} = '0';

6.32.8. Ticket::Frontend::AgentTicketClose###Owner

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the ticket owner in the close ticket screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewClose

$Self->{'Ticket::Frontend::AgentTicketClose'}->{'Owner'} = '0';

6.32.9.

Ticket::Frontend::AgentTicketClose###OwnerMandatory

Description: Sets if ticket owner must be selected by the agent.

526

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Agent::Ticket::ViewClose

$Self->{'Ticket::Frontend::AgentTicketClose'}->{'OwnerMandatory'} =

'0';

6.32.10.

Ticket::Frontend::AgentTicketClose###Responsible

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the responsible agent of the ticket in the close ticket screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewClose

$Self->{'Ticket::Frontend::AgentTicketClose'}->{'Responsible'} =

'0';

6.32.11. Ticket::Frontend::AgentTicketClose###State

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If a note is added by an agent, sets the state of a ticket in the close ticket screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewClose

$Self->{'Ticket::Frontend::AgentTicketClose'}->{'State'} = '1';

6.32.12.

Ticket::Frontend::AgentTicketClose###StateType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the next state of a ticket after adding a note, in the close ticket screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewClose

$Self->{'Ticket::Frontend::AgentTicketClose'}->{'StateType'} = [

'closed'

];

6.32.13.

Ticket::Frontend::AgentTicketClose###StateDefault

Description:

Group:

Defines the default next state of a ticket after adding a note, in the close ticket screen of the agent interface.

Ticket

527

SubGroup:

Valid:

Required:

Config-Setting:

Frontend::Agent::Ticket::ViewClose

$Self->{'Ticket::Frontend::AgentTicketClose'}->{'StateDefault'} =

'closed successful';

6.32.14. Ticket::Frontend::AgentTicketClose###Note

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Allows adding notes in the close ticket screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewClose

$Self->{'Ticket::Frontend::AgentTicketClose'}->{'Note'} = '1';

6.32.15.

Ticket::Frontend::AgentTicketClose###NoteMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets if note must be filled in by the agent.

Ticket

Frontend::Agent::Ticket::ViewClose

$Self->{'Ticket::Frontend::AgentTicketClose'}->{'NoteMandatory'} =

'1';

6.32.16.

Ticket::Frontend::AgentTicketClose###Subject

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the default subject for notes added in the close ticket screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewClose

$Self->{'Ticket::Frontend::AgentTicketClose'}->{'Subject'} =

'$Text{"Close"}';

6.32.17. Ticket::Frontend::AgentTicketClose###Body

Description:

Group:

SubGroup:

Valid:

Required:

Sets the default body text for notes added in the close ticket screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewClose

528

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketClose'}->{'Body'} = '';

6.32.18.

Ticket::Frontend::AgentTicketClose###InvolvedAgent

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a list of all the involved agents on this ticket, in the close ticket screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewClose

$Self->{'Ticket::Frontend::AgentTicketClose'}->{'InvolvedAgent'} =

'0';

6.32.19.

Ticket::Frontend::AgentTicketClose###InformAgent

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a list of all the possible agents (all agents with note permissions on the queue/ticket) to determine who should be informed about this note, in the close ticket screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewClose

$Self->{'Ticket::Frontend::AgentTicketClose'}->{'InformAgent'} =

'0';

6.32.20.

Ticket::Frontend::AgentTicketClose###ArticleTypeDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default type of the note in the close ticket screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewClose

$Self->{'Ticket::Frontend::AgentTicketClose'}-

>{'ArticleTypeDefault'} = 'note-internal';

6.32.21.

Ticket::Frontend::AgentTicketClose###ArticleTypes

Description:

Group:

SubGroup:

Valid:

Specifies the available note types for this ticket mask. If the option is deselected, ArticleTypeDefault is used and the option is removed from the mask.

Ticket

Frontend::Agent::Ticket::ViewClose

529

Required:

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketClose'}->{'ArticleTypes'} =

{

'note-external' => '0',

'note-internal' => '1',

'note-report' => '0'

};

6.32.22.

Ticket::Frontend::AgentTicketClose###Priority

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows the ticket priority options in the close ticket screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewClose

$Self->{'Ticket::Frontend::AgentTicketClose'}->{'Priority'} = '0';

6.32.23.

Ticket::Frontend::AgentTicketClose###PriorityDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default ticket priority in the close ticket screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewClose

$Self->{'Ticket::Frontend::AgentTicketClose'}->{'PriorityDefault'}

= '3 normal';

6.32.24. Ticket::Frontend::AgentTicketClose###Title

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows the title fields in the close ticket screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewClose

$Self->{'Ticket::Frontend::AgentTicketClose'}->{'Title'} = '0';

6.32.25.

Ticket::Frontend::AgentTicketClose###HistoryType

Description:

Group:

SubGroup:

Valid:

Defines the history type for the close ticket screen action, which gets used for ticket history in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewClose

530

Required:

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketClose'}->{'HistoryType'} =

'AddNote';

6.32.26.

Ticket::Frontend::AgentTicketClose###HistoryComment

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the history comment for the close ticket screen action, which gets used for ticket history in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewClose

$Self->{'Ticket::Frontend::AgentTicketClose'}->{'HistoryComment'} =

'%%Close';

6.32.27.

Ticket::Frontend::AgentTicketClose###DynamicField

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Dynamic fields shown in the ticket close screen of the agent interface. Possible settings: 0 = Disabled, 1 = Enabled, 2 = Enabled and required.

Ticket

Frontend::Agent::Ticket::ViewClose

$Self->{'Ticket::Frontend::AgentTicketClose'}->{'DynamicField'} =

{};

6.32.28.

Ticket::Frontend::AgentTicketClose###RichTextWidth

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the width for the rich text editor component for this screen.

Enter number (pixels) or percent value (relative).

Ticket

Frontend::Agent::Ticket::ViewClose

$Self->{'Ticket::Frontend::AgentTicketClose'}->{'RichTextWidth'} =

'620';

6.32.29.

Ticket::Frontend::AgentTicketClose###RichTextHeight

Description:

Group:

SubGroup:

Valid:

Defines the height for the rich text editor component for this screen. Enter number (pixels) or percent value (relative).

Ticket

Frontend::Agent::Ticket::ViewClose

531

Required:

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketClose'}->{'RichTextHeight'} =

'100';

6.33. Frontend::Agent::Ticket::ViewCompose

6.33.1.

Ticket::Frontend::AgentTicketCompose###Permission

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Required permissions to use the ticket compose screen in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewCompose

$Self->{'Ticket::Frontend::AgentTicketCompose'}->{'Permission'} =

'compose';

6.33.2.

Ticket::Frontend::AgentTicketCompose###RequiredLock

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines if a ticket lock is required in the ticket compose screen of the agent interface (if the ticket isn't locked yet, the ticket gets locked and the current agent will be set automatically as its owner).

Ticket

Frontend::Agent::Ticket::ViewCompose

$Self->{'Ticket::Frontend::AgentTicketCompose'}->{'RequiredLock'} =

'1';

6.33.3.

Ticket::Frontend::AgentTicketCompose###StateDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default next state of a ticket if it is composed / answered in the ticket compose screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewCompose

$Self->{'Ticket::Frontend::AgentTicketCompose'}->{'StateDefault'} =

'open';

6.33.4.

Ticket::Frontend::AgentTicketCompose###StateType

Description: Defines the next possible states after composing / answering a ticket in the ticket compose screen of the agent interface.

532

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Agent::Ticket::ViewCompose

$Self->{'Ticket::Frontend::AgentTicketCompose'}->{'StateType'} = [

'open',

'closed',

'pending auto',

'pending reminder'

];

6.33.5.

Ticket::Frontend::AgentTicketCompose###ArticleTypes

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the different article types that will be used in the system.

Ticket

Frontend::Agent::Ticket::ViewCompose

$Self->{'Ticket::Frontend::AgentTicketCompose'}->{'ArticleTypes'} =

[

'email-external',

'email-internal'

];

6.33.6.

Ticket::Frontend::AgentTicketCompose###DefaultArticleType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the default article type for the ticket compose screen in the agent interface if the article type cannot be automatically detected.

Ticket

Frontend::Agent::Ticket::ViewCompose

$Self->{'Ticket::Frontend::AgentTicketCompose'}-

>{'DefaultArticleType'} = 'email-external';

6.33.7. Ticket::Frontend::ResponseFormat

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the format of responses in the ticket compose screen of the agent interface ($QData{"OrigFrom"} is From 1:1,

$QData{"OrigFromName"} is only realname of From).

Ticket

Frontend::Agent::Ticket::ViewCompose

$Self->{'Ticket::Frontend::ResponseFormat'} =

'$QData{"Salutation"}

$QData{"StdResponse"}

$QData{"Signature"}

533

$TimeShort{"$QData{"Created"}"} - $QData{"OrigFromName"}

$Text{"wrote"}:

$QData{"Body"}

6.33.8. Ticket::Frontend::Quote

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the used character for plaintext email quotes in the ticket compose screen of the agent interface. If this is empty or inactive, original emails will not be quoted but appended to the response.

Ticket

Frontend::Agent::Ticket::ViewCompose

$Self->{'Ticket::Frontend::Quote'} = '>';

6.33.9. Ticket::Frontend::ResponseQuoteMaxLines

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the maximum number of quoted lines to be added to responses.

Ticket

Frontend::Agent::Ticket::ViewCompose

$Self->{'Ticket::Frontend::ResponseQuoteMaxLines'} = '99';

6.33.10.

Ticket::Frontend::ComposeAddCustomerAddress

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Adds customers email addresses to recipients in the ticket compose screen of the agent interface. The customers email address won't be added if the article type is email-internal.

Ticket

Frontend::Agent::Ticket::ViewCompose

$Self->{'Ticket::Frontend::ComposeAddCustomerAddress'} = '1';

6.33.11.

Ticket::Frontend::ComposeReplaceSenderAddress

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Replaces the original sender with current customer's email address on compose answer in the ticket compose screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewCompose

$Self->{'Ticket::Frontend::ComposeReplaceSenderAddress'} = '0';

534

6.33.12.

Ticket::Frontend::ComposeExcludeCcRecipients

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Uses Cc recipients in reply Cc list on compose an email answer in the ticket compose screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewCompose

$Self->{'Ticket::Frontend::ComposeExcludeCcRecipients'} = '0';

6.33.13.

Ticket::Frontend::AgentTicketCompose###DynamicField

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Dynamic fields shown in the ticket compose screen of the agent interface. Possible settings: 0 = Disabled, 1 = Enabled, 2 = Enabled and required.

Ticket

Frontend::Agent::Ticket::ViewCompose

$Self->{'Ticket::Frontend::AgentTicketCompose'}->{'DynamicField'} =

{};

6.34. Frontend::Agent::Ticket::ViewCustomer

6.34.1.

Ticket::Frontend::AgentTicketCustomer###Permission

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Required permissions to change the customer of a ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewCustomer

$Self->{'Ticket::Frontend::AgentTicketCustomer'}->{'Permission'} =

'customer';

6.34.2.

Ticket::Frontend::AgentTicketCustomer###RequiredLock

Description:

Group:

SubGroup:

Valid:

Defines if a ticket lock is required to change the customer of a ticket in the agent interface (if the ticket isn't locked yet, the ticket gets locked and the current agent will be set automatically as its owner).

Ticket

Frontend::Agent::Ticket::ViewCustomer

535

Required:

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketCustomer'}->{'RequiredLock'}

= '0';

6.35. Frontend::Agent::Ticket::ViewEmailNew

6.35.1. Ticket::Frontend::AgentTicketEmail###Priority

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the default priority for new email tickets in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewEmailNew

$Self->{'Ticket::Frontend::AgentTicketEmail'}->{'Priority'} = '3

normal';

6.35.2.

Ticket::Frontend::AgentTicketEmail###ArticleType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the default article type for new email tickets in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewEmailNew

$Self->{'Ticket::Frontend::AgentTicketEmail'}->{'ArticleType'} =

'email-external';

6.35.3.

Ticket::Frontend::AgentTicketEmail###SenderType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the default sender type for new email tickets in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewEmailNew

$Self->{'Ticket::Frontend::AgentTicketEmail'}->{'SenderType'} =

'agent';

6.35.4. Ticket::Frontend::AgentTicketEmail###Subject

Description:

Group:

SubGroup:

Valid:

Sets the default subject for new email tickets (e.g. 'email Outbound') in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewEmailNew

536

Required:

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketEmail'}->{'Subject'} = '';

6.35.5. Ticket::Frontend::AgentTicketEmail###Body

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the default text for new email tickets in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewEmailNew

$Self->{'Ticket::Frontend::AgentTicketEmail'}->{'Body'} = '';

6.35.6.

Ticket::Frontend::AgentTicketEmail###StateDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the default next ticket state, after the creation of an email ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewEmailNew

$Self->{'Ticket::Frontend::AgentTicketEmail'}->{'StateDefault'} =

'open';

6.35.7.

Ticket::Frontend::AgentTicketEmail###StateType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Determines the next possible ticket states, after the creation of a new email ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewEmailNew

$Self->{'Ticket::Frontend::AgentTicketEmail'}->{'StateType'} = [

'open',

'pending auto',

'pending reminder',

'closed'

];

6.35.8.

Ticket::Frontend::AgentTicketEmail###HistoryType

Description:

Group:

SubGroup:

Valid:

Defines the history type for the email ticket screen action, which gets used for ticket history in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewEmailNew

537

Required:

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketEmail'}->{'HistoryType'} =

'EmailAgent';

6.35.9.

Ticket::Frontend::AgentTicketEmail###HistoryComment

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the history comment for the email ticket screen action, which gets used for ticket history in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewEmailNew

$Self->{'Ticket::Frontend::AgentTicketEmail'}->{'HistoryComment'} =

'';

6.35.10.

Ticket::Frontend::AgentTicketEmail###ServiceMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets if service must be selected by the agent.

Ticket

Frontend::Agent::Ticket::ViewEmailNew

$Self->{'Ticket::Frontend::AgentTicketEmail'}->{'ServiceMandatory'}

= '0';

6.35.11.

Ticket::Frontend::AgentTicketEmail###SLAMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets if SLA must be selected by the agent.

Ticket

Frontend::Agent::Ticket::ViewEmailNew

$Self->{'Ticket::Frontend::AgentTicketEmail'}->{'SLAMandatory'} =

'0';

6.35.12.

Ticket::Frontend::AgentTicketEmail###DynamicField

Description:

Group:

SubGroup:

Valid:

Required:

Dynamic fields shown in the ticket email screen of the agent interface. Possible settings: 0 = Disabled, 1 = Enabled, 2 = Enabled and required.

Ticket

Frontend::Agent::Ticket::ViewEmailNew

538

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketEmail'}->{'DynamicField'} =

{};

6.35.13.

Ticket::Frontend::AgentTicketEmail###RichTextWidth

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the width for the rich text editor component for this screen.

Enter number (pixels) or percent value (relative).

Ticket

Frontend::Agent::Ticket::ViewEmailNew

$Self->{'Ticket::Frontend::AgentTicketEmail'}->{'RichTextWidth'} =

'620';

6.35.14.

Ticket::Frontend::AgentTicketEmail###RichTextHeight

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the height for the rich text editor component for this screen. Enter number (pixels) or percent value (relative).

Ticket

Frontend::Agent::Ticket::ViewEmailNew

$Self->{'Ticket::Frontend::AgentTicketEmail'}->{'RichTextHeight'} =

'320';

6.36. Frontend::Agent::Ticket::ViewEscalation

6.36.1.

Ticket::Frontend::AgentTicketEscalationView###TicketPermission

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the required permission to show a ticket in the escalation view of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewEscalation

$Self->{'Ticket::Frontend::AgentTicketEscalationView'}-

>{'TicketPermission'} = 'rw';

6.36.2.

Ticket::Frontend::AgentTicketEscalationView###ViewableTicketsPage

Description:

Group:

SubGroup:

Shows all open tickets (even if they are locked) in the escalation view of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewEscalation

539

Valid:

Required:

Config-Setting:

6.36.3.

Ticket::Frontend::AgentTicketEscalationView###SortBy::Default

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default ticket attribute for ticket sorting in the escalation view of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewEscalation

$Self->{'Ticket::Frontend::AgentTicketEscalationView'}-

>{'SortBy::Default'} = 'EscalationTime';

6.36.4.

Ticket::Frontend::AgentTicketEscalationView###Order::Default

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default ticket order (after priority sort) in the escalation view of the agent interface. Up: oldest on top. Down: latest on top.

Ticket

Frontend::Agent::Ticket::ViewEscalation

$Self->{'Ticket::Frontend::AgentTicketEscalationView'}-

>{'Order::Default'} = 'Up';

6.36.5.

Ticket::Frontend::AgentTicketEscalationView###DefaultColumns

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketEscalationView'}-

>{'ViewableTicketsPage'} = '50';

Columns that can be filtered in the escalation view of the agent interface. Possible settings: 0 = Disabled, 1 = Available, 2 = Enabled by default. Note: Only Ticket attributes and Dynamic Fields

(DynamicField_NameX) are allowed.

Ticket

Frontend::Agent::Ticket::ViewEscalation

$Self->{'Ticket::Frontend::AgentTicketEscalationView'}-

>{'DefaultColumns'} = {

'Age' => '2',

'Changed' => '1',

'CustomerID' => '2',

'CustomerName' => '1',

'CustomerUserID' => '1',

'EscalationResponseTime' => '1',

'EscalationSolutionTime' => '1',

'EscalationTime' => '2',

'EscalationUpdateTime' => '1',

540

'Lock' => '2',

'Owner' => '2',

'PendingTime' => '1',

'Priority' => '1',

'Queue' => '2',

'Responsible' => '1',

'SLA' => '1',

'Service' => '1',

'State' => '2',

'TicketNumber' => '2',

'Title' => '2',

'Type' => '1'

};

6.37. Frontend::Agent::Ticket::ViewForward

6.37.1.

Ticket::Frontend::AgentTicketForward###Permission

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Required permissions to use the ticket forward screen in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewForward

$Self->{'Ticket::Frontend::AgentTicketForward'}->{'Permission'} =

'forward';

6.37.2.

Ticket::Frontend::AgentTicketForward###RequiredLock

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines if a ticket lock is required in the ticket forward screen of the agent interface (if the ticket isn't locked yet, the ticket gets locked and the current agent will be set automatically as its owner).

Ticket

Frontend::Agent::Ticket::ViewForward

$Self->{'Ticket::Frontend::AgentTicketForward'}->{'RequiredLock'} =

'1';

6.37.3.

Ticket::Frontend::AgentTicketForward###StateDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default next state of a ticket after being forwarded, in the ticket forward screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewForward

$Self->{'Ticket::Frontend::AgentTicketForward'}->{'StateDefault'} =

'closed successful';

541

6.37.4.

Ticket::Frontend::AgentTicketForward###StateType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the next possible states after forwarding a ticket in the ticket forward screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewForward

$Self->{'Ticket::Frontend::AgentTicketForward'}->{'StateType'} = [

'open',

'closed',

'pending reminder',

'pending auto'

];

6.37.5.

Ticket::Frontend::AgentTicketForward###ArticleTypeDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default type of forwarded message in the ticket forward screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewForward

$Self->{'Ticket::Frontend::AgentTicketForward'}-

>{'ArticleTypeDefault'} = 'email-external';

6.37.6.

Ticket::Frontend::AgentTicketForward###ArticleTypes

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the different article types that will be used in the system.

Ticket

Frontend::Agent::Ticket::ViewForward

$Self->{'Ticket::Frontend::AgentTicketForward'}->{'ArticleTypes'} =

[

'email-external',

'email-internal'

];

6.37.7.

Ticket::Frontend::AgentTicketForward###DynamicField

Description:

Group:

SubGroup:

Valid:

Dynamic fields shown in the ticket forward screen of the agent interface. Possible settings: 0 = Disabled, 1 = Enabled, 2 = Enabled and required.

Ticket

Frontend::Agent::Ticket::ViewForward

542

Required:

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketForward'}->{'DynamicField'} =

{};

6.37.8.

Ticket::Frontend::AgentTicketForward###RichTextWidth

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the width for the rich text editor component for this screen.

Enter number (pixels) or percent value (relative).

Ticket

Frontend::Agent::Ticket::ViewForward

$Self->{'Ticket::Frontend::AgentTicketForward'}->{'RichTextWidth'}

= '620';

6.37.9.

Ticket::Frontend::AgentTicketForward###RichTextHeight

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the height for the rich text editor component for this screen. Enter number (pixels) or percent value (relative).

Ticket

Frontend::Agent::Ticket::ViewForward

$Self->{'Ticket::Frontend::AgentTicketForward'}->{'RichTextHeight'}

= '100';

6.38. Frontend::Agent::Ticket::ViewFreeText

6.38.1.

Ticket::Frontend::AgentTicketFreeText###Permission

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Required permissions to use the ticket free text screen in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewFreeText

$Self->{'Ticket::Frontend::AgentTicketFreeText'}->{'Permission'} =

'rw';

6.38.2.

Ticket::Frontend::AgentTicketFreeText###RequiredLock

Description: Defines if a ticket lock is required in the ticket free text screen of the agent interface (if the ticket isn't locked yet, the ticket gets locked and the current agent will be set automatically as its owner).

543

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Agent::Ticket::ViewFreeText

$Self->{'Ticket::Frontend::AgentTicketFreeText'}->{'RequiredLock'}

= '0';

6.38.3.

Ticket::Frontend::AgentTicketFreeText###TicketType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the ticket type in the ticket free text screen of the agent interface (Ticket::Type needs to be activated).

Ticket

Frontend::Agent::Ticket::ViewFreeText

$Self->{'Ticket::Frontend::AgentTicketFreeText'}->{'TicketType'} =

'1';

6.38.4.

Ticket::Frontend::AgentTicketFreeText###Service

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the service in the ticket free text screen of the agent interface

(Ticket::Service needs to be activated).

Ticket

Frontend::Agent::Ticket::ViewFreeText

$Self->{'Ticket::Frontend::AgentTicketFreeText'}->{'Service'} =

'1';

6.38.5.

Ticket::Frontend::AgentTicketFreeText###ServiceMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets if service must be selected by the agent.

Ticket

Frontend::Agent::Ticket::ViewFreeText

$Self->{'Ticket::Frontend::AgentTicketFreeText'}-

>{'ServiceMandatory'} = '0';

6.38.6.

Ticket::Frontend::AgentTicketFreeText###SLAMandatory

Description:

Group:

SubGroup:

Sets if SLA must be selected by the agent.

Ticket

Frontend::Agent::Ticket::ViewFreeText

544

Valid:

Required:

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketFreeText'}->{'SLAMandatory'}

= '0';

6.38.7.

Ticket::Frontend::AgentTicketFreeText###Queue

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the queue in the ticket free text screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewFreeText

$Self->{'Ticket::Frontend::AgentTicketFreeText'}->{'Queue'} = '0';

6.38.8.

Ticket::Frontend::AgentTicketFreeText###Owner

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the ticket owner in the ticket free text screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewFreeText

$Self->{'Ticket::Frontend::AgentTicketFreeText'}->{'Owner'} = '0';

6.38.9.

Ticket::Frontend::AgentTicketFreeText###OwnerMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets if ticket owner must be selected by the agent.

Ticket

Frontend::Agent::Ticket::ViewFreeText

$Self->{'Ticket::Frontend::AgentTicketFreeText'}-

>{'OwnerMandatory'} = '0';

6.38.10.

Ticket::Frontend::AgentTicketFreeText###Responsible

Description:

Group:

SubGroup:

Valid:

Required:

Sets the responsible agent of the ticket in the ticket free text screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewFreeText

545

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketFreeText'}->{'Responsible'} =

'0';

6.38.11.

Ticket::Frontend::AgentTicketFreeText###State

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If a note is added by an agent, sets the state of a ticket in the ticket free text screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewFreeText

$Self->{'Ticket::Frontend::AgentTicketFreeText'}->{'State'} = '0';

6.38.12.

Ticket::Frontend::AgentTicketFreeText###StateType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the next state of a ticket after adding a note, in the ticket free text screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewFreeText

$Self->{'Ticket::Frontend::AgentTicketFreeText'}->{'StateType'} =

[

'open',

'closed',

'pending reminder',

'pending auto'

];

6.38.13.

Ticket::Frontend::AgentTicketFreeText###StateDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default next state of a ticket after adding a note, in the ticket free text screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewFreeText

$Self->{'Ticket::Frontend::AgentTicketFreeText'}->{'StateDefault'}

= 'open';

6.38.14.

Ticket::Frontend::AgentTicketFreeText###Note

Description:

Group:

SubGroup:

Allows adding notes in the ticket free text screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewFreeText

546

Valid:

Required:

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketFreeText'}->{'Note'} = '0';

6.38.15.

Ticket::Frontend::AgentTicketFreeText###NoteMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets if note must be filled in by the agent.

Ticket

Frontend::Agent::Ticket::ViewFreeText

$Self->{'Ticket::Frontend::AgentTicketFreeText'}->{'NoteMandatory'}

= '0';

6.38.16.

Ticket::Frontend::AgentTicketFreeText###Subject

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default subject of a note in the ticket free text screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewFreeText

$Self->{'Ticket::Frontend::AgentTicketFreeText'}->{'Subject'} =

'$Text{"Note"}';

6.38.17.

Ticket::Frontend::AgentTicketFreeText###Body

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default body of a note in the ticket free text screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewFreeText

$Self->{'Ticket::Frontend::AgentTicketFreeText'}->{'Body'} = '';

6.38.18.

Ticket::Frontend::AgentTicketFreeText###InvolvedAgent

Description:

Group:

SubGroup:

Valid:

Required:

Shows a list of all the involved agents on this ticket, in the ticket free text screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewFreeText

547

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketFreeText'}->{'InvolvedAgent'}

= '0';

6.38.19.

Ticket::Frontend::AgentTicketFreeText###InformAgent

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a list of all the possible agents (all agents with note permissions on the queue/ticket) to determine who should be informed about this note, in the ticket free text screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewFreeText

$Self->{'Ticket::Frontend::AgentTicketFreeText'}->{'InformAgent'} =

'0';

6.38.20.

Ticket::Frontend::AgentTicketFreeText###ArticleTypeDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default type of the note in the ticket free text screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewFreeText

$Self->{'Ticket::Frontend::AgentTicketFreeText'}-

>{'ArticleTypeDefault'} = 'note-internal';

6.38.21.

Ticket::Frontend::AgentTicketFreeText###ArticleTypes

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the available note types for this ticket mask. If the option is deselected, ArticleTypeDefault is used and the option is removed from the mask.

Ticket

Frontend::Agent::Ticket::ViewFreeText

$Self->{'Ticket::Frontend::AgentTicketFreeText'}->{'ArticleTypes'}

= {

'note-external' => '1',

'note-internal' => '1',

'note-report' => '0'

};

6.38.22.

Ticket::Frontend::AgentTicketFreeText###Priority

Description: Shows the ticket priority options in the ticket free text screen of the agent interface.

548

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Agent::Ticket::ViewFreeText

$Self->{'Ticket::Frontend::AgentTicketFreeText'}->{'Priority'} =

'0';

6.38.23.

Ticket::Frontend::AgentTicketFreeText###PriorityDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default ticket priority in the ticket free text screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewFreeText

$Self->{'Ticket::Frontend::AgentTicketFreeText'}-

>{'PriorityDefault'} = '3 normal';

6.38.24.

Ticket::Frontend::AgentTicketFreeText###Title

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows the title fields in the ticket free text screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewFreeText

$Self->{'Ticket::Frontend::AgentTicketFreeText'}->{'Title'} = '1';

6.38.25.

Ticket::Frontend::AgentTicketFreeText###HistoryType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the history type for the ticket free text screen action, which gets used for ticket history.

Ticket

Frontend::Agent::Ticket::ViewFreeText

$Self->{'Ticket::Frontend::AgentTicketFreeText'}->{'HistoryType'} =

'AddNote';

6.38.26.

Ticket::Frontend::AgentTicketFreeText###HistoryComment

Description:

Group:

Defines the history comment for the ticket free text screen action, which gets used for ticket history.

Ticket

549

SubGroup:

Valid:

Required:

Config-Setting:

Frontend::Agent::Ticket::ViewFreeText

$Self->{'Ticket::Frontend::AgentTicketFreeText'}-

>{'HistoryComment'} = '%%FreeText';

6.38.27.

Ticket::Frontend::AgentTicketFreeText###DynamicField

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Dynamic fields shown in the ticket free text screen of the agent interface. Possible settings: 0 = Disabled, 1 = Enabled, 2 = Enabled and required.

Ticket

Frontend::Agent::Ticket::ViewFreeText

$Self->{'Ticket::Frontend::AgentTicketFreeText'}->{'DynamicField'}

= {};

6.38.28.

Ticket::Frontend::AgentTicketFreeText###RichTextWidth

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the width for the rich text editor component for this screen.

Enter number (pixels) or percent value (relative).

Ticket

Frontend::Agent::Ticket::ViewFreeText

$Self->{'Ticket::Frontend::AgentTicketFreeText'}->{'RichTextWidth'}

= '620';

6.38.29.

Ticket::Frontend::AgentTicketFreeText###RichTextHeight

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the height for the rich text editor component for this screen. Enter number (pixels) or percent value (relative).

Ticket

Frontend::Agent::Ticket::ViewFreeText

$Self->{'Ticket::Frontend::AgentTicketFreeText'}-

>{'RichTextHeight'} = '100';

6.39. Frontend::Agent::Ticket::ViewHistory

6.39.1. Ticket::Frontend::HistoryOrder

Description: Shows the ticket history (reverse ordered) in the agent interface.

550

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Agent::Ticket::ViewHistory

$Self->{'Ticket::Frontend::HistoryOrder'} = 'normal';

6.40. Frontend::Agent::Ticket::ViewLocked

6.40.1.

Ticket::Frontend::AgentTicketLockedView###SortBy::Default

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default ticket attribute for ticket sorting in the locked ticket view of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewLocked

$Self->{'Ticket::Frontend::AgentTicketLockedView'}-

>{'SortBy::Default'} = 'Age';

6.40.2.

Ticket::Frontend::AgentTicketLockedView###Order::Default

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default ticket order in the ticket locked view of the agent interface. Up: oldest on top. Down: latest on top.

Ticket

Frontend::Agent::Ticket::ViewLocked

$Self->{'Ticket::Frontend::AgentTicketLockedView'}-

>{'Order::Default'} = 'Up';

6.40.3.

Ticket::Frontend::AgentTicketLockedView###DefaultColumns

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Columns that can be filtered in the locked view of the agent interface. Possible settings: 0 = Disabled, 1 = Available, 2 = Enabled by default. Note: Only Ticket attributes and Dynamic Fields

(DynamicField_NameX) are allowed.

Ticket

Frontend::Agent::Ticket::ViewLocked

$Self->{'Ticket::Frontend::AgentTicketLockedView'}-

>{'DefaultColumns'} = {

'Age' => '2',

'Changed' => '1',

'CustomerID' => '2',

'CustomerName' => '1',

551

6.41. Frontend::Agent::Ticket::ViewMerge

6.41.1.

Ticket::Frontend::AgentTicketMerge###Permission

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

'CustomerUserID' => '1',

'EscalationResponseTime' => '1',

'EscalationSolutionTime' => '1',

'EscalationTime' => '1',

'EscalationUpdateTime' => '1',

'Lock' => '2',

'Owner' => '2',

'PendingTime' => '1',

'Priority' => '1',

'Queue' => '2',

'Responsible' => '1',

'SLA' => '1',

'Service' => '1',

'State' => '2',

'TicketNumber' => '2',

'Title' => '2',

'Type' => '1'

};

Required permissions to use the ticket merge screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewMerge

$Self->{'Ticket::Frontend::AgentTicketMerge'}->{'Permission'} =

'rw';

6.41.2.

Ticket::Frontend::AgentTicketMerge###RequiredLock

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines if a ticket lock is required in the ticket merge screen of a zoomed ticket in the agent interface (if the ticket isn't locked yet, the ticket gets locked and the current agent will be set automatically as its owner).

Ticket

Frontend::Agent::Ticket::ViewMerge

$Self->{'Ticket::Frontend::AgentTicketMerge'}->{'RequiredLock'} =

'1';

6.41.3. Ticket::Frontend::MergeText

Description:

Group:

SubGroup:

When tickets are merged, the customer can be informed per email by setting the check box "Inform Sender". In this text area, you can define a pre-formatted text which can later be modified by the agents.

Ticket

Frontend::Agent::Ticket::ViewMerge

552

Valid:

Required:

Config-Setting:

$Self->{'Ticket::Frontend::MergeText'} = 'Your email with ticket

number "<OTRS_TICKET>" is merged to "<OTRS_MERGE_TO_TICKET>".';

6.41.4. Ticket::Frontend::AutomaticMergeSubject

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

When tickets are merged, a note will be added automatically to the ticket which is no longer active. Here you can define the subject of this note (this subject cannot be changed by the agent).

Ticket

Frontend::Agent::Ticket::ViewMerge

$Self->{'Ticket::Frontend::AutomaticMergeSubject'} = 'Ticket

Merged';

6.41.5. Ticket::Frontend::AutomaticMergeText

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

When tickets are merged, a note will be added automatically to the ticket which is no longer active. Here you can define the body of this note (this text cannot be changed by the agent).

Ticket

Frontend::Agent::Ticket::ViewMerge

$Self->{'Ticket::Frontend::AutomaticMergeText'} = 'Merged Ticket

<OTRS_TICKET> to <OTRS_MERGE_TO_TICKET>.';

6.41.6.

Ticket::Frontend::AgentTicketMerge###RichTextWidth

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the width for the rich text editor component for this screen.

Enter number (pixels) or percent value (relative).

Ticket

Frontend::Agent::Ticket::ViewMerge

$Self->{'Ticket::Frontend::AgentTicketMerge'}->{'RichTextWidth'} =

'620';

6.41.7.

Ticket::Frontend::AgentTicketMerge###RichTextHeight

Description:

Group:

SubGroup:

Valid:

Defines the height for the rich text editor component for this screen. Enter number (pixels) or percent value (relative).

Ticket

Frontend::Agent::Ticket::ViewMerge

553

Required:

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketMerge'}->{'RichTextHeight'} =

'100';

6.42. Frontend::Agent::Ticket::ViewMove

6.42.1. Ticket::Frontend::MoveType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Determines if the list of possible queues to move to ticket into should be displayed in a dropdown list or in a new window in the agent interface. If "New Window" is set you can add a move note to the ticket.

Ticket

Frontend::Agent::Ticket::ViewMove

$Self->{'Ticket::Frontend::MoveType'} = 'form';

6.42.2. Ticket::Frontend::AgentTicketMove###State

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Allows to set a new ticket state in the move ticket screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewMove

$Self->{'Ticket::Frontend::AgentTicketMove'}->{'State'} = '1';

6.42.3.

Ticket::Frontend::AgentTicketMove###StateType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the next state of a ticket after being moved to another queue, in the move ticket screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewMove

$Self->{'Ticket::Frontend::AgentTicketMove'}->{'StateType'} = [

'open',

'closed'

];

6.42.4. Ticket::Frontend::AgentTicketMove###Priority

Description:

Group:

SubGroup:

Valid:

Shows the ticket priority options in the move ticket screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewMove

554

Required:

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketMove'}->{'Priority'} = '0';

6.42.5.

Ticket::Frontend::AgentTicketMove###RequiredLock

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Automatically lock and set owner to current Agent after opening the move ticket screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewMove

$Self->{'Ticket::Frontend::AgentTicketMove'}->{'RequiredLock'} =

'1';

6.42.6.

Ticket::Frontend::AgentTicketMove###NextScreen

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Determines the next screen after the ticket is moved. LastScreenOverview will return the last overview screen (e.g. search results, queueview, dashboard). TicketZoom will return to the TicketZoom.

Ticket

Frontend::Agent::Ticket::ViewMove

$Self->{'Ticket::Frontend::AgentTicketMove'}->{'NextScreen'} =

'TicketZoom';

6.42.7. Ticket::Frontend::AgentTicketMove###Subject

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the default subject for notes added in the ticket move screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewMove

$Self->{'Ticket::Frontend::AgentTicketMove'}->{'Subject'} =

'$Text{"Change Queue"}';

6.42.8. Ticket::Frontend::AgentTicketMove###Body

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the default body text for notes added in the ticket move screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewMove

$Self->{'Ticket::Frontend::AgentTicketMove'}->{'Body'} = '';

555

6.42.9.

Ticket::Frontend::AgentTicketMove###RichTextWidth

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the width for the rich text editor component for this screen.

Enter number (pixels) or percent value (relative).

Ticket

Frontend::Agent::Ticket::ViewMove

$Self->{'Ticket::Frontend::AgentTicketMove'}->{'RichTextWidth'} =

'620';

6.42.10.

Ticket::Frontend::AgentTicketMove###RichTextHeight

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the height for the rich text editor component for this screen. Enter number (pixels) or percent value (relative).

Ticket

Frontend::Agent::Ticket::ViewMove

$Self->{'Ticket::Frontend::AgentTicketMove'}->{'RichTextHeight'} =

'100';

6.42.11.

Ticket::Frontend::AgentTicketMove###DynamicField

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Dynamic fields shown in the ticket move screen of the agent interface. Possible settings: 0 = Disabled, 1 = Enabled, 2 = Enabled and required.

Ticket

Frontend::Agent::Ticket::ViewMove

$Self->{'Ticket::Frontend::AgentTicketMove'}->{'DynamicField'} =

{};

6.43. Frontend::Agent::Ticket::ViewNote

6.43.1.

Ticket::Frontend::AgentTicketNote###Permission

Description:

Group:

SubGroup:

Valid:

Required:

Required permissions to use the ticket note screen in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewNote

556

Config-Setting:

6.43.2.

Ticket::Frontend::AgentTicketNote###RequiredLock

Description:

$Self->{'Ticket::Frontend::AgentTicketNote'}->{'Permission'} =

'note';

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines if a ticket lock is required in the ticket note screen of the agent interface (if the ticket isn't locked yet, the ticket gets locked and the current agent will be set automatically as its owner).

Ticket

Frontend::Agent::Ticket::ViewNote

$Self->{'Ticket::Frontend::AgentTicketNote'}->{'RequiredLock'} =

'0';

6.43.3.

Ticket::Frontend::AgentTicketNote###TicketType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the ticket type in the ticket note screen of the agent interface

(Ticket::Type needs to be activated).

Ticket

Frontend::Agent::Ticket::ViewNote

$Self->{'Ticket::Frontend::AgentTicketNote'}->{'TicketType'} =

'0';

6.43.4. Ticket::Frontend::AgentTicketNote###Service

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the service in the ticket note screen of the agent interface

(Ticket::Service needs to be activated).

Ticket

Frontend::Agent::Ticket::ViewNote

$Self->{'Ticket::Frontend::AgentTicketNote'}->{'Service'} = '0';

6.43.5.

Ticket::Frontend::AgentTicketNote###ServiceMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets if service must be selected by the agent.

Ticket

Frontend::Agent::Ticket::ViewNote

$Self->{'Ticket::Frontend::AgentTicketNote'}->{'ServiceMandatory'}

= '0';

557

6.43.6.

Ticket::Frontend::AgentTicketNote###SLAMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets if SLA must be selected by the agent.

Ticket

Frontend::Agent::Ticket::ViewNote

$Self->{'Ticket::Frontend::AgentTicketNote'}->{'SLAMandatory'} =

'0';

6.43.7. Ticket::Frontend::AgentTicketNote###Queue

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the queue in the ticket note screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewNote

$Self->{'Ticket::Frontend::AgentTicketNote'}->{'Queue'} = '0';

6.43.8. Ticket::Frontend::AgentTicketNote###Owner

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the ticket owner in the ticket note screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewNote

$Self->{'Ticket::Frontend::AgentTicketNote'}->{'Owner'} = '0';

6.43.9.

Ticket::Frontend::AgentTicketNote###OwnerMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets if ticket owner must be selected by the agent.

Ticket

Frontend::Agent::Ticket::ViewNote

$Self->{'Ticket::Frontend::AgentTicketNote'}->{'OwnerMandatory'} =

'0';

6.43.10.

Ticket::Frontend::AgentTicketNote###Responsible

Description: Sets the responsible agent of the ticket in the ticket note screen of the agent interface.

558

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Agent::Ticket::ViewNote

$Self->{'Ticket::Frontend::AgentTicketNote'}->{'Responsible'} =

'0';

6.43.11. Ticket::Frontend::AgentTicketNote###State

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If a note is added by an agent, sets the state of a ticket in the ticket note screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewNote

$Self->{'Ticket::Frontend::AgentTicketNote'}->{'State'} = '0';

6.43.12.

Ticket::Frontend::AgentTicketNote###StateType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the next state of a ticket after adding a note, in the ticket note screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewNote

$Self->{'Ticket::Frontend::AgentTicketNote'}->{'StateType'} = [

'open',

'closed',

'pending reminder',

'pending auto'

];

6.43.13.

Ticket::Frontend::AgentTicketNote###StateDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default next state of a ticket after adding a note, in the ticket note screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewNote

$Self->{'Ticket::Frontend::AgentTicketNote'}->{'StateDefault'} =

'open';

6.43.14. Ticket::Frontend::AgentTicketNote###Note

Description: Allows adding notes in the ticket note screen of the agent interface.

559

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Agent::Ticket::ViewNote

$Self->{'Ticket::Frontend::AgentTicketNote'}->{'Note'} = '1';

6.43.15.

Ticket::Frontend::AgentTicketNote###NoteMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets if note must be filled in by the agent.

Ticket

Frontend::Agent::Ticket::ViewNote

$Self->{'Ticket::Frontend::AgentTicketNote'}->{'NoteMandatory'} =

'1';

6.43.16. Ticket::Frontend::AgentTicketNote###Subject

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the default subject for notes added in the ticket note screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewNote

$Self->{'Ticket::Frontend::AgentTicketNote'}->{'Subject'} =

'$Text{"Note"}';

6.43.17. Ticket::Frontend::AgentTicketNote###Body

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the default body text for notes added in the ticket note screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewNote

$Self->{'Ticket::Frontend::AgentTicketNote'}->{'Body'} = '';

6.43.18.

Ticket::Frontend::AgentTicketNote###InvolvedAgent

Description:

Group:

SubGroup:

Valid:

Required:

Shows a list of all the involved agents on this ticket, in the ticket note screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewNote

560

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketNote'}->{'InvolvedAgent'} =

'0';

6.43.19.

Ticket::Frontend::AgentTicketNote###InformAgent

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a list of all the possible agents (all agents with note permissions on the queue/ticket) to determine who should be informed about this note, in the ticket note screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewNote

$Self->{'Ticket::Frontend::AgentTicketNote'}->{'InformAgent'} =

'0';

6.43.20.

Ticket::Frontend::AgentTicketNote###ArticleTypeDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default type of the note in the ticket note screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewNote

$Self->{'Ticket::Frontend::AgentTicketNote'}-

>{'ArticleTypeDefault'} = 'note-internal';

6.43.21.

Ticket::Frontend::AgentTicketNote###ArticleTypes

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the available note types for this ticket mask. If the option is deselected, ArticleTypeDefault is used and the option is removed from the mask.

Ticket

Frontend::Agent::Ticket::ViewNote

$Self->{'Ticket::Frontend::AgentTicketNote'}->{'ArticleTypes'} = {

'note-external' => '1',

'note-internal' => '1',

'note-report' => '0'

};

6.43.22. Ticket::Frontend::AgentTicketNote###Priority

Description:

Group:

SubGroup:

Shows the ticket priority options in the ticket note screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewNote

561

Valid:

Required:

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketNote'}->{'Priority'} = '0';

6.43.23.

Ticket::Frontend::AgentTicketNote###PriorityDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default ticket priority in the ticket note screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewNote

$Self->{'Ticket::Frontend::AgentTicketNote'}->{'PriorityDefault'} =

'3 normal';

6.43.24. Ticket::Frontend::AgentTicketNote###Title

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows the title fields in the ticket note screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewNote

$Self->{'Ticket::Frontend::AgentTicketNote'}->{'Title'} = '0';

6.43.25.

Ticket::Frontend::AgentTicketNote###HistoryType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the history type for the ticket note screen action, which gets used for ticket history in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewNote

$Self->{'Ticket::Frontend::AgentTicketNote'}->{'HistoryType'} =

'AddNote';

6.43.26.

Ticket::Frontend::AgentTicketNote###HistoryComment

Description:

Group:

SubGroup:

Valid:

Required:

Defines the history comment for the ticket note screen action, which gets used for ticket history in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewNote

562

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketNote'}->{'HistoryComment'} =

'%%Note';

6.43.27.

Ticket::Frontend::AgentTicketNote###DynamicField

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Dynamic fields shown in the ticket note screen of the agent interface. Possible settings: 0 = Disabled, 1 = Enabled, 2 = Enabled and required.

Ticket

Frontend::Agent::Ticket::ViewNote

$Self->{'Ticket::Frontend::AgentTicketNote'}->{'DynamicField'} =

{};

6.43.28.

Ticket::Frontend::AgentTicketNote###RichTextWidth

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the width for the rich text editor component for this screen.

Enter number (pixels) or percent value (relative).

Ticket

Frontend::Agent::Ticket::ViewNote

$Self->{'Ticket::Frontend::AgentTicketNote'}->{'RichTextWidth'} =

'620';

6.43.29.

Ticket::Frontend::AgentTicketNote###RichTextHeight

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the height for the rich text editor component for this screen. Enter number (pixels) or percent value (relative).

Ticket

Frontend::Agent::Ticket::ViewNote

$Self->{'Ticket::Frontend::AgentTicketNote'}->{'RichTextHeight'} =

'100';

6.44. Frontend::Agent::Ticket::ViewOwner

6.44.1.

Ticket::Frontend::AgentTicketOwner###Permission

Description:

Group:

Required permissions to use the ticket owner screen of a zoomed ticket in the agent interface.

Ticket

563

SubGroup:

Valid:

Required:

Config-Setting:

Frontend::Agent::Ticket::ViewOwner

$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'Permission'} =

'owner';

6.44.2.

Ticket::Frontend::AgentTicketOwner###RequiredLock

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines if a ticket lock is required in the ticket owner screen of a zoomed ticket in the agent interface (if the ticket isn't locked yet, the ticket gets locked and the current agent will be set automatically as its owner).

Ticket

Frontend::Agent::Ticket::ViewOwner

$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'RequiredLock'} =

'0';

6.44.3.

Ticket::Frontend::AgentTicketOwner###TicketType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the ticket type in the ticket owner screen of a zoomed ticket in the agent interface (Ticket::Type needs to be activated).

Ticket

Frontend::Agent::Ticket::ViewOwner

$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'TicketType'} =

'0';

6.44.4.

Ticket::Frontend::AgentTicketOwner###Service

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the service in the ticket owner screen of a zoomed ticket in the agent interface (Ticket::Service needs to be activated).

Ticket

Frontend::Agent::Ticket::ViewOwner

$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'Service'} = '0';

6.44.5.

Ticket::Frontend::AgentTicketOwner###ServiceMandatory

Description: Sets if service must be selected by the agent.

564

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Agent::Ticket::ViewOwner

$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'ServiceMandatory'}

= '0';

6.44.6.

Ticket::Frontend::AgentTicketOwner###SLAMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets if SLA must be selected by the agent.

Ticket

Frontend::Agent::Ticket::ViewOwner

$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'SLAMandatory'} =

'0';

6.44.7. Ticket::Frontend::AgentTicketOwner###Queue

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the queue in the ticket owner screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewOwner

$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'Queue'} = '0';

6.44.8. Ticket::Frontend::AgentTicketOwner###Owner

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the ticket owner in the ticket owner screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewOwner

$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'Owner'} = '1';

6.44.9.

Ticket::Frontend::AgentTicketOwner###OwnerMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Sets if ticket owner must be selected by the agent.

Ticket

Frontend::Agent::Ticket::ViewOwner

565

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'OwnerMandatory'} =

'1';

6.44.10.

Ticket::Frontend::AgentTicketOwner###Responsible

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the responsible agent of the ticket in the ticket owner screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewOwner

$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'Responsible'} =

'0';

6.44.11. Ticket::Frontend::AgentTicketOwner###State

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If a note is added by an agent, sets the state of the ticket in the ticket owner screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewOwner

$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'State'} = '0';

6.44.12.

Ticket::Frontend::AgentTicketOwner###StateType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the next state of a ticket after adding a note, in the ticket owner screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewOwner

$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'StateType'} = [

'open',

'pending reminder',

'pending auto'

];

6.44.13.

Ticket::Frontend::AgentTicketOwner###StateDefault

Description:

Group:

SubGroup:

Valid:

Defines the default next state of a ticket after adding a note, in the ticket owner screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewOwner

566

Required:

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'StateDefault'} =

'open';

6.44.14. Ticket::Frontend::AgentTicketOwner###Note

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Allows adding notes in the ticket owner screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewOwner

$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'Note'} = '1';

6.44.15.

Ticket::Frontend::AgentTicketOwner###NoteMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets if note must be filled in by the agent.

Ticket

Frontend::Agent::Ticket::ViewOwner

$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'NoteMandatory'} =

'1';

6.44.16.

Ticket::Frontend::AgentTicketOwner###Subject

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the default subject for notes added in the ticket owner screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewOwner

$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'Subject'} =

'$Text{"Owner Update"}!';

6.44.17. Ticket::Frontend::AgentTicketOwner###Body

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the default body text for notes added in the ticket owner screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewOwner

$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'Body'} = '';

567

6.44.18.

Ticket::Frontend::AgentTicketOwner###InvolvedAgent

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a list of all the involved agents on this ticket, in the ticket owner screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewOwner

$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'InvolvedAgent'} =

'0';

6.44.19.

Ticket::Frontend::AgentTicketOwner###InformAgent

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a list of all the possible agents (all agents with note permissions on the queue/ticket) to determine who should be informed about this note, in the ticket owner screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewOwner

$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'InformAgent'} =

'0';

6.44.20.

Ticket::Frontend::AgentTicketOwner###ArticleTypeDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default type of the note in the ticket owner screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewOwner

$Self->{'Ticket::Frontend::AgentTicketOwner'}-

>{'ArticleTypeDefault'} = 'note-internal';

6.44.21.

Ticket::Frontend::AgentTicketOwner###ArticleTypes

Description:

Group:

SubGroup:

Valid:

Required:

Specifies the available note types for this ticket mask. If the option is deselected, ArticleTypeDefault is used and the option is removed from the mask.

Ticket

Frontend::Agent::Ticket::ViewOwner

568

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'ArticleTypes'} =

{

'note-external' => '0',

'note-internal' => '1',

'note-report' => '0'

};

6.44.22.

Ticket::Frontend::AgentTicketOwner###Priority

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows the ticket priority options in the ticket owner screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewOwner

$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'Priority'} = '0';

6.44.23.

Ticket::Frontend::AgentTicketOwner###PriorityDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default ticket priority in the ticket owner screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewOwner

$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'PriorityDefault'}

= '3 normal';

6.44.24. Ticket::Frontend::AgentTicketOwner###Title

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows the title fields in the ticket owner screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewOwner

$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'Title'} = '0';

6.44.25.

Ticket::Frontend::AgentTicketOwner###HistoryType

Description:

Group:

SubGroup:

Valid:

Required:

Defines the history type for the ticket owner screen action, which gets used for ticket history in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewOwner

569

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'HistoryType'} =

'AddNote';

6.44.26.

Ticket::Frontend::AgentTicketOwner###HistoryComment

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the history comment for the ticket owner screen action, which gets used for ticket history in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewOwner

$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'HistoryComment'} =

'%%Owner';

6.44.27.

Ticket::Frontend::AgentTicketOwner###DynamicField

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Dynamic fields shown in the ticket owner screen of the agent interface. Possible settings: 0 = Disabled, 1 = Enabled, 2 = Enabled and required.

Ticket

Frontend::Agent::Ticket::ViewOwner

$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'DynamicField'} =

{};

6.44.28.

Ticket::Frontend::AgentTicketOwner###RichTextWidth

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the width for the rich text editor component for this screen.

Enter number (pixels) or percent value (relative).

Ticket

Frontend::Agent::Ticket::ViewOwner

$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'RichTextWidth'} =

'620';

6.44.29.

Ticket::Frontend::AgentTicketOwner###RichTextHeight

Description:

Group:

SubGroup:

Valid:

Defines the height for the rich text editor component for this screen. Enter number (pixels) or percent value (relative).

Ticket

Frontend::Agent::Ticket::ViewOwner

570

Required:

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketOwner'}->{'RichTextHeight'} =

'100';

6.45. Frontend::Agent::Ticket::ViewPending

6.45.1.

Ticket::Frontend::AgentTicketPending###Permission

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Required permissions to use the ticket pending screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPending

$Self->{'Ticket::Frontend::AgentTicketPending'}->{'Permission'} =

'pending';

6.45.2.

Ticket::Frontend::AgentTicketPending###RequiredLock

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines if a ticket lock is required in the ticket pending screen of a zoomed ticket in the agent interface (if the ticket isn't locked yet, the ticket gets locked and the current agent will be set automatically as its owner).

Ticket

Frontend::Agent::Ticket::ViewPending

$Self->{'Ticket::Frontend::AgentTicketPending'}->{'RequiredLock'} =

'1';

6.45.3.

Ticket::Frontend::AgentTicketPending###TicketType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the ticket type in the ticket pending screen of a zoomed ticket in the agent interface (Ticket::Type needs to be activated).

Ticket

Frontend::Agent::Ticket::ViewPending

$Self->{'Ticket::Frontend::AgentTicketPending'}->{'TicketType'} =

'0';

6.45.4.

Ticket::Frontend::AgentTicketPending###Service

Description: Sets the service in the ticket pending screen of a zoomed ticket in the agent interface (Ticket::Service needs to be activated).

571

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Agent::Ticket::ViewPending

$Self->{'Ticket::Frontend::AgentTicketPending'}->{'Service'} =

'0';

6.45.5.

Ticket::Frontend::AgentTicketPending###ServiceMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets if service must be selected by the agent.

Ticket

Frontend::Agent::Ticket::ViewPending

$Self->{'Ticket::Frontend::AgentTicketPending'}-

>{'ServiceMandatory'} = '0';

6.45.6.

Ticket::Frontend::AgentTicketPending###SLAMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets if SLA must be selected by the agent.

Ticket

Frontend::Agent::Ticket::ViewPending

$Self->{'Ticket::Frontend::AgentTicketPending'}->{'SLAMandatory'} =

'0';

6.45.7.

Ticket::Frontend::AgentTicketPending###Queue

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the queue in the ticket pending screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPending

$Self->{'Ticket::Frontend::AgentTicketPending'}->{'Queue'} = '0';

6.45.8.

Ticket::Frontend::AgentTicketPending###Owner

Description:

Group:

SubGroup:

Sets the ticket owner in the ticket pending screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPending

572

Valid:

Required:

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketPending'}->{'Owner'} = '0';

6.45.9.

Ticket::Frontend::AgentTicketPending###OwnerMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets if ticket owner must be selected by the agent.

Ticket

Frontend::Agent::Ticket::ViewPending

$Self->{'Ticket::Frontend::AgentTicketPending'}->{'OwnerMandatory'}

= '0';

6.45.10.

Ticket::Frontend::AgentTicketPending###Responsible

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the responsible agent of the ticket in the ticket pending screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPending

$Self->{'Ticket::Frontend::AgentTicketPending'}->{'Responsible'} =

'0';

6.45.11.

Ticket::Frontend::AgentTicketPending###State

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If a note is added by an agent, sets the state of the ticket in the ticket pending screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPending

$Self->{'Ticket::Frontend::AgentTicketPending'}->{'State'} = '1';

6.45.12.

Ticket::Frontend::AgentTicketPending###StateType

Description:

Group:

SubGroup:

Valid:

Required:

Defines the next state of a ticket after adding a note, in the ticket pending screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPending

573

Config-Setting:

6.45.13.

Ticket::Frontend::AgentTicketPending###StateDefault

Description:

$Self->{'Ticket::Frontend::AgentTicketPending'}->{'StateType'} = [

'pending reminder',

'pending auto'

];

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default next state of a ticket after adding a note, in the ticket pending screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPending

$Self->{'Ticket::Frontend::AgentTicketPending'}->{'StateDefault'} =

'pending reminder';

6.45.14.

Ticket::Frontend::AgentTicketPending###Note

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Allows adding notes in the ticket pending screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPending

$Self->{'Ticket::Frontend::AgentTicketPending'}->{'Note'} = '1';

6.45.15.

Ticket::Frontend::AgentTicketPending###NoteMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets if note must be filled in by the agent.

Ticket

Frontend::Agent::Ticket::ViewPending

$Self->{'Ticket::Frontend::AgentTicketPending'}->{'NoteMandatory'}

= '1';

6.45.16.

Ticket::Frontend::AgentTicketPending###Subject

Description:

Group:

SubGroup:

Valid:

Required:

Sets the default subject for notes added in the ticket pending screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPending

574

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketPending'}->{'Subject'} =

'$Text{"Pending"}!';

6.45.17.

Ticket::Frontend::AgentTicketPending###Body

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the default body text for notes added in the ticket pending screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPending

$Self->{'Ticket::Frontend::AgentTicketPending'}->{'Body'} = '';

6.45.18.

Ticket::Frontend::AgentTicketPending###InvolvedAgent

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a list of all the involved agents on this ticket, in the ticket pending screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPending

$Self->{'Ticket::Frontend::AgentTicketPending'}->{'InvolvedAgent'}

= '0';

6.45.19.

Ticket::Frontend::AgentTicketPending###InformAgent

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a list of all the possible agents (all agents with note permissions on the queue/ticket) to determine who should be informed about this note, in the ticket pending screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPending

$Self->{'Ticket::Frontend::AgentTicketPending'}->{'InformAgent'} =

'0';

6.45.20.

Ticket::Frontend::AgentTicketPending###ArticleTypeDefault

Description:

Group:

SubGroup:

Valid:

Defines the default type of the note in the ticket pending screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPending

575

Required:

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketPending'}-

>{'ArticleTypeDefault'} = 'note-internal';

6.45.21.

Ticket::Frontend::AgentTicketPending###ArticleTypes

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the available note types for this ticket mask. If the option is deselected, ArticleTypeDefault is used and the option is removed from the mask.

Ticket

Frontend::Agent::Ticket::ViewPending

$Self->{'Ticket::Frontend::AgentTicketPending'}->{'ArticleTypes'} =

{

'note-external' => '0',

'note-internal' => '1',

'note-report' => '0'

};

6.45.22.

Ticket::Frontend::AgentTicketPending###Priority

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows the ticket priority options in the ticket pending screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPending

$Self->{'Ticket::Frontend::AgentTicketPending'}->{'Priority'} =

'0';

6.45.23.

Ticket::Frontend::AgentTicketPending###PriorityDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default ticket priority in the ticket pending screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPending

$Self->{'Ticket::Frontend::AgentTicketPending'}-

>{'PriorityDefault'} = '3 normal';

6.45.24.

Ticket::Frontend::AgentTicketPending###Title

Description: Shows the title fields in the ticket pending screen of a zoomed ticket in the agent interface.

576

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Agent::Ticket::ViewPending

$Self->{'Ticket::Frontend::AgentTicketPending'}->{'Title'} = '0';

6.45.25.

Ticket::Frontend::AgentTicketPending###HistoryType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the history type for the ticket pending screen action, which gets used for ticket history in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPending

$Self->{'Ticket::Frontend::AgentTicketPending'}->{'HistoryType'} =

'AddNote';

6.45.26.

Ticket::Frontend::AgentTicketPending###HistoryComment

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the history comment for the ticket pending screen action, which gets used for ticket history in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPending

$Self->{'Ticket::Frontend::AgentTicketPending'}->{'HistoryComment'}

= '%%Pending';

6.45.27.

Ticket::Frontend::AgentTicketPending###DynamicField

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Dynamic fields shown in the ticket pending screen of the agent interface. Possible settings: 0 = Disabled, 1 = Enabled, 2 = Enabled and required.

Ticket

Frontend::Agent::Ticket::ViewPending

$Self->{'Ticket::Frontend::AgentTicketPending'}->{'DynamicField'} =

{};

6.45.28.

Ticket::Frontend::AgentTicketPending###RichTextWidth

Description: Defines the width for the rich text editor component for this screen.

Enter number (pixels) or percent value (relative).

577

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Agent::Ticket::ViewPending

$Self->{'Ticket::Frontend::AgentTicketPending'}->{'RichTextWidth'}

= '620';

6.45.29.

Ticket::Frontend::AgentTicketPending###RichTextHeight

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the height for the rich text editor component for this screen. Enter number (pixels) or percent value (relative).

Ticket

Frontend::Agent::Ticket::ViewPending

$Self->{'Ticket::Frontend::AgentTicketPending'}->{'RichTextHeight'}

= '100';

6.46.

Frontend::Agent::Ticket::ViewPhoneInbound

6.46.1.

Ticket::Frontend::AgentTicketPhoneInbound###Permission

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Required permissions to use the ticket phone inbound screen in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPhoneInbound

$Self->{'Ticket::Frontend::AgentTicketPhoneInbound'}-

>{'Permission'} = 'phone';

6.46.2.

Ticket::Frontend::AgentTicketPhoneInbound###RequiredLock

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines if a ticket lock is required in the ticket phone inbound screen of the agent interface (if the ticket isn't locked yet, the ticket gets locked and the current agent will be set automatically as its owner).

Ticket

Frontend::Agent::Ticket::ViewPhoneInbound

$Self->{'Ticket::Frontend::AgentTicketPhoneInbound'}-

>{'RequiredLock'} = '0';

578

6.46.3.

Ticket::Frontend::AgentTicketPhoneInbound###ArticleType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default type of the note in the ticket phone inbound screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPhoneInbound

$Self->{'Ticket::Frontend::AgentTicketPhoneInbound'}-

>{'ArticleType'} = 'phone';

6.46.4.

Ticket::Frontend::AgentTicketPhoneInbound###SenderType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default sender type for phone tickets in the ticket phone inbound screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPhoneInbound

$Self->{'Ticket::Frontend::AgentTicketPhoneInbound'}-

>{'SenderType'} = 'customer';

6.46.5.

Ticket::Frontend::AgentTicketPhoneInbound###Subject

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default subject for phone tickets in the ticket phone inbound screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPhoneInbound

$Self->{'Ticket::Frontend::AgentTicketPhoneInbound'}->{'Subject'} =

'$Text{"Phone call"}!';

6.46.6.

Ticket::Frontend::AgentTicketPhoneInbound###Body

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default note body text for phone tickets in the ticket phone inbound screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPhoneInbound

$Self->{'Ticket::Frontend::AgentTicketPhoneInbound'}->{'Body'} =

'';

579

6.46.7.

Ticket::Frontend::AgentTicketPhoneInbound###State

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default ticket next state after adding a phone note in the ticket phone inbound screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPhoneInbound

$Self->{'Ticket::Frontend::AgentTicketPhoneInbound'}->{'State'} =

'open';

6.46.8.

Ticket::Frontend::AgentTicketPhoneInbound###StateType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Next possible ticket states after adding a phone note in the ticket phone inbound screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPhoneInbound

$Self->{'Ticket::Frontend::AgentTicketPhoneInbound'}->{'StateType'}

= [

'open',

'pending auto',

'pending reminder',

'closed'

];

6.46.9.

Ticket::Frontend::AgentTicketPhoneInbound###HistoryType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the history type for the ticket phone inbound screen action, which gets used for ticket history in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPhoneInbound

$Self->{'Ticket::Frontend::AgentTicketPhoneInbound'}-

>{'HistoryType'} = 'PhoneCallCustomer';

6.46.10.

Ticket::Frontend::AgentTicketPhoneInbound###HistoryComment

Description:

Group:

SubGroup:

Valid:

Required:

Defines the history comment for the ticket phone inbound screen action, which gets used for ticket history in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPhoneInbound

580

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketPhoneInbound'}-

>{'HistoryComment'} = '';

6.46.11.

Ticket::Frontend::AgentTicketPhoneInbound###DynamicField

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Dynamic fields shown in the ticket phone inbound screen of the agent interface. Possible settings: 0 = Disabled, 1 = Enabled, 2 =

Enabled and required.

Ticket

Frontend::Agent::Ticket::ViewPhoneInbound

$Self->{'Ticket::Frontend::AgentTicketPhoneInbound'}-

>{'DynamicField'} = {};

6.46.12.

Ticket::Frontend::AgentTicketPhoneInbound###RichTextWidth

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the width for the rich text editor component for this screen.

Enter number (pixels) or percent value (relative).

Ticket

Frontend::Agent::Ticket::ViewPhoneInbound

$Self->{'Ticket::Frontend::AgentTicketPhoneInbound'}-

>{'RichTextWidth'} = '475';

6.46.13.

Ticket::Frontend::AgentTicketPhoneInbound###RichTextHeight

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the height for the rich text editor component for this screen. Enter number (pixels) or percent value (relative).

Ticket

Frontend::Agent::Ticket::ViewPhoneInbound

$Self->{'Ticket::Frontend::AgentTicketPhoneInbound'}-

>{'RichTextHeight'} = '200';

6.47. Frontend::Agent::Ticket::ViewPhoneNew

6.47.1.

Ticket::Frontend::AgentTicketPhone###Priority

Description:

Group:

SubGroup:

Sets the default priority for new phone tickets in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPhoneNew

581

Valid:

Required:

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketPhone'}->{'Priority'} = '3

normal';

6.47.2.

Ticket::Frontend::AgentTicketPhone###ArticleType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the default article type for new phone tickets in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPhoneNew

$Self->{'Ticket::Frontend::AgentTicketPhone'}->{'ArticleType'} =

'phone';

6.47.3.

Ticket::Frontend::AgentTicketPhone###SenderType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the default sender type for new phone ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPhoneNew

$Self->{'Ticket::Frontend::AgentTicketPhone'}->{'SenderType'} =

'customer';

6.47.4.

Ticket::Frontend::AgentTicketPhone::AllowMultipleFrom

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Controls if more than one from entry can be set in the new phone ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPhoneNew

$Self->{'Ticket::Frontend::AgentTicketPhone::AllowMultipleFrom'} =

'1';

6.47.5.

Ticket::Frontend::AgentTicketPhone###Subject

Description:

Group:

SubGroup:

Valid:

Sets the default subject for new phone tickets (e.g. 'Phone call') in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPhoneNew

582

Required:

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketPhone'}->{'Subject'} = '';

6.47.6. Ticket::Frontend::AgentTicketPhone###Body

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the default note text for new telephone tickets. E.g 'New ticket via call' in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPhoneNew

$Self->{'Ticket::Frontend::AgentTicketPhone'}->{'Body'} = '';

6.47.7.

Ticket::Frontend::AgentTicketPhone###StateDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the default next state for new phone tickets in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPhoneNew

$Self->{'Ticket::Frontend::AgentTicketPhone'}->{'StateDefault'} =

'open';

6.47.8.

Ticket::Frontend::AgentTicketPhone###StateType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Determines the next possible ticket states, after the creation of a new phone ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPhoneNew

$Self->{'Ticket::Frontend::AgentTicketPhone'}->{'StateType'} = [

'open',

'pending auto',

'pending reminder',

'closed'

];

6.47.9.

Ticket::Frontend::AgentTicketPhone###HistoryType

Description:

Group:

SubGroup:

Valid:

Required:

Defines the history type for the phone ticket screen action, which gets used for ticket history in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPhoneNew

583

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketPhone'}->{'HistoryType'} =

'PhoneCallCustomer';

6.47.10.

Ticket::Frontend::AgentTicketPhone###HistoryComment

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the history comment for the phone ticket screen action, which gets used for ticket history in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPhoneNew

$Self->{'Ticket::Frontend::AgentTicketPhone'}->{'HistoryComment'} =

'';

6.47.11.

Ticket::Frontend::AgentTicketPhone###SplitLinkType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the default link type of splitted tickets in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPhoneNew

$Self->{'Ticket::Frontend::AgentTicketPhone'}->{'SplitLinkType'} =

{

'Direction' => 'Target',

'LinkType' => 'ParentChild'

};

6.47.12.

Ticket::Frontend::AgentTicketPhone###ServiceMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets if service must be selected by the agent.

Ticket

Frontend::Agent::Ticket::ViewPhoneNew

$Self->{'Ticket::Frontend::AgentTicketPhone'}->{'ServiceMandatory'}

= '0';

6.47.13.

Ticket::Frontend::AgentTicketPhone###SLAMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets if SLA must be selected by the agent.

Ticket

Frontend::Agent::Ticket::ViewPhoneNew

$Self->{'Ticket::Frontend::AgentTicketPhone'}->{'SLAMandatory'} =

'0';

584

6.47.14.

Ticket::Frontend::AgentTicketPhone###DynamicField

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Dynamic fields shown in the ticket phone screen of the agent interface. Possible settings: 0 = Disabled, 1 = Enabled, 2 = Enabled and required.

Ticket

Frontend::Agent::Ticket::ViewPhoneNew

$Self->{'Ticket::Frontend::AgentTicketPhone'}->{'DynamicField'} =

{};

6.47.15.

Ticket::Frontend::AgentTicketPhone###RichTextWidth

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the width for the rich text editor component for this screen.

Enter number (pixels) or percent value (relative).

Ticket

Frontend::Agent::Ticket::ViewPhoneNew

$Self->{'Ticket::Frontend::AgentTicketPhone'}->{'RichTextWidth'} =

'620';

6.47.16.

Ticket::Frontend::AgentTicketPhone###RichTextHeight

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the height for the rich text editor component for this screen. Enter number (pixels) or percent value (relative).

Ticket

Frontend::Agent::Ticket::ViewPhoneNew

$Self->{'Ticket::Frontend::AgentTicketPhone'}->{'RichTextHeight'} =

'320';

6.48.

Frontend::Agent::Ticket::ViewPhoneOutbound

6.48.1.

Ticket::Frontend::AgentTicketPhoneOutbound###Permission

Description:

Group:

SubGroup:

Valid:

Required permissions to use the ticket phone outbound screen in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPhoneOutbound

585

Required:

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketPhoneOutbound'}-

>{'Permission'} = 'phone';

6.48.2.

Ticket::Frontend::AgentTicketPhoneOutbound###RequiredLock

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines if a ticket lock is required in the ticket phone outbound screen of the agent interface (if the ticket isn't locked yet, the ticket gets locked and the current agent will be set automatically as its owner).

Ticket

Frontend::Agent::Ticket::ViewPhoneOutbound

$Self->{'Ticket::Frontend::AgentTicketPhoneOutbound'}-

>{'RequiredLock'} = '1';

6.48.3.

Ticket::Frontend::AgentTicketPhoneOutbound###ArticleType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default type of the note in the ticket phone outbound screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPhoneOutbound

$Self->{'Ticket::Frontend::AgentTicketPhoneOutbound'}-

>{'ArticleType'} = 'phone';

6.48.4.

Ticket::Frontend::AgentTicketPhoneOutbound###SenderType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default sender type for phone tickets in the ticket phone outbound screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPhoneOutbound

$Self->{'Ticket::Frontend::AgentTicketPhoneOutbound'}-

>{'SenderType'} = 'agent';

6.48.5.

Ticket::Frontend::AgentTicketPhoneOutbound###Subject

Description:

Group:

SubGroup:

Defines the default subject for phone tickets in the ticket phone outbound screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPhoneOutbound

586

Valid:

Required:

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketPhoneOutbound'}->{'Subject'}

= '$Text{"Phone call"}!';

6.48.6.

Ticket::Frontend::AgentTicketPhoneOutbound###Body

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default note body text for phone tickets in the ticket phone outbound screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPhoneOutbound

$Self->{'Ticket::Frontend::AgentTicketPhoneOutbound'}->{'Body'} =

'';

6.48.7.

Ticket::Frontend::AgentTicketPhoneOutbound###State

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default ticket next state after adding a phone note in the ticket phone outbound screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPhoneOutbound

$Self->{'Ticket::Frontend::AgentTicketPhoneOutbound'}->{'State'} =

'closed successful';

6.48.8.

Ticket::Frontend::AgentTicketPhoneOutbound###StateType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Next possible ticket states after adding a phone note in the ticket phone outbound screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPhoneOutbound

$Self->{'Ticket::Frontend::AgentTicketPhoneOutbound'}-

>{'StateType'} = [

'open',

'pending auto',

'pending reminder',

'closed'

];

6.48.9.

Ticket::Frontend::AgentTicketPhoneOutbound###HistoryType

Description: Defines the history type for the ticket phone outbound screen action, which gets used for ticket history in the agent interface.

587

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Agent::Ticket::ViewPhoneOutbound

$Self->{'Ticket::Frontend::AgentTicketPhoneOutbound'}-

>{'HistoryType'} = 'PhoneCallAgent';

6.48.10.

Ticket::Frontend::AgentTicketPhoneOutbound###HistoryComment

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the history comment for the ticket phone outbound screen action, which gets used for ticket history in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPhoneOutbound

$Self->{'Ticket::Frontend::AgentTicketPhoneOutbound'}-

>{'HistoryComment'} = '';

6.48.11.

Ticket::Frontend::AgentTicketPhoneOutbound###DynamicField

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Dynamic fields shown in the ticket phone outbound screen of the agent interface. Possible settings: 0 = Disabled, 1 = Enabled, 2 =

Enabled and required.

Ticket

Frontend::Agent::Ticket::ViewPhoneOutbound

$Self->{'Ticket::Frontend::AgentTicketPhoneOutbound'}-

>{'DynamicField'} = {};

6.48.12.

Ticket::Frontend::AgentTicketPhoneOutbound###RichTextWidth

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the width for the rich text editor component for this screen.

Enter number (pixels) or percent value (relative).

Ticket

Frontend::Agent::Ticket::ViewPhoneOutbound

$Self->{'Ticket::Frontend::AgentTicketPhoneOutbound'}-

>{'RichTextWidth'} = '475';

6.48.13.

Ticket::Frontend::AgentTicketPhoneOutbound###RichTextHeight

Description: Defines the height for the rich text editor component for this screen. Enter number (pixels) or percent value (relative).

588

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Agent::Ticket::ViewPhoneOutbound

$Self->{'Ticket::Frontend::AgentTicketPhoneOutbound'}-

>{'RichTextHeight'} = '200';

6.49. Frontend::Agent::Ticket::ViewPrint

6.49.1.

Ticket::Frontend::AgentTicketPrint###DynamicField

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Dynamic fields shown in the ticket print screen of the agent interface. Possible settings: 0 = Disabled, 1 = Enabled.

Ticket

Frontend::Agent::Ticket::ViewPrint

$Self->{'Ticket::Frontend::AgentTicketPrint'}->{'DynamicField'} =

{};

6.50. Frontend::Agent::Ticket::ViewPriority

6.50.1.

Ticket::Frontend::AgentTicketPriority###Permission

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Required permissions to use the ticket priority screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPriority

$Self->{'Ticket::Frontend::AgentTicketPriority'}->{'Permission'} =

'priority';

6.50.2.

Ticket::Frontend::AgentTicketPriority###RequiredLock

Description:

Group:

SubGroup:

Valid:

Required:

Defines if a ticket lock is required in the ticket priority screen of a zoomed ticket in the agent interface (if the ticket isn't locked yet, the ticket gets locked and the current agent will be set automatically as its owner).

Ticket

Frontend::Agent::Ticket::ViewPriority

589

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketPriority'}->{'RequiredLock'}

= '1';

6.50.3.

Ticket::Frontend::AgentTicketPriority###TicketType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the ticket type in the ticket priority screen of a zoomed ticket in the agent interface (Ticket::Type needs to be activated).

Ticket

Frontend::Agent::Ticket::ViewPriority

$Self->{'Ticket::Frontend::AgentTicketPriority'}->{'TicketType'} =

'0';

6.50.4.

Ticket::Frontend::AgentTicketPriority###Service

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the service in the ticket priority screen of a zoomed ticket in the agent interface (Ticket::Service needs to be activated).

Ticket

Frontend::Agent::Ticket::ViewPriority

$Self->{'Ticket::Frontend::AgentTicketPriority'}->{'Service'} =

'0';

6.50.5.

Ticket::Frontend::AgentTicketPriority###ServiceMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets if service must be selected by the agent.

Ticket

Frontend::Agent::Ticket::ViewPriority

$Self->{'Ticket::Frontend::AgentTicketPriority'}-

>{'ServiceMandatory'} = '0';

6.50.6.

Ticket::Frontend::AgentTicketPriority###SLAMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Sets if SLA must be selected by the agent.

Ticket

Frontend::Agent::Ticket::ViewPriority

590

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketPriority'}->{'SLAMandatory'}

= '0';

6.50.7.

Ticket::Frontend::AgentTicketPriority###Queue

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the queue in the ticket priority screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPriority

$Self->{'Ticket::Frontend::AgentTicketPriority'}->{'Queue'} = '0';

6.50.8.

Ticket::Frontend::AgentTicketPriority###Owner

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the ticket owner in the ticket priority screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPriority

$Self->{'Ticket::Frontend::AgentTicketPriority'}->{'Owner'} = '0';

6.50.9.

Ticket::Frontend::AgentTicketPriority###OwnerMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets if ticket owner must be selected by the agent.

Ticket

Frontend::Agent::Ticket::ViewPriority

$Self->{'Ticket::Frontend::AgentTicketPriority'}-

>{'OwnerMandatory'} = '0';

6.50.10.

Ticket::Frontend::AgentTicketPriority###Responsible

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the responsible agent of the ticket in the ticket priority screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPriority

$Self->{'Ticket::Frontend::AgentTicketPriority'}->{'Responsible'} =

'0';

591

6.50.11.

Ticket::Frontend::AgentTicketPriority###State

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If a note is added by an agent, sets the state of the ticket in the ticket priority screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPriority

$Self->{'Ticket::Frontend::AgentTicketPriority'}->{'State'} = '0';

6.50.12.

Ticket::Frontend::AgentTicketPriority###StateType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the next state of a ticket after adding a note, in the ticket priority screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPriority

$Self->{'Ticket::Frontend::AgentTicketPriority'}->{'StateType'} =

[

'open',

'pending reminder',

'pending auto'

];

6.50.13.

Ticket::Frontend::AgentTicketPriority###StateDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default next state of a ticket after adding a note, in the ticket priority screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPriority

$Self->{'Ticket::Frontend::AgentTicketPriority'}->{'StateDefault'}

= 'open';

6.50.14. Ticket::Frontend::AgentTicketPriority###Note

Description:

Group:

SubGroup:

Valid:

Required:

Allows adding notes in the ticket priority screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPriority

592

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketPriority'}->{'Note'} = '1';

6.50.15.

Ticket::Frontend::AgentTicketPriority###NoteMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets if note must be filled in by the agent.

Ticket

Frontend::Agent::Ticket::ViewPriority

$Self->{'Ticket::Frontend::AgentTicketPriority'}->{'NoteMandatory'}

= '1';

6.50.16.

Ticket::Frontend::AgentTicketPriority###Subject

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the default subject for notes added in the ticket priority screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPriority

$Self->{'Ticket::Frontend::AgentTicketPriority'}->{'Subject'} =

'$Text{"Priority Update"}!';

6.50.17.

Ticket::Frontend::AgentTicketPriority###Body

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the default body text for notes added in the ticket priority screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPriority

$Self->{'Ticket::Frontend::AgentTicketPriority'}->{'Body'} = '';

6.50.18.

Ticket::Frontend::AgentTicketPriority###InvolvedAgent

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a list of all the involved agents on this ticket, in the ticket priority screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPriority

$Self->{'Ticket::Frontend::AgentTicketPriority'}->{'InvolvedAgent'}

= '0';

593

6.50.19.

Ticket::Frontend::AgentTicketPriority###InformAgent

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a list of all the possible agents (all agents with note permissions on the queue/ticket) to determine who should be informed about this note, in the ticket priority screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPriority

$Self->{'Ticket::Frontend::AgentTicketPriority'}->{'InformAgent'} =

'0';

6.50.20.

Ticket::Frontend::AgentTicketPriority###ArticleTypeDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default type of the note in the ticket priority screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPriority

$Self->{'Ticket::Frontend::AgentTicketPriority'}-

>{'ArticleTypeDefault'} = 'note-internal';

6.50.21.

Ticket::Frontend::AgentTicketPriority###ArticleTypes

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the available note types for this ticket mask. If the option is deselected, ArticleTypeDefault is used and the option is removed from the mask.

Ticket

Frontend::Agent::Ticket::ViewPriority

$Self->{'Ticket::Frontend::AgentTicketPriority'}->{'ArticleTypes'}

= {

'note-external' => '0',

'note-internal' => '1',

'note-report' => '0'

};

6.50.22.

Ticket::Frontend::AgentTicketPriority###Priority

Description:

Group:

SubGroup:

Shows the ticket priority options in the ticket priority screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPriority

594

Valid:

Required:

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketPriority'}->{'Priority'} =

'1';

6.50.23.

Ticket::Frontend::AgentTicketPriority###PriorityDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default ticket priority in the ticket priority screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPriority

$Self->{'Ticket::Frontend::AgentTicketPriority'}-

>{'PriorityDefault'} = '3 normal';

6.50.24. Ticket::Frontend::AgentTicketPriority###Title

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows the title fields in the ticket priority screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPriority

$Self->{'Ticket::Frontend::AgentTicketPriority'}->{'Title'} = '0';

6.50.25.

Ticket::Frontend::AgentTicketPriority###HistoryType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the history type for the ticket priority screen action, which gets used for ticket history in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPriority

$Self->{'Ticket::Frontend::AgentTicketPriority'}->{'HistoryType'} =

'AddNote';

6.50.26.

Ticket::Frontend::AgentTicketPriority###HistoryComment

Description:

Group:

SubGroup:

Valid:

Defines the history comment for the ticket priority screen action, which gets used for ticket history in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewPriority

595

Required:

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketPriority'}-

>{'HistoryComment'} = '%%Priority';

6.50.27.

Ticket::Frontend::AgentTicketPriority###DynamicField

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Dynamic fields shown in the ticket priority screen of the agent interface. Possible settings: 0 = Disabled, 1 = Enabled, 2 = Enabled and required.

Ticket

Frontend::Agent::Ticket::ViewPriority

$Self->{'Ticket::Frontend::AgentTicketPriority'}->{'DynamicField'}

= {};

6.50.28.

Ticket::Frontend::AgentTicketPriority###RichTextWidth

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the width for the rich text editor component for this screen.

Enter number (pixels) or percent value (relative).

Ticket

Frontend::Agent::Ticket::ViewPriority

$Self->{'Ticket::Frontend::AgentTicketPriority'}->{'RichTextWidth'}

= '620';

6.50.29.

Ticket::Frontend::AgentTicketPriority###RichTextHeight

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the height for the rich text editor component for this screen. Enter number (pixels) or percent value (relative).

Ticket

Frontend::Agent::Ticket::ViewPriority

$Self->{'Ticket::Frontend::AgentTicketPriority'}-

>{'RichTextHeight'} = '100';

6.51. Frontend::Agent::Ticket::ViewQueue

6.51.1.

Ticket::Frontend::AgentTicketQueue###StripEmptyLines

Description:

Group:

Strips empty lines on the ticket preview in the queue view.

Ticket

596

SubGroup:

Valid:

Required:

Config-Setting:

Frontend::Agent::Ticket::ViewQueue

$Self->{'Ticket::Frontend::AgentTicketQueue'}->{'StripEmptyLines'}

= '0';

6.51.2.

Ticket::Frontend::AgentTicketQueue###ViewAllPossibleTickets

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows all both ro and rw queues in the queue view.

Ticket

Frontend::Agent::Ticket::ViewQueue

$Self->{'Ticket::Frontend::AgentTicketQueue'}-

>{'ViewAllPossibleTickets'} = '0';

6.51.3.

Ticket::Frontend::AgentTicketQueue###HighlightAge1

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the age in minutes (first level) for highlighting queues that contain untouched tickets.

Ticket

Frontend::Agent::Ticket::ViewQueue

$Self->{'Ticket::Frontend::AgentTicketQueue'}->{'HighlightAge1'} =

'1440';

6.51.4.

Ticket::Frontend::AgentTicketQueue###HighlightAge2

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the age in minutes (second level) for highlighting queues that contain untouched tickets.

Ticket

Frontend::Agent::Ticket::ViewQueue

$Self->{'Ticket::Frontend::AgentTicketQueue'}->{'HighlightAge2'} =

'2880';

6.51.5. Ticket::Frontend::AgentTicketQueue###Blink

Description:

Group:

SubGroup:

Valid:

Activates a blinking mechanism of the queue that contains the oldest ticket.

Ticket

Frontend::Agent::Ticket::ViewQueue

597

Required:

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketQueue'}->{'Blink'} = '1';

6.51.6.

Ticket::Frontend::AgentTicketQueue###QueueSort

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sorts the tickets (ascendingly or descendingly) when a single queue is selected in the queue view and after the tickets are sorted by priority. Values: 0 = ascending (oldest on top, default), 1 = descending (youngest on top). Use the QueueID for the key and

0 or 1 for value.

Ticket

Frontend::Agent::Ticket::ViewQueue

$Self->{'Ticket::Frontend::AgentTicketQueue'}->{'QueueSort'} = {

'3' => '0',

'7' => '1'

};

6.51.7.

Ticket::Frontend::AgentTicketQueue###SortBy::Default

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default sort criteria for all queues displayed in the queue view.

Ticket

Frontend::Agent::Ticket::ViewQueue

$Self->{'Ticket::Frontend::AgentTicketQueue'}->{'SortBy::Default'}

= 'Age';

6.51.8.

Ticket::Frontend::AgentTicketQueue###PreSort::ByPriority

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines if a pre-sorting by priority should be done in the queue view.

Ticket

Frontend::Agent::Ticket::ViewQueue

$Self->{'Ticket::Frontend::AgentTicketQueue'}-

>{'PreSort::ByPriority'} = '1';

6.51.9.

Ticket::Frontend::AgentTicketQueue###Order::Default

Description: Defines the default sort order for all queues in the queue view, after priority sort.

598

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Agent::Ticket::ViewQueue

$Self->{'Ticket::Frontend::AgentTicketQueue'}->{'Order::Default'} =

'Up';

6.51.10.

Ticket::Frontend::AgentTicketQueue###DefaultColumns

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Group:

SubGroup:

Valid:

Required:

Columns that can be filtered in the queue view of the agent interface. Possible settings: 0 = Disabled, 1 = Available, 2 = Enabled by default. Note: Only Ticket attributes and Dynamic Fields

(DynamicField_NameX) are allowed.

Ticket

Frontend::Agent::Ticket::ViewQueue

$Self->{'Ticket::Frontend::AgentTicketQueue'}->{'DefaultColumns'} =

{

'Age' => '2',

'Changed' => '1',

'CustomerID' => '2',

'CustomerName' => '1',

'CustomerUserID' => '1',

'EscalationResponseTime' => '1',

'EscalationSolutionTime' => '1',

'EscalationTime' => '1',

'EscalationUpdateTime' => '1',

'Lock' => '2',

'Owner' => '2',

'PendingTime' => '1',

'Priority' => '1',

'Queue' => '2',

'Responsible' => '1',

'SLA' => '1',

'Service' => '1',

'State' => '2',

'TicketNumber' => '2',

'Title' => '2',

'Type' => '1'

};

6.52.

Frontend::Agent::Ticket::ViewResponsible

6.52.1.

Ticket::Frontend::AgentTicketResponsibleView###SortBy::Default

Description: Defines the default ticket attribute for ticket sorting in the responsible view of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewResponsible

599

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketResponsibleView'}-

>{'SortBy::Default'} = 'Age';

6.52.2.

Ticket::Frontend::AgentTicketResponsibleView###Order::Default

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default ticket order in the responsible view of the agent interface. Up: oldest on top. Down: latest on top.

Ticket

Frontend::Agent::Ticket::ViewResponsible

$Self->{'Ticket::Frontend::AgentTicketResponsibleView'}-

>{'Order::Default'} = 'Up';

6.52.3.

Ticket::Frontend::AgentTicketResponsible###Permission

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Required permissions to use the ticket responsible screen in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewResponsible

$Self->{'Ticket::Frontend::AgentTicketResponsible'}->{'Permission'}

= 'responsible';

6.52.4.

Ticket::Frontend::AgentTicketResponsible###RequiredLock

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines if a ticket lock is required in the ticket responsible screen of the agent interface (if the ticket isn't locked yet, the ticket gets locked and the current agent will be set automatically as its owner).

Ticket

Frontend::Agent::Ticket::ViewResponsible

$Self->{'Ticket::Frontend::AgentTicketResponsible'}-

>{'RequiredLock'} = '0';

6.52.5.

Ticket::Frontend::AgentTicketResponsible###TicketType

Description:

Group:

SubGroup:

Valid:

Sets the ticket type in the ticket responsible screen of the agent interface (Ticket::Type needs to be activated).

Ticket

Frontend::Agent::Ticket::ViewResponsible

600

Required:

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketResponsible'}->{'TicketType'}

= '0';

6.52.6.

Ticket::Frontend::AgentTicketResponsible###Service

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the service in the ticket responsible screen of the agent interface (Ticket::Service needs to be activated).

Ticket

Frontend::Agent::Ticket::ViewResponsible

$Self->{'Ticket::Frontend::AgentTicketResponsible'}->{'Service'} =

'0';

6.52.7.

Ticket::Frontend::AgentTicketResponsible###ServiceMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets if service must be selected by the agent.

Ticket

Frontend::Agent::Ticket::ViewResponsible

$Self->{'Ticket::Frontend::AgentTicketResponsible'}-

>{'ServiceMandatory'} = '0';

6.52.8.

Ticket::Frontend::AgentTicketResponsible###SLAMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets if SLA must be selected by the agent.

Ticket

Frontend::Agent::Ticket::ViewResponsible

$Self->{'Ticket::Frontend::AgentTicketResponsible'}-

>{'SLAMandatory'} = '0';

6.52.9.

Ticket::Frontend::AgentTicketResponsible###Queue

Description:

Group:

SubGroup:

Valid:

Required:

Sets the queue in the ticket responsible screen of a zoomed ticket in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewResponsible

601

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketResponsible'}->{'Queue'} =

'0';

6.52.10.

Ticket::Frontend::AgentTicketResponsible###Owner

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the ticket owner in the ticket responsible screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewResponsible

$Self->{'Ticket::Frontend::AgentTicketResponsible'}->{'Owner'} =

'0';

6.52.11.

Ticket::Frontend::AgentTicketResponsible###OwnerMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets if ticket owner must be selected by the agent.

Ticket

Frontend::Agent::Ticket::ViewResponsible

$Self->{'Ticket::Frontend::AgentTicketResponsible'}-

>{'OwnerMandatory'} = '0';

6.52.12.

Ticket::Frontend::AgentTicketResponsible###Responsible

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the responsible agent of the ticket in the ticket responsible screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewResponsible

$Self->{'Ticket::Frontend::AgentTicketResponsible'}-

>{'Responsible'} = '1';

6.52.13.

Ticket::Frontend::AgentTicketResponsible###State

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

If a note is added by an agent, sets the state of a ticket in the ticket responsible screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewResponsible

$Self->{'Ticket::Frontend::AgentTicketResponsible'}->{'State'} =

'0';

602

6.52.14.

Ticket::Frontend::AgentTicketResponsible###StateType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the next state of a ticket after adding a note, in the ticket responsible screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewResponsible

$Self->{'Ticket::Frontend::AgentTicketResponsible'}->{'StateType'}

= [

'open',

'pending reminder',

'pending auto'

];

6.52.15.

Ticket::Frontend::AgentTicketResponsible###StateDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default next state of a ticket after adding a note, in the ticket responsible screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewResponsible

$Self->{'Ticket::Frontend::AgentTicketResponsible'}-

>{'StateDefault'} = 'open';

6.52.16.

Ticket::Frontend::AgentTicketResponsible###Note

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Allows adding notes in the ticket responsible screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewResponsible

$Self->{'Ticket::Frontend::AgentTicketResponsible'}->{'Note'} =

'1';

6.52.17.

Ticket::Frontend::AgentTicketResponsible###NoteMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Sets if note must be filled in by the agent.

Ticket

Frontend::Agent::Ticket::ViewResponsible

603

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketResponsible'}-

>{'NoteMandatory'} = '1';

6.52.18.

Ticket::Frontend::AgentTicketResponsible###Subject

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the default subject for notes added in the ticket responsible screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewResponsible

$Self->{'Ticket::Frontend::AgentTicketResponsible'}->{'Subject'} =

'$Text{"Responsible Update"}!';

6.52.19.

Ticket::Frontend::AgentTicketResponsible###Body

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the default body text for notes added in the ticket responsible screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewResponsible

$Self->{'Ticket::Frontend::AgentTicketResponsible'}->{'Body'} =

'';

6.52.20.

Ticket::Frontend::AgentTicketResponsible###InvolvedAgent

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a list of all the involved agents on this ticket, in the ticket responsible screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewResponsible

$Self->{'Ticket::Frontend::AgentTicketResponsible'}-

>{'InvolvedAgent'} = '0';

6.52.21.

Ticket::Frontend::AgentTicketResponsible###InformAgent

Description:

Group:

SubGroup:

Valid:

Shows a list of all the possible agents (all agents with note permissions on the queue/ticket) to determine who should be informed about this note, in the ticket responsible screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewResponsible

604

Required:

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketResponsible'}-

>{'InformAgent'} = '0';

6.52.22.

Ticket::Frontend::AgentTicketResponsible###ArticleTypeDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default type of the note in the ticket responsible screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewResponsible

$Self->{'Ticket::Frontend::AgentTicketResponsible'}-

>{'ArticleTypeDefault'} = 'note-internal';

6.52.23.

Ticket::Frontend::AgentTicketResponsible###ArticleTypes

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Specifies the available note types for this ticket mask. If the option is deselected, ArticleTypeDefault is used and the option is removed from the mask.

Ticket

Frontend::Agent::Ticket::ViewResponsible

$Self->{'Ticket::Frontend::AgentTicketResponsible'}-

>{'ArticleTypes'} = {

'note-external' => '0',

'note-internal' => '1',

'note-report' => '0'

};

6.52.24.

Ticket::Frontend::AgentTicketResponsible###Priority

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows the ticket priority options in the ticket responsible screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewResponsible

$Self->{'Ticket::Frontend::AgentTicketResponsible'}->{'Priority'} =

'0';

6.52.25.

Ticket::Frontend::AgentTicketResponsible###PriorityDefault

Description:

Group:

Defines the default ticket priority in the ticket responsible screen of the agent interface.

Ticket

605

SubGroup:

Valid:

Required:

Config-Setting:

Frontend::Agent::Ticket::ViewResponsible

$Self->{'Ticket::Frontend::AgentTicketResponsible'}-

>{'PriorityDefault'} = '3 normal';

6.52.26.

Ticket::Frontend::AgentTicketResponsible###Title

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows the title fields in the ticket responsible screen of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewResponsible

$Self->{'Ticket::Frontend::AgentTicketResponsible'}->{'Title'} =

'1';

6.52.27.

Ticket::Frontend::AgentTicketResponsible###HistoryType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the history type for the ticket responsible screen action, which gets used for ticket history in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewResponsible

$Self->{'Ticket::Frontend::AgentTicketResponsible'}-

>{'HistoryType'} = 'AddNote';

6.52.28.

Ticket::Frontend::AgentTicketResponsible###HistoryComment

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the history comment for the ticket responsible screen action, which gets used for ticket history in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewResponsible

$Self->{'Ticket::Frontend::AgentTicketResponsible'}-

>{'HistoryComment'} = '%%Responsible';

6.52.29.

Ticket::Frontend::AgentTicketResponsible###DynamicField

Description:

Group:

Dynamic fields shown in the ticket responsible screen of the agent interface. Possible settings: 0 = Disabled, 1 = Enabled, 2 = Enabled and required.

Ticket

606

SubGroup:

Valid:

Required:

Config-Setting:

Frontend::Agent::Ticket::ViewResponsible

$Self->{'Ticket::Frontend::AgentTicketResponsible'}-

>{'DynamicField'} = {};

6.52.30.

Ticket::Frontend::AgentTicketResponsible###RichTextWidth

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the width for the rich text editor component for this screen.

Enter number (pixels) or percent value (relative).

Ticket

Frontend::Agent::Ticket::ViewResponsible

$Self->{'Ticket::Frontend::AgentTicketResponsible'}-

>{'RichTextWidth'} = '620';

6.52.31.

Ticket::Frontend::AgentTicketResponsible###RichTextHeight

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the height for the rich text editor component for this screen. Enter number (pixels) or percent value (relative).

Ticket

Frontend::Agent::Ticket::ViewResponsible

$Self->{'Ticket::Frontend::AgentTicketResponsible'}-

>{'RichTextHeight'} = '100';

6.52.32.

Ticket::Frontend::AgentTicketResponsibleView###DefaultColumns

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Columns that can be filtered in the responsible view of the agent interface. Possible settings: 0 = Disabled, 1 = Available, 2 = Enabled by default. Note: Only Ticket attributes and Dynamic Fields

(DynamicField_NameX) are allowed.

Ticket

Frontend::Agent::Ticket::ViewResponsible

$Self->{'Ticket::Frontend::AgentTicketResponsibleView'}-

>{'DefaultColumns'} = {

'Age' => '2',

'Changed' => '1',

'CustomerID' => '2',

'CustomerName' => '1',

'CustomerUserID' => '1',

'EscalationResponseTime' => '1',

'EscalationSolutionTime' => '1',

'EscalationTime' => '1',

607

6.53. Frontend::Agent::Ticket::ViewSearch

6.53.1.

Ticket::Frontend::AgentTicketSearch###ExtendedSearchCondition

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

'EscalationUpdateTime' => '1',

'Lock' => '2',

'Owner' => '2',

'PendingTime' => '1',

'Priority' => '1',

'Queue' => '2',

'Responsible' => '1',

'SLA' => '1',

'Service' => '1',

'State' => '2',

'TicketNumber' => '2',

'Title' => '2',

'Type' => '1'

};

Allows extended search conditions in ticket search of the agent interface. With this feature you can search e. g. with this kind of conditions like "(key1&&key2)" or "(key1||key2)".

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}-

>{'ExtendedSearchCondition'} = '1';

6.53.2.

Ticket::Frontend::AgentTicketSearch###SearchLimit

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Maximum number of tickets to be displayed in the result of a search in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'SearchLimit'} =

'2000';

6.53.3.

Ticket::Frontend::AgentTicketSearch###SearchPageShown

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Number of tickets to be displayed in each page of a search result in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'SearchPageShown'}

= '40';

608

6.53.4.

Ticket::Frontend::AgentTicketSearch###SearchViewableTicketLines

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Number of lines (per ticket) that are shown by the search utility in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}-

>{'SearchViewableTicketLines'} = '10';

6.53.5.

Ticket::Frontend::AgentTicketSearch###SortBy::Default

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default ticket attribute for ticket sorting of the ticket search result of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'SortBy::Default'}

= 'Age';

6.53.6.

Ticket::Frontend::AgentTicketSearch###Order::Default

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default ticket order in the ticket search result of the agent interface. Up: oldest on top. Down: latest on top.

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'Order::Default'}

= 'Down';

6.53.7.

Ticket::Frontend::AgentTicketSearch###SearchArticleCSVTree

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Exports the whole article tree in search result (it can affect the system performance).

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}-

>{'SearchArticleCSVTree'} = '0';

609

6.53.8.

Ticket::Frontend::AgentTicketSearch###SearchCSVData

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Data used to export the search result in CSV format.

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'SearchCSVData'} =

[

'TicketNumber',

'Age',

'Created',

'Closed',

'FirstLock',

'FirstResponse',

'State',

'Priority',

'Queue',

'Lock',

'Owner',

'UserFirstname',

'UserLastname',

'CustomerID',

'CustomerName',

'From',

'Subject',

'AccountedTime',

'ArticleTree',

'SolutionInMin',

'SolutionDiffInMin',

'FirstResponseInMin',

'FirstResponseDiffInMin'

];

6.53.9.

Ticket::Frontend::AgentTicketSearch###ArticleCreateTime

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Includes article create times in the ticket search of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}-

>{'ArticleCreateTime'} = '0';

6.53.10.

Ticket::Frontend::AgentTicketSearch###Defaults###Fulltext

Description:

Group:

SubGroup:

Valid:

Required:

Defines the default shown ticket search attribute for ticket search screen.

Ticket

Frontend::Agent::Ticket::ViewSearch

610

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'Defaults'}-

>{'Fulltext'} = '';

6.53.11.

Ticket::Frontend::AgentTicketSearch###Defaults###TicketNumber

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default shown ticket search attribute for ticket search screen.

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'Defaults'}-

>{'TicketNumber'} = '';

6.53.12.

Ticket::Frontend::AgentTicketSearch###Defaults###Title

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default shown ticket search attribute for ticket search screen.

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'Defaults'}-

>{'Title'} = '';

6.53.13.

Ticket::Frontend::AgentTicketSearch###Defaults###From

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default shown ticket search attribute for ticket search screen.

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'Defaults'}-

>{'From'} = '';

6.53.14.

Ticket::Frontend::AgentTicketSearch###Defaults###To

Description:

Group:

SubGroup:

Valid:

Required:

Defines the default shown ticket search attribute for ticket search screen.

Ticket

Frontend::Agent::Ticket::ViewSearch

611

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'Defaults'}-

>{'To'} = '';

6.53.15.

Ticket::Frontend::AgentTicketSearch###Defaults###Cc

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default shown ticket search attribute for ticket search screen.

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'Defaults'}-

>{'Cc'} = '';

6.53.16.

Ticket::Frontend::AgentTicketSearch###Defaults###Subject

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default shown ticket search attribute for ticket search screen.

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'Defaults'}-

>{'Subject'} = '';

6.53.17.

Ticket::Frontend::AgentTicketSearch###Defaults###Body

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default shown ticket search attribute for ticket search screen.

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'Defaults'}-

>{'Body'} = '';

6.53.18.

Ticket::Frontend::AgentTicketSearch###Defaults###CustomerID

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default shown ticket search attribute for ticket search screen.

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'Defaults'}-

>{'CustomerID'} = '';

612

6.53.19.

Ticket::Frontend::AgentTicketSearch###Defaults###CustomerUserLogin

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default shown ticket search attribute for ticket search screen.

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'Defaults'}-

>{'CustomerUserLogin'} = '';

6.53.20.

Ticket::Frontend::AgentTicketSearch###Defaults###StateIDs

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default shown ticket search attribute for ticket search screen.

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'Defaults'}-

>{'StateIDs'} = [];

6.53.21.

Ticket::Frontend::AgentTicketSearch###Defaults###QueueIDs

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default shown ticket search attribute for ticket search screen.

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'Defaults'}-

>{'QueueIDs'} = [];

6.53.22.

Ticket::Frontend::AgentTicketSearch###Defaults###TicketCreateTimePoint

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Default ticket data to search use on screen. attribute for

Example:

"TicketCreateTimePointFormat=year;TicketCreateTimePointStart=Last;TicketCreateTimePoint=2;".

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'Defaults'}-

>{'TicketCreateTimePoint'} = '';

613

6.53.23.

Ticket::Frontend::AgentTicketSearch###Defaults###TicketCreateTimeSlot

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Default ticket data to search use on screen. attribute for

Example:

"TicketCreateTimeStartYear=2010;TicketCreateTimeStartMonth=10;TicketCreateTimeStartDay=4;TicketCreateTimeStopYear=2010;TicketCreateTimeStopMonth=11;TicketCreateTimeStopDay=3;".

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'Defaults'}-

>{'TicketCreateTimeSlot'} = '';

6.53.24.

Ticket::Frontend::AgentTicketSearch###Defaults###TicketChangeTimePoint

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default shown ticket search attribute for ticket search screen.

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'Defaults'}-

>{'TicketChangeTimePoint'} = '';

6.53.25.

Ticket::Frontend::AgentTicketSearch###Defaults###TicketChangeTimeSlot

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default shown ticket search attribute for ticket search screen.

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'Defaults'}-

>{'TicketChangeTimeSlot'} = '';

6.53.26.

Ticket::Frontend::AgentTicketSearch###Defaults###TicketCloseTimePoint

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default shown ticket search attribute for ticket search screen.

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'Defaults'}-

>{'TicketCloseTimePoint'} = '';

614

6.53.27.

Ticket::Frontend::AgentTicketSearch###Defaults###TicketCloseTimeSlot

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default shown ticket search attribute for ticket search screen.

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'Defaults'}-

>{'TicketCloseTimeSlot'} = '';

6.53.28.

Ticket::Frontend::AgentTicketSearch###Defaults###TicketEscalationTimePoint

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default shown ticket search attribute for ticket search screen.

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'Defaults'}-

>{'TicketEscalationTimePoint'} = '';

6.53.29.

Ticket::Frontend::AgentTicketSearch###Defaults###TicketEscalationTimeSlot

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default shown ticket search attribute for ticket search screen.

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'Defaults'}-

>{'TicketEscalationTimeSlot'} = '';

6.53.30.

Ticket::Frontend::AgentTicketSearch###Defaults###ArticleCreateTimePoint

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default shown ticket search attribute for ticket search screen.

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'Defaults'}-

>{'ArticleCreateTimePoint'} = '';

615

6.53.31.

Ticket::Frontend::AgentTicketSearch###Defaults###ArticleCreateTimeSlot

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default shown ticket search attribute for ticket search screen.

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'Defaults'}-

>{'ArticleCreateTimeSlot'} = '';

6.53.32.

Ticket::Frontend::AgentTicketSearch###Defaults###SearchInArchive

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default shown ticket search attribute for ticket search screen.

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'Defaults'}-

>{'SearchInArchive'} = '';

6.53.33.

Ticket::Frontend::CustomerTicketSearch###SearchArticleCSVTree

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Exports the whole article tree in search result (it can affect the system performance).

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::CustomerTicketSearch'}-

>{'SearchArticleCSVTree'} = '0';

6.53.34.

Ticket::Frontend::AgentTicketSearch###DynamicField

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Dynamic fields shown in the ticket search screen of the agent interface. Possible settings: 0 = Disabled, 1 = Enabled, 2 = Enabled and shown by default.

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'DynamicField'} =

{};

616

6.53.35.

Ticket::Frontend::AgentTicketSearch###Defaults###DynamicField

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default shown ticket search attribute for ticket search screen. Example: "Key" must have the name of the Dynamic Field in this case 'X', "Content" must have the value of the Dynamic Field depending on the Dynamic Field type, Text: 'a text', Dropdown:

'1', Date/Time: 'Search_DynamicField_XTimeSlotStartYear=1974;

Search_DynamicField_XTimeSlotStartMonth=01;

Search_DynamicField_XTimeSlotStartDay=26;

Search_DynamicField_XTimeSlotStartHour=00;

Search_DynamicField_XTimeSlotStartMinute=00;

Search_DynamicField_XTimeSlotStartSecond=00;

Search_DynamicField_XTimeSlotStopYear=2013;

Search_DynamicField_XTimeSlotStopMonth=01;

Search_DynamicField_XTimeSlotStopDay=26;

Search_DynamicField_XTimeSlotStopHour=23;

Search_DynamicField_XTimeSlotStopMinute=59;

Search_DynamicField_XTimeSlotStopSecond=59;'

'Search_DynamicField_XTimePointFormat=week;

Search_DynamicField_XTimePointStart=Before;

Search_DynamicField_XTimePointValue=7';.

and or

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'Defaults'}-

>{'DynamicField'} = {};

6.53.36.

Ticket::Frontend::AgentTicketSearch###SearchCSVDynamicField

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Dynamic Fields used to export the search result in CSV format.

Ticket

Frontend::Agent::Ticket::ViewSearch

$Self->{'Ticket::Frontend::AgentTicketSearch'}-

>{'SearchCSVDynamicField'} = {};

6.53.37.

Ticket::Frontend::AgentTicketSearch###DefaultColumns

Description:

Group:

SubGroup:

Valid:

Required:

Columns that can be filtered in the ticket search result view of the agent interface. Possible settings: 0 = Disabled, 1 = Available, 2

= Enabled by default. Note: Only Ticket attributes and Dynamic

Fields (DynamicField_NameX) are allowed.

Ticket

Frontend::Agent::Ticket::ViewSearch

617

Config-Setting:

$Self->{'Ticket::Frontend::AgentTicketSearch'}->{'DefaultColumns'}

= {

'Age' => '2',

'Changed' => '1',

'CustomerID' => '2',

'CustomerName' => '1',

'CustomerUserID' => '1',

'EscalationResponseTime' => '1',

'EscalationSolutionTime' => '1',

'EscalationTime' => '1',

'EscalationUpdateTime' => '1',

'Lock' => '2',

'Owner' => '2',

'PendingTime' => '1',

'Priority' => '1',

'Queue' => '2',

'Responsible' => '1',

'SLA' => '1',

'Service' => '1',

'State' => '2',

'TicketNumber' => '2',

'Title' => '2',

'Type' => '1'

};

6.54. Frontend::Agent::Ticket::ViewStatus

6.54.1.

Ticket::Frontend::AgentTicketStatusView###ViewableTicketsPage

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows all open tickets (even if they are locked) in the status view of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewStatus

$Self->{'Ticket::Frontend::AgentTicketStatusView'}-

>{'ViewableTicketsPage'} = '50';

6.54.2.

Ticket::Frontend::AgentTicketStatusView###SortBy::Default

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default ticket attribute for ticket sorting in the status view of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewStatus

$Self->{'Ticket::Frontend::AgentTicketStatusView'}-

>{'SortBy::Default'} = 'Age';

6.54.3.

Ticket::Frontend::AgentTicketStatusView###Order::Default

Description: Defines the default ticket order (after priority sort) in the status view of the agent interface. Up: oldest on top. Down: latest on top.

618

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Agent::Ticket::ViewStatus

$Self->{'Ticket::Frontend::AgentTicketStatusView'}-

>{'Order::Default'} = 'Down';

6.54.4.

Ticket::Frontend::AgentTicketStatusView###DefaultColumns

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Columns that can be filtered in the status view of the agent interface. Possible settings: 0 = Disabled, 1 = Available, 2 = Enabled by default. Note: Only Ticket attributes and Dynamic Fields

(DynamicField_NameX) are allowed.

Ticket

Frontend::Agent::Ticket::ViewStatus

$Self->{'Ticket::Frontend::AgentTicketStatusView'}-

>{'DefaultColumns'} = {

'Age' => '2',

'Changed' => '1',

'CustomerID' => '2',

'CustomerName' => '1',

'CustomerUserID' => '1',

'EscalationResponseTime' => '1',

'EscalationSolutionTime' => '1',

'EscalationTime' => '1',

'EscalationUpdateTime' => '1',

'Lock' => '2',

'Owner' => '2',

'PendingTime' => '1',

'Priority' => '1',

'Queue' => '2',

'Responsible' => '1',

'SLA' => '1',

'Service' => '1',

'State' => '2',

'TicketNumber' => '2',

'Title' => '2',

'Type' => '1'

};

6.55. Frontend::Agent::Ticket::ViewWatch

6.55.1.

Ticket::Frontend::AgentTicketWatchView###SortBy::Default

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default ticket attribute for ticket sorting in the watch view of the agent interface.

Ticket

Frontend::Agent::Ticket::ViewWatch

$Self->{'Ticket::Frontend::AgentTicketWatchView'}-

>{'SortBy::Default'} = 'Age';

619

6.55.2.

Ticket::Frontend::AgentTicketWatchView###Order::Default

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default ticket order in the watch view of the agent interface. Up: oldest on top. Down: latest on top.

Ticket

Frontend::Agent::Ticket::ViewWatch

$Self->{'Ticket::Frontend::AgentTicketWatchView'}-

>{'Order::Default'} = 'Up';

6.55.3.

Ticket::Frontend::AgentTicketWatchView###DefaultColumns

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Columns that can be filtered in the watch view of the agent interface. Possible settings: 0 = Disabled, 1 = Available, 2 = Enabled by default. Note: Only Ticket attributes and Dynamic Fields

(DynamicField_NameX) are allowed.

Ticket

Frontend::Agent::Ticket::ViewWatch

$Self->{'Ticket::Frontend::AgentTicketWatchView'}-

>{'DefaultColumns'} = {

'Age' => '2',

'Changed' => '1',

'CustomerID' => '2',

'CustomerName' => '1',

'CustomerUserID' => '1',

'EscalationResponseTime' => '1',

'EscalationSolutionTime' => '1',

'EscalationTime' => '1',

'EscalationUpdateTime' => '1',

'Lock' => '2',

'Owner' => '2',

'PendingTime' => '1',

'Priority' => '1',

'Queue' => '2',

'Responsible' => '1',

'SLA' => '1',

'Service' => '1',

'State' => '2',

'TicketNumber' => '2',

'Title' => '2',

'Type' => '1'

};

6.56. Frontend::Agent::Ticket::ViewZoom

6.56.1. Ticket::Frontend::PlainView

Description:

Group:

SubGroup:

Valid:

Shows a link to see a zoomed email ticket in plain text.

Ticket

Frontend::Agent::Ticket::ViewZoom

620

Required:

Config-Setting:

$Self->{'Ticket::Frontend::PlainView'} = '0';

6.56.2. Ticket::Frontend::ZoomExpand

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows all the articles of the ticket (expanded) in the zoom view.

Ticket

Frontend::Agent::Ticket::ViewZoom

$Self->{'Ticket::Frontend::ZoomExpand'} = '0';

6.56.3. Ticket::Frontend::ZoomExpandSort

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows the articles sorted normally or in reverse, under ticket zoom in the agent interface.

Ticket

Frontend::Agent::Ticket::ViewZoom

$Self->{'Ticket::Frontend::ZoomExpandSort'} = 'normal';

6.56.4. Ticket::ZoomAttachmentDisplayCount

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a count of icons in the ticket zoom, if the article has attachments.

Ticket

Frontend::Agent::Ticket::ViewZoom

$Self->{'Ticket::ZoomAttachmentDisplayCount'} = '20';

6.56.5. Ticket::ZoomTimeDisplay

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Displays the accounted time for an article in the ticket zoom view.

Ticket

Frontend::Agent::Ticket::ViewZoom

$Self->{'Ticket::ZoomTimeDisplay'} = '0';

6.56.6. Ticket::UseArticleColors

Description:

Group:

SubGroup:

Valid:

Shows colors for different article types in the article table.

Ticket

Frontend::Agent::Ticket::ViewZoom

621

Required:

Config-Setting:

$Self->{'Ticket::UseArticleColors'} = '0';

6.56.7. Ticket::Frontend::TicketArticleFilter

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Activates the article filter in the zoom view to specify which articles should be shown.

Ticket

Frontend::Agent::Ticket::ViewZoom

$Self->{'Ticket::Frontend::TicketArticleFilter'} = '0';

6.56.8. Ticket::Frontend::HTMLArticleHeightDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Set the default height (in pixels) of inline HTML articles in Agent-

TicketZoom.

Ticket

Frontend::Agent::Ticket::ViewZoom

$Self->{'Ticket::Frontend::HTMLArticleHeightDefault'} = '100';

6.56.9. Ticket::Frontend::HTMLArticleHeightMax

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Set the maximum height (in pixels) of inline HTML articles in Agent-

TicketZoom.

Ticket

Frontend::Agent::Ticket::ViewZoom

$Self->{'Ticket::Frontend::HTMLArticleHeightMax'} = '2500';

6.56.10. Ticket::Frontend::ZoomRichTextForce

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Show article as rich text even if rich text writing is disabled.

Ticket

Frontend::Agent::Ticket::ViewZoom

$Self->{'Ticket::Frontend::ZoomRichTextForce'} = '1';

6.56.11.

Ticket::Frontend::AgentTicketZoom###DynamicField

Description: Dynamic fields shown in the sidebar of the ticket zoom screen of the agent interface. Possible settings: 0 = Disabled, 1 = Enabled.

622

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Agent::Ticket::ViewZoom

$Self->{'Ticket::Frontend::AgentTicketZoom'}->{'DynamicField'} =

{};

6.57. Frontend::Agent::TicketOverview

6.57.1. Ticket::Frontend::Overview###Small

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Allows having a small format ticket overview (CustomerInfo => 1

- shows also the customer information).

Ticket

Frontend::Agent::TicketOverview

$Self->{'Ticket::Frontend::Overview'}->{'Small'} = {

'CustomerInfo' => '1',

'Module' => 'Kernel::Output::HTML::TicketOverviewSmall',

'ModulePriority' => '100',

'Name' => 'Small',

'NameShort' => 'S'

};

6.57.2.

Ticket::Frontend::OverviewSmall###ColumnHeader

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows either the last customer article's subject or the ticket title in the small format overview.

Ticket

Frontend::Agent::TicketOverview

$Self->{'Ticket::Frontend::OverviewSmall'}->{'ColumnHeader'} =

'LastCustomerSubject';

6.57.3. Ticket::Frontend::Overview###Medium

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Allows having a medium format ticket overview (CustomerInfo =>

1 - shows also the customer information).

Ticket

Frontend::Agent::TicketOverview

$Self->{'Ticket::Frontend::Overview'}->{'Medium'} = {

'CustomerInfo' => '0',

'Module' => 'Kernel::Output::HTML::TicketOverviewMedium',

'ModulePriority' => '200',

'Name' => 'Medium',

'NameShort' => 'M',

623

'OverviewMenuModules' => '1',

'TicketActionsPerTicket' => '0'

};

6.57.4. Ticket::Frontend::Overview###Preview

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows a preview of the ticket overview (CustomerInfo => 1 shows also Customer-Info, CustomerInfoMaxSize max. size in characters of Customer-Info).

Ticket

Frontend::Agent::TicketOverview

$Self->{'Ticket::Frontend::Overview'}->{'Preview'} = {

'CustomerInfo' => '0',

'CustomerInfoMaxSize' => '18',

'DefaultPreViewLines' => '25',

'DefaultViewNewLine' => '90',

'Module' => 'Kernel::Output::HTML::TicketOverviewPreview',

'ModulePriority' => '300',

'Name' => 'Large',

'NameShort' => 'L',

'OverviewMenuModules' => '1',

'StripEmptyLines' => '0',

'TicketActionsPerTicket' => '0'

};

6.57.5.

Ticket::Frontend::Overview::PreviewArticleSenderTypes

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines which article sender types should be shown in the preview of a ticket.

Ticket

Frontend::Agent::TicketOverview

$Self->{'Ticket::Frontend::Overview::PreviewArticleSenderTypes'} =

{

'agent' => '1',

'customer' => '1',

'system' => '1'

};

6.57.6.

Ticket::Frontend::Overview::PreviewArticleLimit

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets the count of articles visible in preview mode of ticket overviews.

Ticket

Frontend::Agent::TicketOverview

$Self->{'Ticket::Frontend::Overview::PreviewArticleLimit'} = '5';

624

6.57.7.

Ticket::Frontend::Overview::PreviewArticleTypeExpanded

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines wich article type should be expanded when entering the overview. If nothing defined, latest article will be expanded.

Ticket

Frontend::Agent::TicketOverview

$Self->{'Ticket::Frontend::Overview::PreviewArticleTypeExpanded'} =

'';

6.57.8.

Ticket::Frontend::OverviewSmall###DynamicField

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Dynamic fields shown in the ticket small format overview screen of the agent interface. Possible settings: 0 = Disabled, 1 = Available,

2 = Enabled by default.

Ticket

Frontend::Agent::TicketOverview

$Self->{'Ticket::Frontend::OverviewSmall'}->{'DynamicField'} = {};

6.57.9.

Ticket::Frontend::OverviewMedium###DynamicField

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Dynamic fields shown in the ticket medium format overview screen of the agent interface. Possible settings: 0 = Disabled, 1

= Enabled.

Ticket

Frontend::Agent::TicketOverview

$Self->{'Ticket::Frontend::OverviewMedium'}->{'DynamicField'} =

{};

6.57.10.

Ticket::Frontend::OverviewPreview###DynamicField

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Dynamic fields shown in the ticket preview format overview screen of the agent interface. Possible settings: 0 = Disabled, 1 = Enabled.

Ticket

Frontend::Agent::TicketOverview

$Self->{'Ticket::Frontend::OverviewPreview'}->{'DynamicField'} =

{};

625

6.58. Frontend::Agent::ToolBarModule

6.58.1. Frontend::ToolBarModule###1-

Ticket::AgentTicketQueue

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Toolbar Item for a shortcut.

Ticket

Frontend::Agent::ToolBarModule

$Self->{'Frontend::ToolBarModule'}->{'1-Ticket::AgentTicketQueue'}

= {

'AccessKey' => 'q',

'Action' => 'AgentTicketQueue',

'CssClass' => 'QueueView',

'Icon' => 'icon-folder-close',

'Link' => 'Action=AgentTicketQueue',

'Module' => 'Kernel::Output::HTML::ToolBarLink',

'Name' => 'Queue view',

'Priority' => '1010010'

};

6.58.2. Frontend::ToolBarModule###2-

Ticket::AgentTicketStatus

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Toolbar Item for a shortcut.

Ticket

Frontend::Agent::ToolBarModule

$Self->{'Frontend::ToolBarModule'}->{'2-Ticket::AgentTicketStatus'}

= {

'AccessKey' => 'o',

'Action' => 'AgentTicketStatusView',

'CssClass' => 'StatusView',

'Icon' => 'icon-list-ol',

'Link' => 'Action=AgentTicketStatusView',

'Module' => 'Kernel::Output::HTML::ToolBarLink',

'Name' => 'Status view',

'Priority' => '1010020'

};

6.58.3. Frontend::ToolBarModule###3-

Ticket::AgentTicketEscalation

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Toolbar Item for a shortcut.

Ticket

Frontend::Agent::ToolBarModule

$Self->{'Frontend::ToolBarModule'}->{'3-

Ticket::AgentTicketEscalation'} = {

'AccessKey' => 'w',

'Action' => 'AgentTicketEscalationView',

626

'CssClass' => 'EscalationView',

'Icon' => 'icon-exclamation',

'Link' => 'Action=AgentTicketEscalationView',

'Module' => 'Kernel::Output::HTML::ToolBarLink',

'Name' => 'Escalation view',

'Priority' => '1010030'

};

6.58.4. Frontend::ToolBarModule###4-

Ticket::AgentTicketPhone

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Toolbar Item for a shortcut.

Ticket

Frontend::Agent::ToolBarModule

$Self->{'Frontend::ToolBarModule'}->{'4-Ticket::AgentTicketPhone'}

= {

'AccessKey' => 'l',

'Action' => 'AgentTicketPhone',

'CssClass' => 'PhoneTicket',

'Icon' => 'icon-phone',

'Link' => 'Action=AgentTicketPhone',

'Module' => 'Kernel::Output::HTML::ToolBarLink',

'Name' => 'New phone ticket',

'Priority' => '1020010'

};

6.58.5. Frontend::ToolBarModule###5-

Ticket::AgentTicketEmail

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Toolbar Item for a shortcut.

Ticket

Frontend::Agent::ToolBarModule

$Self->{'Frontend::ToolBarModule'}->{'5-Ticket::AgentTicketEmail'}

= {

'AccessKey' => 'e',

'Action' => 'AgentTicketEmail',

'CssClass' => 'EmailTicket',

'Icon' => 'icon-envelope',

'Link' => 'Action=AgentTicketEmail',

'Module' => 'Kernel::Output::HTML::ToolBarLink',

'Name' => 'New email ticket',

'Priority' => '1020020'

};

6.58.6. Frontend::ToolBarModule###6-

Ticket::AgentTicketProcess

Description:

Group:

SubGroup:

Valid:

Required:

Toolbar Item for a shortcut.

Ticket

Frontend::Agent::ToolBarModule

627

Config-Setting:

$Self->{'Frontend::ToolBarModule'}->{'6-

Ticket::AgentTicketProcess'} = {

'AccessKey' => 'p',

'Action' => 'AgentTicketProcess',

'CssClass' => 'ProcessTicket',

'Icon' => 'icon-th-large',

'Link' => 'Action=AgentTicketProcess',

'Module' => 'Kernel::Output::HTML::ToolBarLink',

'Name' => 'New process ticket',

'Priority' => '1020030'

};

6.58.7. Frontend::ToolBarModule###6-

Ticket::TicketResponsible

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Agent interface notification module to see the number of tickets an agent is responsible for.

Ticket

Frontend::Agent::ToolBarModule

$Self->{'Frontend::ToolBarModule'}->{'6-Ticket::TicketResponsible'}

= {

'CssClass' => 'Responsible',

'CssClassNew' => 'Responsible New',

'CssClassReached' => 'Responsible Reached',

'Icon' => 'icon-user',

'IconNew' => 'icon-user',

'IconReached' => 'icon-user',

'Module' => 'Kernel::Output::HTML::ToolBarTicketResponsible',

'Priority' => '1030010'

};

6.58.8. Frontend::ToolBarModule###7-

Ticket::TicketWatcher

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Agent interface notification module to see the number of watched tickets.

Ticket

Frontend::Agent::ToolBarModule

$Self->{'Frontend::ToolBarModule'}->{'7-Ticket::TicketWatcher'} =

{

'CssClass' => 'Watcher',

'CssClassNew' => 'Watcher New',

'CssClassReached' => 'Watcher Reached',

'Icon' => 'icon-eye-open',

'IconNew' => 'icon-eye-open',

'IconReached' => 'icon-eye-open',

'Module' => 'Kernel::Output::HTML::ToolBarTicketWatcher',

'Priority' => '1030020'

};

6.58.9. Frontend::ToolBarModule###8-

Ticket::TicketLocked

Description: Agent interface notification module to check the used charset.

628

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Agent::ToolBarModule

$Self->{'Frontend::ToolBarModule'}->{'8-Ticket::TicketLocked'} = {

'CssClass' => 'Locked',

'CssClassNew' => 'Locked New',

'CssClassReached' => 'Locked Reached',

'Icon' => 'icon-lock',

'IconNew' => 'icon-lock',

'IconReached' => 'icon-lock',

'Module' => 'Kernel::Output::HTML::ToolBarTicketLocked',

'Priority' => '1030030'

};

6.58.10. Frontend::ToolBarModule###9-

Ticket::TicketSearchProfile

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Agent interface module to access search profiles via nav bar.

Ticket

Frontend::Agent::ToolBarModule

$Self->{'Frontend::ToolBarModule'}->{'9-

Ticket::TicketSearchProfile'} = {

'Block' => 'ToolBarSearchProfile',

'Description' => 'Search-Template',

'MaxWidth' => '40',

'Module' => 'Kernel::Output::HTML::ToolBarTicketSearchProfile',

'Name' => 'Search-Template',

'Priority' => '1990010'

};

6.58.11. Frontend::ToolBarModule###10-

Ticket::TicketSearchFulltext

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Agent interface module to access fulltext search via nav bar.

Ticket

Frontend::Agent::ToolBarModule

$Self->{'Frontend::ToolBarModule'}->{'10-

Ticket::TicketSearchFulltext'} = {

'Block' => 'ToolBarSearchFulltext',

'CSS' => 'Core.Agent.Toolbar.FulltextSearch.css',

'Description' => 'Fulltext search',

'Module' => 'Kernel::Output::HTML::ToolBarGeneric',

'Name' => 'Fulltext-Search',

'Priority' => '1990020',

'Size' => '10'

};

6.58.12. Frontend::ToolBarModule###11-CICSearch-

CustomerID

Description: Agent interface module to access CIC search via nav bar.

629

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Agent::ToolBarModule

$Self->{'Frontend::ToolBarModule'}->{'11-CICSearchCustomerID'} = {

'Block' => 'ToolBarCICSearchCustomerID',

'CSS' => 'Core.Agent.Toolbar.CICSearch.css',

'Description' => 'CustomerID Search',

'Module' => 'Kernel::Output::HTML::ToolBarGeneric',

'Name' => 'CustomerID search',

'Priority' => '1990030',

'Size' => '10'

};

6.58.13. Frontend::ToolBarModule###11-CICSearch-

CustomerUser

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Agent interface module to access CIC search via nav bar.

Ticket

Frontend::Agent::ToolBarModule

$Self->{'Frontend::ToolBarModule'}->{'11-CICSearchCustomerUser'} =

{

'Block' => 'ToolBarCICSearchCustomerUser',

'CSS' => 'Core.Agent.Toolbar.CICSearch.css',

'Description' => 'CustomerUser Search',

'Module' => 'Kernel::Output::HTML::ToolBarGeneric',

'Name' => 'Customer user search',

'Priority' => '1990040',

'Size' => '10'

};

6.59. Frontend::Customer

6.59.1.

Ticket::Frontend::CustomerDisableCompanyTicketAccess

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

This option will deny the access to customer company tickets, which are not created by the customer user.

Ticket

Frontend::Customer

$Self->{'Ticket::Frontend::CustomerDisableCompanyTicketAccess'} =

'0';

6.59.2.

Ticket::Frontend::CustomerTicketOverviewCustomEmptyText

Description: Custom text for the page shown to customers that have no tickets yet.

630

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Customer

$Self->{'Ticket::Frontend::CustomerTicketOverviewCustomEmptyText'}

= {

'Button' => 'Create your first ticket',

'Text' => 'Please click the button below to create your first

ticket.',

'Title' => 'Welcome!'

};

6.59.3. Frontend::CustomerUser::Item###15-OpenTickets

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Customer item (icon) which shows the open tickets of this customer as info block. Setting CustomerUserLogin to 1 searches for tickets based on login name rather than CustomerID.

Ticket

Frontend::Customer

$Self->{'Frontend::CustomerUser::Item'}->{'15-OpenTickets'} = {

'Action' => 'AgentTicketSearch',

'Attributes' => 'StateType=Open;',

'CSS' => 'Core.Agent.CustomerUser.OpenTicket.css',

'CSSClassNoOpenTicket' => 'NoOpenTicket',

'CSSClassOpenTicket' => 'OpenTicket',

'CustomerUserLogin' => '0',

'Module' => 'Kernel::Output::HTML::CustomerUserGenericTicket',

'Subaction' => 'Search',

'Target' => '_blank',

'Text' => 'Open tickets'

};

6.59.4. Frontend::CustomerUser::Item###16-OpenTicketsForCustomerUserLogin

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Customer item (icon) which shows the open tickets of this customer as info block. Setting CustomerUserLogin to 1 searches for tickets based on login name rather than CustomerID.

Ticket

Frontend::Customer

$Self->{'Frontend::CustomerUser::Item'}->{'16-

OpenTicketsForCustomerUserLogin'} = {

'Action' => 'AgentTicketSearch',

'Attributes' => 'StateType=Open;',

'CSS' => 'Core.Agent.CustomerUser.OpenTicket.css',

'CSSClassNoOpenTicket' => 'NoOpenTicket',

'CSSClassOpenTicket' => 'OpenTicket',

'CustomerUserLogin' => '1',

'Module' => 'Kernel::Output::HTML::CustomerUserGenericTicket',

'Subaction' => 'Search',

'Target' => '_blank',

631

'Text' => 'Open tickets of customer'

};

6.59.5. Frontend::CustomerUser::Item###17-ClosedTickets

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Customer item (icon) which shows the closed tickets of this customer as info block. Setting CustomerUserLogin to 1 searches for tickets based on login name rather than CustomerID.

Ticket

Frontend::Customer

$Self->{'Frontend::CustomerUser::Item'}->{'17-ClosedTickets'} = {

'Action' => 'AgentTicketSearch',

'Attributes' => 'StateType=Closed;',

'CSS' => 'Core.Agent.CustomerUser.OpenTicket.css',

'CSSClassNoOpenTicket' => 'NoOpenTicket',

'CSSClassOpenTicket' => 'OpenTicket',

'CustomerUserLogin' => '0',

'Module' => 'Kernel::Output::HTML::CustomerUserGenericTicket',

'Subaction' => 'Search',

'Target' => '_blank',

'Text' => 'Closed tickets'

};

6.59.6. Frontend::CustomerUser::Item###18-ClosedTicketsForCustomerUserLogin

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Customer item (icon) which shows the closed tickets of this customer as info block. Setting CustomerUserLogin to 1 searches for tickets based on login name rather than CustomerID.

Ticket

Frontend::Customer

$Self->{'Frontend::CustomerUser::Item'}->{'18-

ClosedTicketsForCustomerUserLogin'} = {

'Action' => 'AgentTicketSearch',

'Attributes' => 'StateType=Closed;',

'CSS' => 'Core.Agent.CustomerUser.OpenTicket.css',

'CSSClassNoOpenTicket' => 'NoOpenTicket',

'CSSClassOpenTicket' => 'OpenTicket',

'CustomerUserLogin' => '1',

'Module' => 'Kernel::Output::HTML::CustomerUserGenericTicket',

'Subaction' => 'Search',

'Target' => '_blank',

'Text' => 'Closed tickets of customer'

};

6.59.7.

CustomerFrontend::CommonObject###QueueObject

Description:

Group:

Path of the file that stores all the settings for the QueueObject object for the customer interface.

Ticket

632

SubGroup:

Valid:

Required:

Config-Setting:

Frontend::Customer

$Self->{'CustomerFrontend::CommonObject'}->{'QueueObject'} =

'Kernel::System::Queue';

6.59.8.

CustomerFrontend::CommonObject###TicketObject

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Path of the file that stores all the settings for the TicketObject for the customer interface.

Ticket

Frontend::Customer

$Self->{'CustomerFrontend::CommonObject'}->{'TicketObject'} =

'Kernel::System::Ticket';

6.59.9. CustomerFrontend::CommonParam###Action

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default used Frontend-Module if no Action parameter given in the url on the customer interface.

Ticket

Frontend::Customer

$Self->{'CustomerFrontend::CommonParam'}->{'Action'} =

'CustomerTicketOverview';

6.59.10.

CustomerFrontend::CommonParam###TicketID

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Default ticket ID used by the system in the customer interface.

Ticket

Frontend::Customer

$Self->{'CustomerFrontend::CommonParam'}->{'TicketID'} = '';

6.60. Frontend::Customer::ModuleMetaHead

6.60.1. CustomerFrontend::HeaderMetaModule###2-

TicketSearch

Description:

Group:

Module to generate html OpenSearch profile for short ticket search in the customer interface.

Ticket

633

SubGroup:

Valid:

Required:

Config-Setting:

Frontend::Customer::ModuleMetaHead

$Self->{'CustomerFrontend::HeaderMetaModule'}->{'2-TicketSearch'} =

{

'Action' => 'CustomerTicketSearch',

'Module' => 'Kernel::Output::HTML::CustomerHeaderMetaTicketSearch'

};

6.61.

Frontend::Customer::ModuleRegistration

6.61.1.

CustomerFrontend::Module###CustomerTicketOverview

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the customer interface.

Ticket

Frontend::Customer::ModuleRegistration

$Self->{'CustomerFrontend::Module'}->{'CustomerTicketOverview'} =

{

'Description' => 'Overview of customer tickets',

'NavBar' => [

{

'AccessKey' => 't',

'Block' => '',

'Description' => 'Tickets',

'Link' => 'Action=CustomerTicketOverview;Subaction=MyTickets',

'LinkOption' => '',

'Name' => 'Tickets',

'NavBar' => 'Ticket',

'Prio' => '100',

'Type' => 'Menu'

{

'AccessKey' => 'm',

'Block' => '',

'Description' => 'My Tickets',

'Link' => 'Action=CustomerTicketOverview;Subaction=MyTickets',

'LinkOption' => '',

'Name' => 'My Tickets',

'NavBar' => 'Ticket',

'Prio' => '110',

'Type' => 'Submenu'

{

'AccessKey' => 'c',

'Block' => '',

'Description' => 'Company Tickets',

'Link' =>

'Action=CustomerTicketOverview;Subaction=CompanyTickets',

'LinkOption' => '',

'Name' => 'Company Tickets',

'NavBar' => 'Ticket',

'Prio' => '120',

'Type' => 'Submenu'

}

'NavBarName' => 'Ticket',

'Title' => 'Overview'

};

634

6.61.2.

CustomerFrontend::Module###CustomerTicketMessage

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the customer interface.

Ticket

Frontend::Customer::ModuleRegistration

$Self->{'CustomerFrontend::Module'}->{'CustomerTicketMessage'} = {

'Description' => 'Create tickets',

'NavBar' => [

{

'AccessKey' => 'n',

'Block' => '',

'Description' => 'Create new Ticket',

'Link' => 'Action=CustomerTicketMessage',

'LinkOption' => '',

'Name' => 'New Ticket',

'NavBar' => 'Ticket',

'Prio' => '100',

'Type' => 'Submenu'

}

'NavBarName' => 'Ticket',

'Title' => 'New Ticket'

};

6.61.3.

CustomerFrontend::Module###CustomerTicketZoom

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the customer interface.

Ticket

Frontend::Customer::ModuleRegistration

$Self->{'CustomerFrontend::Module'}->{'CustomerTicketZoom'} = {

'Description' => 'Ticket zoom view',

'Loader' => {

'JavaScript' => [

'Core.Customer.TicketZoom.js',

'Core.UI.Popup.js'

]

'NavBarName' => 'Ticket',

'Title' => 'Zoom'

};

6.61.4.

CustomerFrontend::Module###CustomerTicketPrint

Description:

Group:

SubGroup:

Valid:

Required:

Frontend module registration for the customer interface.

Ticket

Frontend::Customer::ModuleRegistration

635

Config-Setting:

$Self->{'CustomerFrontend::Module'}->{'CustomerTicketPrint'} = {

'Description' => 'Customer Ticket Print Module',

'NavBarName' => '',

'Title' => 'Print'

};

6.61.5.

CustomerFrontend::Module###CustomerTicketAttachment

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the customer interface.

Ticket

Frontend::Customer::ModuleRegistration

$Self->{'CustomerFrontend::Module'}->{'CustomerTicketAttachment'} =

{

'Description' => 'To download attachments',

'NavBarName' => '',

'Title' => ''

};

6.61.6.

CustomerFrontend::Module###CustomerTicketSearch

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Frontend module registration for the customer interface.

Ticket

Frontend::Customer::ModuleRegistration

$Self->{'CustomerFrontend::Module'}->{'CustomerTicketSearch'} = {

'Description' => 'Customer ticket search',

'NavBar' => [

{

'AccessKey' => 's',

'Block' => '',

'Description' => 'Search',

'Link' => 'Action=CustomerTicketSearch',

'LinkOption' => '',

'Name' => 'Search',

'NavBar' => 'Ticket',

'Prio' => '300',

'Type' => 'Submenu'

}

'NavBarName' => 'Ticket',

'Title' => 'Search'

};

6.62. Frontend::Customer::Preferences

6.62.1. CustomerPreferencesGroups###ShownTickets

Description:

Group:

Defines all the parameters for the ShownTickets object in the customer preferences of the customer interface.

Ticket

636

SubGroup:

Valid:

Required:

Config-Setting:

Frontend::Customer::Preferences

$Self->{'CustomerPreferencesGroups'}->{'ShownTickets'} = {

'Active' => '1',

'Column' => 'User Profile',

'Data' => {

'15' => '15',

'20' => '20',

'25' => '25',

'30' => '30'

'DataSelected' => '25',

'Key' => 'Tickets per page',

'Label' => 'Number of displayed tickets',

'Module' => 'Kernel::Output::HTML::PreferencesGeneric',

'PrefKey' => 'UserShowTickets',

'Prio' => '4000'

};

6.62.2. CustomerPreferencesGroups###RefreshTime

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines all the parameters for the RefreshTime object in the customer preferences of the customer interface.

Ticket

Frontend::Customer::Preferences

$Self->{'CustomerPreferencesGroups'}->{'RefreshTime'} = {

'Active' => '1',

'Column' => 'User Profile',

'Data' => {

'' => 'off',

'10' => '10 minutes',

'15' => '15 minutes',

'2' => ' 2 minutes',

'5' => ' 5 minutes',

'7' => ' 7 minutes'

'DataSelected' => '',

'Key' => 'Refresh interval',

'Label' => 'Ticket overview',

'Module' => 'Kernel::Output::HTML::PreferencesGeneric',

'PrefKey' => 'UserRefreshTime',

'Prio' => '4000'

};

6.63. Frontend::Customer::Ticket::ViewNew

6.63.1.

Ticket::Frontend::CustomerTicketMessage###NextScreenAfterNewTicket

Description:

Group:

SubGroup:

Valid:

Required:

Determines the next screen after new customer ticket in the customer interface.

Ticket

Frontend::Customer::Ticket::ViewNew

637

Config-Setting:

$Self->{'Ticket::Frontend::CustomerTicketMessage'}-

>{'NextScreenAfterNewTicket'} = 'CustomerTicketOverview';

6.63.2.

Ticket::Frontend::CustomerTicketMessage###Priority

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Allows customers to set the ticket priority in the customer interface.

Ticket

Frontend::Customer::Ticket::ViewNew

$Self->{'Ticket::Frontend::CustomerTicketMessage'}->{'Priority'} =

'1';

6.63.3.

Ticket::Frontend::CustomerTicketMessage###PriorityDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default priority of new customer tickets in the customer interface.

Ticket

Frontend::Customer::Ticket::ViewNew

$Self->{'Ticket::Frontend::CustomerTicketMessage'}-

>{'PriorityDefault'} = '3 normal';

6.63.4.

Ticket::Frontend::CustomerTicketMessage###Queue

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Allows customers to set the ticket queue in the customer interface.

If this is set to 'No', QueueDefault should be configured.

Ticket

Frontend::Customer::Ticket::ViewNew

$Self->{'Ticket::Frontend::CustomerTicketMessage'}->{'Queue'} =

'1';

6.63.5.

Ticket::Frontend::CustomerTicketMessage###QueueDefault

Description:

Group:

SubGroup:

Valid:

Defines the default queue for new customer tickets in the customer interface.

Ticket

Frontend::Customer::Ticket::ViewNew

638

Required:

Config-Setting:

$Self->{'Ticket::Frontend::CustomerTicketMessage'}-

>{'QueueDefault'} = 'Postmaster';

6.63.6.

Ticket::Frontend::CustomerTicketMessage###TicketType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Allows customers to set the ticket type in the customer interface.

If this is set to 'No', TicketTypeDefault should be configured.

Ticket

Frontend::Customer::Ticket::ViewNew

$Self->{'Ticket::Frontend::CustomerTicketMessage'}->{'TicketType'}

= '1';

6.63.7.

Ticket::Frontend::CustomerTicketMessage###TicketTypeDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default ticket type for new customer tickets in the customer interface.

Ticket

Frontend::Customer::Ticket::ViewNew

$Self->{'Ticket::Frontend::CustomerTicketMessage'}-

>{'TicketTypeDefault'} = 'default';

6.63.8.

Ticket::Frontend::CustomerTicketMessage###Service

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Allows customers to set the ticket service in the customer interface.

Ticket

Frontend::Customer::Ticket::ViewNew

$Self->{'Ticket::Frontend::CustomerTicketMessage'}->{'Service'} =

'1';

6.63.9.

Ticket::Frontend::CustomerTicketMessage###SLA

Description:

Group:

SubGroup:

Valid:

Allows customers to set the ticket SLA in the customer interface.

Ticket

Frontend::Customer::Ticket::ViewNew

639

Required:

Config-Setting:

$Self->{'Ticket::Frontend::CustomerTicketMessage'}->{'SLA'} = '1';

6.63.10.

Ticket::Frontend::CustomerTicketMessage###ServiceMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets if service must be selected by the customer.

Ticket

Frontend::Customer::Ticket::ViewNew

$Self->{'Ticket::Frontend::CustomerTicketMessage'}-

>{'ServiceMandatory'} = '0';

6.63.11.

Ticket::Frontend::CustomerTicketMessage###SLAMandatory

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sets if SLA must be selected by the customer.

Ticket

Frontend::Customer::Ticket::ViewNew

$Self->{'Ticket::Frontend::CustomerTicketMessage'}-

>{'SLAMandatory'} = '0';

6.63.12.

Ticket::Frontend::CustomerTicketMessage###StateDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default state of new customer tickets in the customer interface.

Ticket

Frontend::Customer::Ticket::ViewNew

$Self->{'Ticket::Frontend::CustomerTicketMessage'}-

>{'StateDefault'} = 'new';

6.63.13.

Ticket::Frontend::CustomerTicketMessage###ArticleType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default type for article in the customer interface.

Ticket

Frontend::Customer::Ticket::ViewNew

$Self->{'Ticket::Frontend::CustomerTicketMessage'}->{'ArticleType'}

= 'webrequest';

640

6.63.14.

Ticket::Frontend::CustomerTicketMessage###SenderType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Sender type for new tickets from the customer inteface.

Ticket

Frontend::Customer::Ticket::ViewNew

$Self->{'Ticket::Frontend::CustomerTicketMessage'}->{'SenderType'}

= 'customer';

6.63.15.

Ticket::Frontend::CustomerTicketMessage###HistoryType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default history type in the customer interface.

Ticket

Frontend::Customer::Ticket::ViewNew

$Self->{'Ticket::Frontend::CustomerTicketMessage'}->{'HistoryType'}

= 'WebRequestCustomer';

6.63.16.

Ticket::Frontend::CustomerTicketMessage###HistoryComment

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Comment for new history entries in the customer interface.

Ticket

Frontend::Customer::Ticket::ViewNew

$Self->{'Ticket::Frontend::CustomerTicketMessage'}-

>{'HistoryComment'} = '';

6.63.17. CustomerPanelSelectionType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the receipent target of the tickets ("Queue" shows all queues, "SystemAddress" displays all system addresses) in the customer interface.

Ticket

Frontend::Customer::Ticket::ViewNew

$Self->{'CustomerPanelSelectionType'} = 'Queue';

6.63.18. CustomerPanelSelectionString

Description: Determines the strings that will be shown as receipent (To:) of the ticket in the customer interface. For Queue as CustomerPa-

641

Group:

SubGroup:

Valid:

Required:

Config-Setting: nelSelectionType, "<Queue>" shows the names of the queues, and for SystemAddress, "<Realname> <<Email>>" shows the name and email of the receipent.

Ticket

Frontend::Customer::Ticket::ViewNew

$Self->{'CustomerPanelSelectionString'} = '<Queue>';

6.63.19. CustomerPanelOwnSelection

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Determines which queues will be valid for ticket's recepients in the customer interface.

Ticket

Frontend::Customer::Ticket::ViewNew

$Self->{'CustomerPanelOwnSelection'} = {

'Junk' => 'First Queue',

'Misc' => 'Second Queue'

};

6.63.20.

CustomerPanel::NewTicketQueueSelectionModule

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Module for To-selection in new ticket screen in the customer interface.

Ticket

Frontend::Customer::Ticket::ViewNew

$Self->{'CustomerPanel::NewTicketQueueSelectionModule'} =

'Kernel::Output::HTML::CustomerNewTicketQueueSelectionGeneric';

6.63.21.

Ticket::Frontend::CustomerTicketMessage###DynamicField

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Dynamic fields options shown in the ticket message screen of the customer interface. Possible settings: 0 = Disabled, 1 = Enabled,

2 = Enabled and required. NOTE. If you want to display these fields also in the ticket zoom of the customer interface, you have to enable them in CustomerTicketZoom###DynamicField.

Ticket

Frontend::Customer::Ticket::ViewNew

$Self->{'Ticket::Frontend::CustomerTicketMessage'}-

>{'DynamicField'} = {};

642

6.64. Frontend::Customer::Ticket::ViewPrint

6.64.1.

Ticket::Frontend::CustomerTicketPrint###DynamicField

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Dynamic fields shown in the ticket print screen of the customer interface. Possible settings: 0 = Disabled, 1 = Enabled.

Ticket

Frontend::Customer::Ticket::ViewPrint

$Self->{'Ticket::Frontend::CustomerTicketPrint'}->{'DynamicField'}

= {};

6.65. Frontend::Customer::Ticket::ViewSearch

6.65.1. Ticket::CustomerTicketSearch::SearchLimit

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Maximum number of tickets to be displayed in the result of a search in the customer interface.

Ticket

Frontend::Customer::Ticket::ViewSearch

$Self->{'Ticket::CustomerTicketSearch::SearchLimit'} = '5000';

6.65.2.

Ticket::CustomerTicketSearch::SearchPageShown

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Number of tickets to be displayed in each page of a search result in the customer interface.

Ticket

Frontend::Customer::Ticket::ViewSearch

$Self->{'Ticket::CustomerTicketSearch::SearchPageShown'} = '40';

6.65.3. Ticket::CustomerTicketSearch::SortBy::Default

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default ticket attribute for ticket sorting in a ticket search of the customer interface.

Ticket

Frontend::Customer::Ticket::ViewSearch

$Self->{'Ticket::CustomerTicketSearch::SortBy::Default'} = 'Age';

643

6.65.4. Ticket::CustomerTicketSearch::Order::Default

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default ticket order of a search result in the customer interface. Up: oldest on top. Down: latest on top.

Ticket

Frontend::Customer::Ticket::ViewSearch

$Self->{'Ticket::CustomerTicketSearch::Order::Default'} = 'Down';

6.65.5.

Ticket::Frontend::CustomerTicketSearch###ExtendedSearchCondition

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Allows extended search conditions in ticket search of the customer interface. With this feature you can search w. g. with this kind of conditions like "(key1&&key2)" or "(key1||key2)".

Ticket

Frontend::Customer::Ticket::ViewSearch

$Self->{'Ticket::Frontend::CustomerTicketSearch'}-

>{'ExtendedSearchCondition'} = '1';

6.65.6.

Ticket::Frontend::CustomerTicketSearch###SearchCSVData

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Data used to export the search result in CSV format.

Ticket

Frontend::Customer::Ticket::ViewSearch

$Self->{'Ticket::Frontend::CustomerTicketSearch'}-

>{'SearchCSVData'} = [

'TicketNumber',

'Age',

'Created',

'Closed',

'State',

'Priority',

'Lock',

'CustomerID',

'CustomerName',

'From',

'Subject'

];

6.65.7.

Ticket::Frontend::CustomerTicketSearch###DynamicField

Description:

Group:

Dynamic fields shown in the ticket search screen of the customer interface. Possible settings: 0 = Disabled, 1 = Enabled.

Ticket

644

SubGroup:

Valid:

Required:

Config-Setting:

Frontend::Customer::Ticket::ViewSearch

$Self->{'Ticket::Frontend::CustomerTicketSearch'}->{'DynamicField'}

= {};

6.65.8.

Ticket::Frontend::CustomerTicketSearch###SearchOverviewDynamicField

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Dynamic fields shown in the ticket search overview results screen of the customer interface. Possible settings: 0 = Disabled, 1 =

Enabled.

Ticket

Frontend::Customer::Ticket::ViewSearch

$Self->{'Ticket::Frontend::CustomerTicketSearch'}-

>{'SearchOverviewDynamicField'} = {};

6.65.9.

Ticket::Frontend::CustomerTicketSearch###SearchCSVDynamicField

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Dynamic Fields used to export the search result in CSV format.

Ticket

Frontend::Customer::Ticket::ViewSearch

$Self->{'Ticket::Frontend::CustomerTicketSearch'}-

>{'SearchCSVDynamicField'} = {};

6.66. Frontend::Customer::Ticket::ViewZoom

6.66.1.

Ticket::Frontend::CustomerTicketZoom###NextScreenAfterFollowUp

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Determines the next screen after the follow up screen of a zoomed ticket in the customer interface.

Ticket

Frontend::Customer::Ticket::ViewZoom

$Self->{'Ticket::Frontend::CustomerTicketZoom'}-

>{'NextScreenAfterFollowUp'} = 'CustomerTicketOverview';

6.66.2.

Ticket::Frontend::CustomerTicketZoom###ArticleType

Description: Defines the default type of the note in the ticket zoom screen of the customer interface.

645

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Customer::Ticket::ViewZoom

$Self->{'Ticket::Frontend::CustomerTicketZoom'}->{'ArticleType'} =

'webrequest';

6.66.3.

Ticket::Frontend::CustomerTicketZoom###SenderType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default sender type for tickets in the ticket zoom screen of the customer interface.

Ticket

Frontend::Customer::Ticket::ViewZoom

$Self->{'Ticket::Frontend::CustomerTicketZoom'}->{'SenderType'} =

'customer';

6.66.4.

Ticket::Frontend::CustomerTicketZoom###HistoryType

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the history type for the ticket zoom action, which gets used for ticket history in the customer interface.

Ticket

Frontend::Customer::Ticket::ViewZoom

$Self->{'Ticket::Frontend::CustomerTicketZoom'}->{'HistoryType'} =

'FollowUp';

6.66.5.

Ticket::Frontend::CustomerTicketZoom###HistoryComment

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the history comment for the ticket zoom action, which gets used for ticket history in the customer interface.

Ticket

Frontend::Customer::Ticket::ViewZoom

$Self->{'Ticket::Frontend::CustomerTicketZoom'}->{'HistoryComment'}

= '';

6.66.6.

Ticket::Frontend::CustomerTicketZoom###Priority

Description: Allows customers to change the ticket priority in the customer interface.

646

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Customer::Ticket::ViewZoom

$Self->{'Ticket::Frontend::CustomerTicketZoom'}->{'Priority'} =

'1';

6.66.7.

Ticket::Frontend::CustomerTicketZoom###PriorityDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default priority of follow up customer tickets in the ticket zoom screen in the customer interface.

Ticket

Frontend::Customer::Ticket::ViewZoom

$Self->{'Ticket::Frontend::CustomerTicketZoom'}-

>{'PriorityDefault'} = '3 normal';

6.66.8.

Ticket::Frontend::CustomerTicketZoom###State

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Allows choosing the next compose state for customer tickets in the customer interface.

Ticket

Frontend::Customer::Ticket::ViewZoom

$Self->{'Ticket::Frontend::CustomerTicketZoom'}->{'State'} = '1';

6.66.9.

Ticket::Frontend::CustomerTicketZoom###StateDefault

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Defines the default next state for a ticket after customer follow up in the customer interface.

Ticket

Frontend::Customer::Ticket::ViewZoom

$Self->{'Ticket::Frontend::CustomerTicketZoom'}->{'StateDefault'} =

'open';

6.66.10.

Ticket::Frontend::CustomerTicketZoom###StateType

Description: Defines the next possible states for customer tickets in the customer interface.

647

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Ticket

Frontend::Customer::Ticket::ViewZoom

$Self->{'Ticket::Frontend::CustomerTicketZoom'}->{'StateType'} = [

'open',

'closed'

];

6.66.11.

Ticket::Frontend::CustomerTicketZoom###AttributesView

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows the activated ticket attributes in the customer interface (0

= Disabled and 1 = Enabled).

Ticket

Frontend::Customer::Ticket::ViewZoom

$Self->{'Ticket::Frontend::CustomerTicketZoom'}->{'AttributesView'}

= {

'Owner' => '0',

'Priority' => '1',

'Queue' => '1',

'Responsible' => '0',

'SLA' => '0',

'Service' => '0',

'State' => '1',

'Type' => '0'

};

6.66.12.

Ticket::Frontend::CustomerTicketZoom###DynamicField

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Dynamic fields shown in the ticket zoom screen of the customer interface. Possible settings: 0 = Disabled, 1 = Enabled.

Ticket

Frontend::Customer::Ticket::ViewZoom

$Self->{'Ticket::Frontend::CustomerTicketZoom'}->{'DynamicField'} =

{};

6.66.13.

Ticket::Frontend::CustomerTicketZoom###FollowUpDynamicField

Description:

Group:

SubGroup:

Valid:

Dynamic fields options shown in the ticket reply section in the ticket zoom screen of the customer interface. Possible settings: 0

= Disabled, 1 = Enabled, 2 = Enabled and required.

Ticket

Frontend::Customer::Ticket::ViewZoom

648

Required:

Config-Setting:

$Self->{'Ticket::Frontend::CustomerTicketZoom'}-

>{'FollowUpDynamicField'} = {};

6.67. Frontend::Customer::TicketOverview

6.67.1.

Ticket::Frontend::CustomerTicketOverviewSortable

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Controls if customers have the ability to sort their tickets.

Ticket

Frontend::Customer::TicketOverview

$Self->{'Ticket::Frontend::CustomerTicketOverviewSortable'} = '';

6.67.2.

Ticket::Frontend::CustomerTicketOverview###ColumnHeader

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Shows either the last customer article's subject or the ticket title in the small format overview.

Ticket

Frontend::Customer::TicketOverview

$Self->{'Ticket::Frontend::CustomerTicketOverview'}-

>{'ColumnHeader'} = 'TicketTitle';

6.67.3.

Ticket::Frontend::CustomerTicketOverview###Owner

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Show the current owner in the customer interface.

Ticket

Frontend::Customer::TicketOverview

$Self->{'Ticket::Frontend::CustomerTicketOverview'}->{'Owner'} =

'0';

6.67.4.

Ticket::Frontend::CustomerTicketOverview###Queue

Description:

Group:

SubGroup:

Valid:

Required:

Show the current queue in the customer interface.

Ticket

Frontend::Customer::TicketOverview

649

Config-Setting:

$Self->{'Ticket::Frontend::CustomerTicketOverview'}->{'Queue'} =

'0';

6.67.5.

Ticket::Frontend::CustomerTicketOverview###DynamicField

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Dynamic fields shown in the ticket overview screen of the customer interface. Possible settings: 0 = Disabled, 1 = Enabled, 2 =

Enabled and required.

Ticket

Frontend::Customer::TicketOverview

$Self->{'Ticket::Frontend::CustomerTicketOverview'}-

>{'DynamicField'} = {};

6.68. Frontend::Queue::Preferences

6.68.1. QueuePreferences###Comment2

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Parameters of the example queue attribute Comment2.

Ticket

Frontend::Queue::Preferences

$Self->{'QueuePreferences'}->{'Comment2'} = {

'Block' => 'TextArea',

'Cols' => '50',

'Desc' => 'Define the queue comment 2.',

'Label' => 'Comment2',

'Module' => 'Kernel::Output::HTML::QueuePreferencesGeneric',

'PrefKey' => 'Comment2',

'Rows' => '5'

};

6.69. Frontend::SLA::Preferences

6.69.1. SLAPreferences###Comment2

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Parameters of the example SLA attribute Comment2.

Ticket

Frontend::SLA::Preferences

$Self->{'SLAPreferences'}->{'Comment2'} = {

'Block' => 'TextArea',

'Cols' => '50',

'Desc' => 'Define the sla comment 2.',

'Label' => 'Comment2',

'Module' => 'Kernel::Output::HTML::SLAPreferencesGeneric',

'PrefKey' => 'Comment2',

'Rows' => '5'

};

650

6.70. Frontend::Service::Preferences

6.70.1. ServicePreferences###Comment2

Description:

Group:

SubGroup:

Valid:

Required:

Config-Setting:

Parameters of the example service attribute Comment2.

Ticket

Frontend::Service::Preferences

$Self->{'ServicePreferences'}->{'Comment2'} = {

'Block' => 'TextArea',

'Cols' => '50',

'Desc' => 'Define the service comment 2.',

'Label' => 'Comment2',

'Module' => 'Kernel::Output::HTML::ServicePreferencesGeneric',

'PrefKey' => 'Comment2',

'Rows' => '5'

};

651

Anhang C. Danksagungen

OTRS ist ein OpenSource Projekt und wir möchten auch den vielen Leuten für Ihre Hilfe herzlich danken. Dies ist eine offene Liste in der wir sicher den Einen oder Aderen unabsichtlich vergessen haben, sorry dafür! Meldet Euch einfach, wenn Euer Name hier fehlt!

Folgende Personen haben das Projekt besonders unterstützt bzw. helfen immernoch aktiv mit:

• Robert Kehl, der den Win32-Installer für die 1.x Versionen alleine kreiert hat. Dank Dir,

Robert!

• Torsten Werner, der sich aktiv um den Debian Installer kümmert und dafür sorgt, dass

OTRS auch bequem unter Debian verfügbar ist. Vielen Dank, Torsten!

• Nils Jeppe (Mirror Hamburg, Germany), Bryan Fullerton (Mirro Toronto, Canada), Eberhard Moenkeberg (Mirror Göttingen, Deutschland), Timo Dreger (Mirror Düsseldorf,

Deutschland) und Netmonic (Mirror Wien, Österreich), die unseren ftp-Server spiegeln.

Vielen Dank an Euch, durch Eure Hilfe ist immer ein schneller Download von OTRS möglich!

• Anja Schneider, die kräftig bei der Übersetzung dieses Admin Handbuches mitgeholfen und die deutschen Texte korrigiert hat. Vielen Dank, Anja, für deine Geduld und deine

Mithilfe!

• Aus den OTRS Mailinglisten schöpfen wir viele Ideen für Weiterentwicklungen, erhalten

Patches oder Fixes für Fehler und die Benutzer bekommen sehr guten Support. Vielen

Dank an alle auf den Listen für Eure aktive Mithilfe!

Auch möchten wir uns bei folgenden Personen bedanken:

• Martin Scherbaum

• Carsten Gross

• Harald Müller

• Stefan Schmidt

• Milisav Radmanic

• Uli Hecht

• Norman Walsh

• Heiko Baumann

• Atif Ghaffar

• Pablo Ruiz Garcia

• Dan Rau

• Christoph Kaulich

• Mark Jackson

• Diane Shieh

• Bernard Choppy

652

• Carl Bailey

• Phil Davis

• Edwin D. Vinas

• Lars Müller

• Vladimir Gerdjikov

• Fred van Dijk

• Sebastien Guilbaud

• Wiktor Wodecki

• Arnold Ligtvoet

• Antti Kämäräinen

• Nicolas Goralski

• Gilberto Cezar de Almeida

• Jorge Becerra

• Eddie Urenda

• Stella Power

• Andreas Haase

• Reiner Keller

• Covert Jake

• Moshe Leibovitch

• Bjärn Jacke

• Remo Catelotti

• Alfons Obermeyer

• Michael Rech

• Danie Theron

• Richard Paradies

• Art Powell

653

Anhang D. GNU Free

Documentation License

Version 1.1, March 2000

330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

0. PREAMBLE

The purpose of this License is to make a manual, textbook, or other written document

"free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or non-commercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public

License, which is a copyleft license designed for free software.

We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.

1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you".

A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of the Document, that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters), and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License.

The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or

Back-Cover Texts, in the notice that says that the Document is released under this License.

654

A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats, suitable for input to text formatters. A copy made in an otherwise

Transparent file format, whose markup has been designed to thwart or discourage subsequent modification by readers is not Transparent. A copy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include: plain ASCII without markup,

Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML designed for human modification. Opaque formats include: PostScript, PDF, proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML produced by some word processors for output purposes only.

The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.

2. VERBATIM COPYING

You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.

3. COPYING IN QUANTITY

If you publish printed copies of the Document numbering more than 100, and the

Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a publicly-accessible computer-network location, containing a complete Transparent copy of the Document, free of added material, which the general network-using public has access to download anonymously, at no char-

655

ge, using public-standard network protocols. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location, until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.

4. MODIFICATIONS

You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it.

In addition, you must do these things in the Modified Version:

A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the

History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.

B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has less than five).

C. State on the Title page the name of the publisher of the Modified Version, as the publisher.

D.Preserve all the copyright notices of the Document.

E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.

F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.

G.Preserve in that license notice the full lists of Invariant Sections and required Cover

Texts given in the Document's license notice.

H. Include an unaltered copy of this License.

I. Preserve the section entitled "History", and its title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the

Title Page. If there is no section entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version, as stated in the previous sentence.

J. Preserve the network location, if any, given in the Document for public access to a

Transparent copy of the Document, and likewise the network locations given in the

Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.

K. In any section entitled "Acknowledgements" or "Dedications", preserve the section's title, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.

656

L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.

M.Delete any section entitled "Endorsements". Such a section may not be included in the

Modified Version.

N.Do not retitle any existing section as "Endorsements" or to conflict in title with any

Invariant Section.

If the Modified Version includes new front-matter sections or appendices that qualify as

Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.

You may add a section entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified

Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.

5. COMBINING DOCUMENTS

You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice.

The combined work need only contain one copy of this License, and multiple identical

Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections entitled "History" in the various original documents, forming one section entitled "History"; likewise combine any sections entitled "Acknowledgements", and any sections entitled "Dedications". You must delete all sections entitled "Endorsements."

6. COLLECTIONS OF DOCUMENTS

You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License, for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

657

7. AGGREGATION WITH INDEPENDENT

WORKS

A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, does not as a whole count as a Modified Version of the Document, provided no compilation copyright is claimed for the compilation. Such a compilation is called an "aggregate", and this License does not apply to the other self-contained works thus compiled with the Document, on account of their being thus compiled, if they are not themselves derivative works of the

Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one quarter of the entire aggregate, the Document's

Cover Texts may be placed on covers that surround only the Document within the aggregate. Otherwise they must appear on covers around the whole aggregate.

8. Übersetzung

Translation is considered a kind of modification, so you may distribute translations of the

Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections, in addition to the original versions of these Invariant

Sections. You may include a translation of this License provided that you also include the original English version of this License. In case of a disagreement between the translation and the original English version of this License, the original English version will prevail.

9. TERMINATION

You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

10. FUTURE REVISIONS OF THIS

LICENSE

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http:// www.gnu.org/copyleft/ .

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software

Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.

658

. How to use this License for your documents

To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:

Copyright (c) YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software

Foundation; with the Invariant Sections being LIST THEIR TITLES, with the

Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. A copy of the license is included in the section entitled "GNU Free Documentation License".

If you have no Invariant Sections, write "with no Invariant Sections" instead of saying which ones are invariant. If you have no Front-Cover Texts, write "no Front-Cover Texts" instead of "Front-Cover Texts being LIST"; likewise for Back-Cover Texts.

If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU

General Public License, to permit their use in free software.

659

Documentation

OTRS 3.3 -

Administrator-Handbuch

Vorwort

Kapitel 1. Einführung

1. Trouble-Ticket-Systeme - die Grundlagen

2. OTRS-Helpdesk

Kapitel 2. Installation

1. Der einfache Weg - Installation fertiger Pakete

2. Manuelle Installation (Linux, Unix)

3. Benutzen des Web-Installers

4. Upgrade des OTRS Frameworks

5. Upgrade mit dem Windows-Installer

6. Zusätzliche Applikationen

Kapitel 3. Erste Schritte

1. Agenten-Weboberfläche

2. Kunden-Weboberfläche

3. Öffentliche Weboberfläche

4. Die erste Anmeldung

5. Agenten-Weboberfläche - ein Überblick

6. Übersicht

7. Was verbirgt sich hinter dem

Begriff Queue?

8. Was ist die Queue-Übersicht?

9. Benutzereinstellungen

Kapitel 4. Administration

1. Der Administrationsbereich von

OTRS

2. Systemkonfiguration

3. Datensicherung

4. Email-Einstellungen

5. Einbinden externer Backends

6. Ticket-Einstellungen

7. Zeitabhängige Funktionen in OTRS

8. Anpassen der PDF-Ausgabe

9. Statistikmodul

10. Dynamische Felder

11. Generic Interface

12. OTRS Scheduler

Kapitel 5. Anpassung

1. Access Control Lists (ACLs)

2. Prozess-Management

3. Erstellung eigener Themes

4. Übersetzung des OTRS-Frontends

Kapitel 6.

Leistungsverbesserung

1. OTRS

2. Datenbank

3. Webserver

Anhang A. Weitere Quellen

1. Webseite OTRS Gruppe

2. Mailinglisten

3. Fehler berichten

4. Kommerzieller Support

Anhang B. Referenz der

Konfigurationsoptionen

1. DynamicFields

2. Framework

3. GenericInterface

4. ProcessManagement

5. Scheduler

6. Ticket

Anhang C. Danksagungen

Anhang D. GNU Free

Documentation License

0. PREAMBLE

1. APPLICABILITY AND DEFINITIONS

2. VERBATIM COPYING

3. COPYING IN QUANTITY

4. MODIFICATIONS

5. COMBINING DOCUMENTS

6. COLLECTIONS OF DOCUMENTS

7. AGGREGATION WITH INDEPENDENT

WORKS

8. Übersetzung

9. TERMINATION

10. FUTURE REVISIONS OF THIS

LICENSE

. How to use this License for your documents

Associés