Einführung

In einem Ticketsystem, dreht es sich um sogenannte "Tickets", daher kommt auch der Name "Ticketsystem". Im folgenden werden wir Informationen über das TIcketsystem bereitstellen und danach das kostenlose Ticketsystem OTOBO vorstellen.

Unter Tickets in dem Sinne versteht man, aber keine Kino oder Theater-Tickets, sondern Probleme bzw. Aufgaben.

In einem Help Desk von beispielsweise einer App, könnte ein Ticket ein Bug in der App sein, welcher einem Nutzer aufgefallen ist. Nun wurde im Ticketsystem ein Ticket erstellt und ein Mitarbeiter kümmert sich darum das Ticket zu lösen. Also der Bug in der App zu beheben.

‍

‍

‍

‍

‍

‍

‍

‍

Grundbegriffe

Tickets

Was ist ein Ticket?

Die Tickets enthalten meistens Informationen über das aufgetretene Problem. Wenn wir beim Beispiel der App bleiben, beispielsweise die Version der App in welcher der Bug aufgetreten ist, oder das Betriebssystem des Nutzers.

Eine weitere häufig verwendete Information ist der Bearbeiter/Besitzer des Tickets, das ist die Person, welche das Ticket bearbeitet, also das Problem löst.

Welche Daten werden im Ticket gespeichert ?

Außerdem hat man häufig einen Reporter oder einen Verantwortlichen, welcher das Ticket beaufsichtigt. Prüft, ob das Ticket richtig erledigt worden ist.

Oft speichert man auch, wie viel Aufwand für das lösen des Tickets gebraucht wurde.

Status

Sehr wichtig ist auch noch der Status des Tickets, je nach verwendeten Ticketsystem und Vorlieben der Nutzer gibt es unterschiedliche Stati. Oft gibt es den Status offen, welcher bedeutet, dass das Ticket neu erstellt wurde und noch nicht bearbeitet wurde. Außerdem hat man im Normalfall einen Status, der angibt, dass das Ticket gelöst ist (erledigt oder geschlossen).

Wann wechselt das Ticket den Status?

Das Ticket, wechselt im Normalfall ein paar mal den Status, erst wird es erstellt, dann jemandem zugewiesen, dieser hat vielleicht eine Frage zu dem Ticket, ... und so weiter.

Priorität

‍

Mit der Priorität eines Tickets gibt man an, wie dringend es ist dieses Ticket zu erledigen. Zum Beispiel "hoch", "mittel", "niedrig".

Tickets welche eine höhere Priorität haben, werden schneller erledigt.

‍

Benutzer/Agent

Ein Ticketsystem hat natürlich auch Benutzer, welche Tickets im Help Desk erstellen. Diese melden sich an und erstellen dann Tickets.

Natürlich willst du den Benutzern unterschiedliche Berechtigungen geben, je nachdem welche Rolle Sie haben.

‍

‍

‍

Verantwortlicher

Möglicherweise gibt es bei der Ticket-Bearbeitung mehrere Personen welche mit dem Ticket zu tun haben. Um die Verantwortlichkeiten möglichst einfach zu halten und um Verwirrung zu vermeiden.

Welche Personen sehen das Ticket?

Oft gibt es zusätzlich eine Person, welche das Ticket überwacht, also eine Person die nicht unmittelbar das Ticket bearbeitet, aber dafür Verantwortlich ist, dass das Ticket erledigt wird.

Beobachter

Da andere Leute in der Organisation möglicherweise auch ein Interesse daran haben zu Erfahren wie es mit dem Ticket voran geht, wollen diese über die Entwicklung des Tickets bescheid wissen. Dazu gibt es die Möglichkeit, dass man ein Ticket beobachten kann.

Für die Tickets die man beobachtet, bekommt man Benachrichtigungen, zum Beispiel Emails.

‍

‍

‍

Arbeitsaufwand

Häufig will man im Ticket festhalten wie lange es gedauert hat das Problem zu lösen.

Help Desk - Prozessablauf

Im Normalfall wird der Helpdesk per Telefon oder auch per Email kontaktiert. Ein neuer Trend ist es Chatbots für den Support einzusetzen, da diese deutlich günstiger als echte Menschen zu beschäftigen.

Es kann aber auch Kontakt über einen Live-Chat entstehen.

Kontakt

Nachdem ein Kontakt erstellt wurde, geht es darum das Problem des Nutzers möglichst schnell zu lösen. Je nachdem in welcher Lage der Kunde sich befindet und für welche Branche der Help-Desk ist kann es gut sein, dass der Kunde schlecht gelaunt ist und sehr schnell Hilfe haben will.

Welches Problem hat der Nutzer ?

Um das Problem des Nutzers zu lösen ist es wichtig viele Informationen über das genaue Problem zu erfragen. Diese Daten sollte man am Besten in einem Ticket festhalten.

Kann man das Problem lösen ?

Auch wenn man das Problem schon direkt am Telefon lösen kann, sollte man alle Informationen trotzdem in einem Ticket festhalten. Dies hat den Vorteil, dass man dieses Problem hoffentlich den nächsten Kunden ersparen kann und den Service und die Kundenzufriedenheit verbessern kann.

So findet man schnell heraus, welche Probleme häufig auftreten, welche Kunden häufig Probleme haben, zu welchen Zeiten häufig Probleme auftreten.

Status

Wenn das Ticket nicht direkt gelöst werden kann, dann bekommt es einen gewissen Status, beispielsweise den Status "offen", erledigte Tickets bekommen einen Status der den Benutzern/Agenten zeigt, dass das Problem gelöst ist, zum Beispiel "geschlossen" oder "erledigt". Je nachdem wie weit die Bearbeitung des Tickets ist oder welchen Prozess es durchläuft, kann es mehrere Stati haben, welche sich auch mehrfach während der Ticket Bearbeitung ändern können.

Priorität

Je nachdem wie dringend es ist das Problem, welches im Ticket festgehalten wurde zu lösen, bekommt das Ticket eine entsprechende Priorität. In diesem Zusammenhang kann man auch unterscheiden zwischen wie schnell das Ticket gelöst werden muss, also wie viel Zeit man noch hat und welchen Effekt das Problem hat. Beispielsweise kann es sein, dass ein Problem vielleicht schnell gelöst werden muss, aber das Problem klein ist, also wenig relevant ist.

Bearbeiter

Außerdem wird ein Bearbeiter festgelegt, das ist die Person welche sich um das Ticket kümmern muss. Die Person die diesem Ticket als Bearbeiter zugeordnet ist, kann sich ändern. Der Bearbeiter findet heraus das diese Aufgabe nicht in seinen Bereich fällt und sich jemand anders um das Ticket kümmern soll.

Kommunikation mit dem Kunden

Möglicherweise will man den Kunden eng in die Ticket-Bearbeitung involvieren. Man könnte den Kunden über die einzelnen Schritte und aktuelle Stände informieren.

Wissensdatenbank/ FAQs

Um dafür zu sorgen, dass in Zukunft nicht mehr so viele Tickets erstellt werden müssen und damit die Mitarbeiter nicht so viel zu tun haben, sollte man eine Wissensdatenbank führen.

Diese Wissensdatenbank bzw. FAQs beinhaltet dann alle wichtigen Informationen, sodass die Kunden bevor Sie anrufen in die FAQs schauen.

‍

‍

‍

OTOBO Ticketsystem

OTOBO ist ein sehr gutes Open Source Ticketsystem, es ist außerdem kostenlos und lässt sich sehr stark konfigurieren. Das OTOBO Helpdesk wurde auf Basis von (OTRS)) Community Edition von der Firma Rother OSS entwickelt. In OTOBO kann man festlegen, welche Stati es im Ticketsystem geben soll.

Man kann aber auch sehr komplexe Berechtigungsstrukturen abbilden.

Es gibt außerdem viele Automatisierungen.

OTOBO Erfahrung

Welche Funktionen bietet OTOBO?

Jetzt OTOBO Demo anschauen

Schaue dir jetzt eine Demo des OTOBO Helpdesks an.

OTOBO Ticketsystem Demo

‍

Znuny Ticketsystem

Das Znuny Ticketsystem basiert ebenfalls auf der (OTRS)) Community Edition.

‍

OTOBO Ticketsystemvergleich

Jetzt Ticketsystemvergleich anschauen

Was ist ein Ticketsystem?

Das Ticketsystem speichert Tickets, welche Informationen über ein Problem oder eine Aufgabe enthalten, aus einem Problem ergibt sich meistens auch eine Aufgabe.

Problem -> Aufgabe

‍

‍

Auto ist kaputt -> Auto muss repariert werden

‍

‍

‍

‍

‍

‍

Die Agenten des Ticketsystems bearbeiten und lösen die Aufgaben.

‍

Anwendungsfall Helpdesk

Ein klassischer Anwendungsfall für ein Ticketsystem ist der Support von Kunden.

Wenn ein Kunde ein Problem hat ruft oder emailt er den Mitarbeitern.

1. Kontakt zum Kunden
2. Versuchen das Problem zu lösen

Problem erfolgreich gelöst -> Kunde wird informiert; Ticket wird erfolgreich geschlossen

Kein Erfolg -> Ticket wird Bearbeiter zugeordnet

Ticket ist unlösbar -> Ticket wird erfolglos geschlossen

Ticket kann im Moment nicht gelöst werden -> Warten bis zum Zeitpunkt

‍

FAQs/ Chatbots

Eine Telefon Hotline oder auch Email Beantworten kostet viel Geld.

Um Geld zu sparen, sollte man versuchen die Anzahl der Anfragen bei der Hotline zu verringern, dazu sollte man allen wichtigen Informationen bereits vorher bereitstellen.

FAQs

Die FAQs oder Frequently Asked Questions - Häufig gestellte Fragen sind dabei hilfreich. Man stellt die Antworten auf die wichtigsten Fragen schon vorher per Text bereit. Zusätzlich kann man auch noch Videos zur Erklärung hinzufügen.

Forum

Außerdem kann man ein Forum erstellen, in welchem sich die Kunden Ihre Fragen gegenseitig beantworten.

‍

Chatbots

Ein Chatbot kann dem Kunden Antworten auf seine Fragen geben. Da man beim Chatbot keine echte Person nutzt muss man auch kein Geld bezahlen, außer für die Programmierer die das System entwickelt haben. Der Chatbot bekommt kein Gehalt! Die Helpdesk Mitarbeiter schon!

Ticketsystem im Einsatz in der Software-Entwicklung

Anwendung

Ein Ticketsystem kann auch eingesetzt werden um Aufgaben festzuhalten, welche nicht im direkten Zusammenhang zu einem Problem der Kunden stehen.Dies kann Beispielsweise in einem Software Entwicklungsteam passieren, welche eine App entwickeln.Weit verbreitet ist auch die Agile Software Entwicklung zum Beispiel mit Scrum.

Beschreibung

Tickets sind in diesem Fall Aufgaben.Wenn eine neue Aufgabe erstellt wird, dann wird sie jemandem zugewiesen. Die Aufgabe wird von jemandem bearbeitet.Es wird versucht die Aufgabe fertig zu stellen. Im Ticket kann man den Namen der Aufgabe, Die Aufgaben Beschreibung, Name des Bearbeiters/Besitzer, Dauer der Aufgabe, Schwierigkeit der Aufgabe, Aktueller Fortschrittsgrad. Zusätzlich zum Besitzer oder Bearbeiter kann man noch einen Vorgesetzten im Ticket festhalten, bzw. die Person welche dafür verantwortlich ist, dass die Aufgabe ausgeführt wird. Diese Person kann je nachdem in welchem System oder Umkreis man sich befindet beliebige Namen haben, beispielsweise Reporter, Vorgesetzter, Verantwortlicher, ...

Der Status des Ticket gibt den Fortschrittsgrad der Aufgabe an. Wenn die Aufgabe erledigt ist wird das Ticket geschlossen.

Das kostenlose Ticketsystem OTOBO

Mehr über die Funktionen des OTOBO Ticketsystems erfahren.

Nutze Otobos Demo

OTOBO Kundenportal Demo

OTOBO Agentenportal Demo - Agent‍

‍Wie funktioniert die OTOBO Demo?

Mit unserer Demo, können Sie das OTOBO Ticketsystem testen. Unsere Demo ist kostenlos über die angegebenen Links erreichbar.

OTOBO entstand als Ableger der OTRS Community Edition. Die Firma Rother OSS hat das Ticketsystem erstellt und bringt regelmäßig Neuerungen heraus. Mit Unserer Demo haben Sie Zugriff auf mehrere Accounts. Erstens als "normaler" Agent, ohne Administrationsrechte, Zweitens als Agent mit Administrationsrechten, Drittens als Kundenbenutzer im Kundenportal.

Gefällt Dir die OTOBO Demo?

Wenn Ihnen das OTOBO Ticketsystem, beim Testen der Demo gefällt, dann können Sie sich gerne an uns wenden, um zu besprechen wie Sie am besten Ihr eigenes Ticketsystem erstellen und konfigurieren können. Oft passt das Ticketsystem nicht genau auf Ihre Anforderungen und einige Einstellungen müssen verändert werden. OTOBO hat sehr viele Einstellungen bei denen man gerne mal den Überblick verliert. Wir können Ihnen dann dabei helfen, Ihr eigenes Ticketsystem zu installieren und zu verwalten.

Wie kann man das OTOBO Ticketsystem installieren ?

Dokumentation für die OTOBO Demo

In der OTOBO Demo können Sie unterschiedliche Sachen Testen, es gibt tausende an Funktionen, Sie können sich gerne über das Ticketsystem informieren, wir haben einiges an Dokumentation zu dem Thema geschrieben, welche Ihnen bestimmt weiter helfen kann.

Softoft OTOBO Blog

Demo des OTOBO Agentenportals

OTOBO Demo Agent

Agenten können Tickets erstellen und Tickets bearbeiten. Je nachdem welche Rechte Sie haben, können Sie unterschiedliche Aufgaben erledigen. Agenten ohne Admin-Rechte können nicht auf den Admin Bereich zugreifen. Die Berechtigungen des Agenten legen fest, welchen Zugriff er auf unterschiedliche Queues hat. Queues sind Ansammlungen an Tickets. Dieser OTOBO Demo Agent, hat keinen Zugang zum Admin Bereich. Somit kann er keine Einstellungen ändern. Falls sie ausprobieren wollen wie man Einstellungen ändert oder neue Tickets erstellt dann sollten Sie den Demo Admin nutzen.

In der Demo können Sie gerne mit unterschiedlichen Sachen rum probieren. Zum Beispiel könnten Sie ein Ticket erstellen oder ein Ticket bearbeiten.

Was kann man alles in der OTOBO Demo machen ?

1. Ticket erstellen
2. Ticket bearbeiten
3. Ticket in eine andere Queue verschieben
4. Den Besitzer eines Tickets ändern
5. Seine eingestellte Sprache ändern

und noch viel mehr. Dies ist nur ein ganz kleiner Teil der Funktionen. Tickets haben natürlich auch noch eine Priorität und einen Status.

OTOBO Demo Anmelde Daten Agent

Demo-Nutzer:  agent
Demo-Passwort:  1234

OTOBO Agentenportal Demo - Agent

‍

‍

Beschreibung OTOBO Agentenportal der Demo

Im Agentenportal können sich nur Agenten anmelden. Diese Agenten können Tickets erstellen und bearbeiten.

Kundenbenutzer in der Demo

Jedem Ticket ist in der Regel ein Kundenbenutzer (Endkunde) zugeordnet, diese können sich im Kundenportal anmelden, um zu sehen ob ihr Ticket schon gelöst wurde. Um den Kundenbenutzer zu testen können Sie sich im Demo - Kundenportal als Kundenbenutzer anmelden.

Identitäten im Demo Ticketsystem

‍

• Agent - meldet sich im OTOBO Agentenportal an / er löst die Tickets der Kunden (Kundenbenutzer) , Je nachdem welche Rechte Ihm zu geordnet wurden, hat er unterschiedliche Berechtigungen. Wenn er auf eine Queue keine Berechtigungen hat, dann kann er diese Tickets nicht sehen. Mit den Admin Rechten, welche man hat wenn man sich in der OTOBO Demo als kathi anmeldet (siehe Link). In der Demo hat man dann alle Berechtigungen.

• Kunden - Bei OTOBO sind die Kunden Firmen welche Kunde bei der Firma sind, die das Ticketsystem betreibt - Kunden können sich nicht einloggen; Die Kundenbenutzer hingegen können sich im Kundenportal anmelden. Mit unserer OTOBO Demo kann man sich im Kundenportal anmelden

‍

‍

‍

‍

• Kundenbenutzer - Die OTOBO Kundenbenutzer sind die Endkunden/ Also Mitarbeiter oder Kunden, der Kunden; Die Kundenbenutzer können sich im Kundenportal anmelden um ihre Tickets zu sehen und auch zu bearbeiten. Mit unserer Demo kann man sich im Kundenportal anmelden, man muss nur auf einen der Links klicken oder eben die Seite http://otobo-demo.softoft.de/ und dann den Usernamen und das Passwort eingeben.

‍

‍

‍

Die angegeben Identitäten lassen sich natürlich auch zu anderen Dingen übertragen, der Kunde könnte auch beispielsweise eine Abteilung in einer Firma sein und dann sind die Kundenbenutzer Mitarbeiter in der Abteilung. Des können Sie gerne in der OTOBO Demo testen!

Beispiel der OTOBO Demo:

IT Firma Softoft hat mehrere Kunden, welche Mitarbeiter haben.

‍

• Agenten sind Mitarbeiter von Softoft: Laura und Tobi - Mit dem Demo - Agenten können Sie sich im Agenten Ticketsystem anmelden und neue Tickeets erzeugen. Je nachdem welche Rechte einem Agent zugewiesen sind hat er unterschidliche Berechtigungen. Sie können sowohl unseren OTOBO Demo - Agenten ohne Admin Rechte als auch unseren Agenten mit Admin Rechten. Zu beiden gibt es Links.

‍

‍

‍

‍

• Kunden sind Kunden von Softoft, da B2B, sind diese Kunden Unternehmen: z.B adesso SE, IBM und Google ** Kunden können aber auch ein Abteil oder eine Einheit repräsentieren, Kundenbenutzern sind Kunden zugeordnet. Somit bilden die Kunden im Prinzip auch eine Art Gruppe da, welche im Prinzip jede Mögliche Art von Gruppe sein kann.

‍

‍

‍

‍

• Kundenbenutzer sind nun die Mitarbeiter von adesso SE, IBM und Google: z.B Herr Martin(von adesso) und Herr Kraus(von IBM) ** Kundenbenutzer sind immer einem bestimmten Kunden zugeordnet. In unser Ticketsystem Demo können Sie sich als Kundenbenutzer anmelden. Kundenbenutzer haben ein anderes Portal als die Agenten, diese beiden Portale sind getrennt von einander.

‍

‍

‍

‍

** Die Firmen und Kunden Namen sind erfunden

Demo des OTOBO Kundenportals

Demo-Nutzer:  kunde
Demo-Passwort:  1234

OTOBO Kundenportal Demo

Kundenportal Anmeldung in der Demo

Im Kundenportal können sich nur die Kundenbenutzer anmelden, Agenten können sich nicht im Kundenportal anmelden. Über oben angezeigten Link kann man sich als Kundenbenutzer in unserer OTOBO Demo aus probieren. Sie können gerne ein Ticket erstellen und schauen was passiert.

Welche Funktionen bietet das OTOBO Kundenportal ?

Die Funktionen im Kundenportal sind zwar nicht so groß wie im Agentenportal, man hat aber die Möglichkeit Tickets zu erstellen und Tickets zu bearbeiten. Man bekommt aber keinen Zugriff auf Einstellungen, man hat keine Möglichkeit neue Agenten zu erstellen.

Erfahre mehr über das OTOBO Kundenportal !

Was sind OTOBO Ticketsystem Partner ?

Partner des OTOBO Ticketsystems bieten Services rund um den Helpdesk an. Es gibt folgende Partner: Enterprise Partner, Premium Partner und Qualified Partners. Zusätzlich gibt es auch noch weiter OTOBO Service Provider, welche keine Partner sind. Die Otobo Partner bieten Beratung und Hilfe zum OTOBO Ticketsystem, einige der Partner haben auch Pakete/Plugins für das OTOBO Ticketsystem entwickelt, welche zusätzliche Erweiterungen für das Ticketsystem ermöglichen.

‍

OTOBO Enterprise Partner

‍

‍

OTOBO Premium Partners

‍

‍

‍

‍

‍

‍

‍

‍

‍

‍

‍

‍

‍

OTOBO Qualified Partners

‍

‍

‍

‍

Keine Otobo Partner aber Service Provider:

• Wir, Softoft - https://www.softoft.de
• Perseverance IT Service (Beijing) http://itservice.com.cn/
  
• Cordeos (Hong Kong) - https://www.cordeos.com/
  
• Cordeos (Tokyo)
  
• Cordeos, Singapore – cordeos.com
  
• SEEAS BV -
  
• Cordeos, Manila – cordeos.com
  

Wir machen OTOBO Support

Jetzt unser Support Angebot anschauen!

Demo des OTOBO Ticketsystems

Was ist Otobo?

OTOBO ist ein kostenloses Open Source Ticket System mit umfangreichen Funktionen, im folgenden zeigen wir Dir wie Du die OTOBO Installation in Ubuntu oder Debian durchführen kannst. Es gibt eine "normale" und eine docker Installation für OTOBO. Im folgenden zeigen wir wie man die OTOBO Docker Installation nutzen kann. Um es nutzen zu können benötigt man einen Server auf welchem man die OTOBO Ticketsystem Installation ausführt. Auf dem Server kann das Betriebssystem Debian, Ubuntu, CentOS oder Ähnliches. Sie können das Ticketsystem mit unserer Demo testen:

kostenlose OTOBO Demo

OTOBOs Ticketsystem Quellcode ist öffentlich einsehbar und es kann sogar daran weiter entwickelt werden. Die Programm-Texte befinden sich auf Github.

OTOBO Ticketsystem Github

In dem Öffentlichen Github Repository, kann man Issues Posten, also Bugs im Otobo Ticket System. Außerdem kann man auch selbst am OTOBO Ticketsystem mit kollaborieren, indem man durch einen sogenannten Pull Request den Quellcode verändert. 

Otobo Hosting

Otobo Docker Installation

Das OTOBO Ticketsystem läuft auf einem Server. Der Server sollte Ubuntu Version 20 (oder aber auch neuere Versionen) verwenden.

Server Verwaltung

Ihren Server für das OTOBO Ticketsystem, können Sie bei einer Firma hosten. Zum Beispiel bei Hetzner. Um auf den Server zuzugreifen und Befehle auszuführen, lohnt sich das Programm Putty. Ebenfalls Hilfreich kann das Programm WinScp sein, mit diesem kann man auf die Dateien des Servers auf welchem das OTOBO Ticket System läuft, zugreifen. Nun gibt es noch die Datenbank, um sich von ihrem eigenem Rechner mit der OTOBO Datenbank zu verbinden, müssen sie zuerst die Ports der Docker Container ändern, da nach der Installation, kein Port vom der Datenbank nach außen geöffnet ist. Zum verwalten der OTOBO Datenbank, kann ich das Tool DataGrip empfehlen.

Es gibt aber auch die Möglichkeit OTOBO auf einem eigenem Server laufen zu lassen. Wenn Sie bereits einen eigenen Server haben und kein Geld in einen weiteren Server investieren möchten, dann können Sie die OTOBO Docker Version auch auf Ihren vorhandenen Server installieren. Dabei müssen Sie darauf aufpassen das Sie für Ihre unterschiedlichen Programme verschiedene Ports nutzen. Ein Port kann nämlich nur von einer Applikation genutzt werden.

OTOBO Backups

Es rentiert sich regelmäßig Backups von dem System zu machen, damit man keine Daten verliert. Außerdem empfiehlt es sich bei der Entwicklung des OTOBO Ticketsystems iterativ vorzugehen. Dafür entwickelt man auf der Entwicklungsinstanz, sobald diese fertig ist überträgt man diese auf das Produktiv System So mit verringert man die Wahrscheinlichkeit, dass die Produktivinstanz ausfällt.

Server Hosting für die OTOBO Installation

Für das Hosting vom OTOBO Ticketsystem kann man jeglichen Anbieter verwenden. Der Server sollte aber in Deutschland sein, wegen dem Datenschutz (DSGVO). Außerdem sollte Ubuntu 20 (oder neuer) auf dem Server laufen. Man kann auch Debian oder andere DIstributionen verwenden Im folgenden werde ich Hetzner verwenden.

Auf Server hinzufügen klicken.

‍

1. Deutschen Standort wählen
2. Ubuntu 20 wählen / Debian
3. Standard wählen
4. Eine Option wählen die mindestens 4 GB RAM hat

Fertig! Erstellen.

OTOBO Installation Debian

Statt Ubuntu kann man auch Debian verwenden.

Server Authentifizierung

Für den Server sollten Sie als Authentfizierungs Methode SSH (public-private key) verwenden, da dies viel sicherer und auch praktikabler ist. Nun sollten sie sich mit dem Server verbinden und können jetzt mit der Installation anfangen. Sie können einen private-public key pair wählen, welches Sie bereits haben oder ein neues Paar erstellen. Dies ist relativ einfach möglich. Für zusätzliche Sicherheit können Sie Ihrem private key auch noch eine Passphrase hinzufügen. So müsste der Angreifer Ihren private-key und Ihr Passphrase besitzen. Somit haben sie eine 2-Faktor Authentifizierung umgesetzt und Ihr Server ist sehr gut geschützt.

Sie sollten Ihren private key für sich behalten. Niemandem senden und nirgends im Internet angeben. Dies gilt nicht für Ihren public key, Ihren public key können Sie beliebigen Leuten senden, dies ermächtigt niemandem Zugriff auf Ihren Server. Es ist praktisch unmöglich aus dem public key den private key zu berechnen.

Installations Möglichkeiten des OTOBO Ticketsystems

1. Die normale OTOBO Installation - offizielle Dokumentation zur Installation
2. OTOBO Installation mit Docker - offizielle Dokumentation zur Installation

Bevor man das Ticketsystem installieren kann braucht man zuerst einen Server. Es gibt sehr viele verschiedene Hosting Anbieter oder man nimmt wie oben gezeigt seinen eigenen Server. Außerdem kann man OTOBO natürlich auch lokal auf seinem eigenem Computer, dies kann aber höchstens für Testzwecke Sinn ergeben, ab gesehen davon das Sie das OTOBO System nur alleine auf Ihrem eigenen Rechner nutzen. Andernfalls müsste Ihr eigener Computer dauerhaft an sein und öffentlich zugänglich aus dem Internet sein.

Die Docker Installation wird von OTOBO empfohlen, Sie hat den Vorteil das unterschiedliche Teile der OTOBO Applikation, Webserver, Datenbank, Redis-Cache, Elasticsearch, ... in unterschiedlichen Containern laufen. Die Container haben den Vorteil, das sie nur geringe Abhängigkeiten zu den anderen Containern haben und sich in einer virtuellen Umgebung befinden. Die Container sind mit einem Volume verbunden, auf welchem Daten gespeichert werden können. Die Docker Container können außerdem leicht auf andere Server übertragen werden.

‍

Docker Installation

Mit Installationsskript

Installation mit folgendem Installationsskript:

{new_db_root_password} - muss mit dem Passwort, welches Sie für den root Benutzer der OTOBO Datenbank setzen wollen, ersetzt werden.

curl -L -o /home/install_otobo.sh  https://softoft.de/install-otobo &&
chmod a+x /home/install_otobo.sh &&
bash /home/install_otobo.sh {new_db_root_password}

Das Installationsskript führt die docker Installation des Otobo branches 10_1 ohne SSL Unterstützung durch.

Nachdem das Skript ausgeführt wurde muss der Installer durchlaufen werden. Dafür folgende URL aufrufen http://{yourIPorFQDN}/otobo/installer.pl

‍

Schritt für Schritt

1. Was benötigen wir für die Installtion?

Für die OTOBO Installation benötigen wir einen Server. Haben Wir Bereits im vorherigem Schritt gehostet. Das heißt wir können jetzt mit der OTOBO Installation starten.

2. Installation von Docker, Docker Compose und Git

root> apt-get install git docker docker-compose
root> systemctl enable docker

Man braucht die Pakete um die OTOBO Docker Installation durchführen zu können.

3. Klonen des Github Repositories

Mit rel-10_1 wird die OTOBO Version 10.1 installiert.

docker_admin> cd /opt

docker_admin> git clone https://github.com/RotherOSS/otobo-docker.git --branch rel-10_1 --single-branch

docker_admin> ls otobo-docker    # README.md sollte existieren

‍

4. Erzeugen der Konfigurations .env Datei

In der Konfigurationsdatei .env werden die Einstellungen gespeichert. Je nachdem, ob eine SSL Verschlüsselung benötigt wird oder nicht, muss zwischen der Datei .docker_compose_env_http und .docker_compose_env_https entschieden werden. Eine SSL Verschlüsselung führt dazu ,dass sie das https Protokoll verwenden können. Im Gegensatz zum HTTP Protokoll wird bei HTTPS die gesamte Kommunikation verschlüsselt, sodass keine Nachrichten von dritten mitgelesen können. Das ist vor allem bei sensiblen Daten wichtig, wie Passwörter, Zahlungsinformationen, persönliche Daten.

docker_admin> cd /opt/otobo-docker

docker_admin> cp -p .docker_compose_env_https .env # für HTTP .docker_compose_env_http

Optional - SSL

Danch müssen Sie ein SSL Zertifikat angeben, welches signiert werden muss um gültig zu sein. Dabei gibt es unterschiedliche Anbieter bei welchen man sein Zertifikat verschlüsseln lassen kann. Zum Beispiel bei Lets Encrypt https://letsencrypt.org/.

Danach müssen Sie Die Datei mit Ihrem signierten Zertifikat auf den Server hochladen, dazu bspw. putty oder WinScp verwende(oder irgendein anderes Programm mit welchem Sie Zugriff auf die Dateien Ihres Servers haben). Nun müssen Sie in der .env Datei den Pfad zu Ihrem Zertifikat angeben.

5. Datenbank Passwort festlegen

Ändere das Datenbank root Passwort in der .env Datei.

OTOBO_DB_ROOT_PASSWORD=<Dein_Passwort>

Das Passwort kann frei gewählt werden. Um die .env Datei zu bearbeiten kannst du folgenden Befehl verwenden:

nano .env

Mit nano kannst du ganz simpel Dateien bearbeiten, du kannst aber natürlich ein beliebiges Tool nutzen um das Datenbank Passwort zu ändern. Das festgelegte Passwort, kann im nachhinein noch verändert werden, sollte aber logischerweise ein gutes Passwort sein. Mit diesem Datenbank Zugang kann man alle Daten des Ticketsystems löschen! Gerne können Sie sich das Passwort aufschreiben, Sie können es aber auch immer wieder anschauen in dem Sie die .env Datei öffnen.

6. HTTPS Verschlüsselung einstellen

‍

Falls du nur HTTP verwenden willst kannst du diesen Schritt überspringen!

‍

nginx erfordert für die SSL-Verschlüsselung ein Zertifikat sowie einen privaten Schlüssel.

SSL Zertifikat

Für Testzwecke und beim Entwickeln kann ein selbst signiertes Zertifikat verwendet werden. Grundsätzlich sind jedoch offizielle Zertifikate erforderlich. Mehr dazu, wie Sie ein selbst signiertes Zertifikat erstellen, erfahren Sie z. B. unter https://www.digitalocean.com/community/tutorials/how-to-create-a-self-signed-ssl-certificate-for-nginx-in-ubuntu-18-04.

nginx CA-Chain

Um in nginx eine CA-Chain zusammen mit einem Zertifikat anzugeben, muss das CA-Chain-File mit dem eigentlichen Zertifikat in eine Datei kopiert werden. Das Zertifikat und der private Schlüssel werden in einem Volume hinterlegt, um später von nginx verwendet werden zu können. Legen Sie zunächst das Volume an und kopieren Sie anschließend Zertifikat und Schlüssel hinein:

‍

docker_admin> docker volume create otobo_nginx_ssl

docker_admin> otobo_nginx_ssl_mp=$(docker volume inspect --format '{{ .Mountpoint }}' otobo_nginx_ssl)

docker_admin> echo $otobo_nginx_ssl_mp  # just a sanity check

docker_admin> cp /PathToYourSSLCert/ssl-cert.crt /PathToYourSSLCert/ssl-key.key $otobo_nginx_ssl_mp

Die Namen der kopierten Dateien müssen in die eben angelegte .env-Datei eingegeben werden. Beispiel:

OTOBO_NGINX_SSL_CERTIFICATE=/etc/nginx/ssl/ssl-cert.crt und OTOBO_NGINX_SSL_CERTIFICATE_KEY=/etc/nginx/ssl/ssl-key.key

Bitte passen Sie nur die Dateinamen an. Der Pfad /etc/nginx/ssl/ ist im Docker Image festgeschrieben.

‍

7. Starten der Docker Container

Jetzt starten wir die Docker Container mit docker-compose.

docker_admin> docker-compose up --detach

Danch können Sie mit dem Befehl:

docker ps

alle laufenden Docker Container anschauen, es sollten Ihnen die 5(bzw. 6 bei SSL Verschlüsselung) Container angezeigt werden. Diese sind:

• otobo_web_1
• otobo_daemon_1
• otobo_db_1
• otobo_redis_1
• otobo_elastic_1
• otobo_nginx_1(optional)

Um einzelne Container zu starten, können Sie den Befehl:

docker start <container_name>

Genauso um einzelne container zu stoppen:

docker stop <container_name>

Wenn Sie alle Container stoppen möchten können Sie aus dem Ordner /opt/otobo-docker^{(ist der Standard Installations Ordner, kann je nach Konfiguration auch ein anderer sein)} den Befehl

docker-compose down

Um das System neu zu starten und damit auch alle docker container neu zu starten, ist der Befehl

reboot

sinnvoll.

8. Installation von OTOBO

Führe den OTOBO Installer aus, indem du http://{yourIPorFQDN}/otobo/installer.pl aufrufst.

Folge den Schritten im Installer. Dort kannst du einige wichtige Einstellungen setzen, wie die Email Konfiguration und Ähnliches. All diese Konfigurationen kannst du auch überspringen und dann noch danach ändern.

Wenn nachdem Datenbank Passwort gefragt wird, gebe das in der .env Datei angegebene root Passwort an. Jetzt ist die OTOBO Docker Installation abgeschlossen.

‍

9. Lege dir einen neuen Agenten an

Nun können wir mit OTOBO loslegen. In OTOBO soll der root@localhost Agent nicht verwendet werden. Erstelle dir dafür einen neuen Agent welchem du alle Berechtigungen gibst. Dafür kannst du dir gerne folgende Dokumentation anschauen OTOBO Agent erstellen

‍

10. Habe Viel Spaß mit dem OTOBO Ticketsystem!

Mittlerweile solltest du OTOBO zum Laufen bekommen haben. Wenn du Fragen hast, kannst du diese im OTOBO Forum schreiben, oder du schaust dir noch die offizielle Dokumentation von OTOBO an. Oder schreib mir einfach eine Email an tobias.bueck@softoft.de - tobias.bueck@softoft.de .

‍

Ersten Schritte nach der OTOBO Installation

Domain einstellen

Falls du es noch nicht getan hast, solltest du eine aussagekräftige Domain mit deiner IP Adresse verbinden. "132.342.21.56" ist keine einfache URL. Zum Beispiel www.bestes-ticketsystem.de. Damit du nicht immer wenn du die Seite aufrufst /otobo/index.pl an die URL hängen musst. Kannst deine Domain www.bestes-ticketsystem.de direkt auf 132.342.21.56/otobo/index.pl verweisen. So eine Domain lässt sich auch leicht einrichten. Die Domain, die sie nutzen wollen muss natürlich verfügbar sein. In verschiedenen Online Diensten können Sie sich Domains kaufen. Beispielsweise bei namecheap .

Nachdem Die Ihre Domain erworben haben müssen Sie noch die DNS EInsellungen der DOmain ändern sodass, diese den Inhalt Ihres Otobo Ticketsystems anzeigt.

Ein Ticket in OTOBO erstellen

Nun bist du bereit dein erstes Ticket zu erstellen.

Wenn du dich im Dashboard befindest, dann kannst du ganz oben links, neben deinem Avatar auf das Telefon klicken. Um ein Telefon-Ticket zu erstellen solltest du auf das Telefon klicken, falls du eine Email Ticket erstellen willst dann drück auf das Email Icon. Den Unterschied zwischen Email Tickets und Telefon Ticket, werden wir später noch erläutern. Drücke auf das Telefon Symbol.

‍

Nun sieht man die Ticket Erstell Maske. Dort gibt es verschiedene Felder:

Erklärungen der OTOBO Ticket Felder

• ‍Kundenbenutzer: Die Person die angerufen hat, die E-Mail geschrieben hat.‍
• An Queue: Die Queue welche für solche Probleme Verantwortlich ist‍
• Besitzer: Die Person welche sich um das Ticket kümmern soll‍
• Betreff: Betreff des Tickets/ Die Überschrift über das Problem‍
• Text: Welcher das Problem beschreibt.‍
• Anhänge: wichtige Bilder, Dokumente und Videos bezüglich des Ticket Themas

‍

• ‍Nächster Status des Tickets: welchen Status das Ticket haben soll‍
• Priorität: Priorität des Tickets.‍
• Arbeitseinheiten(Zeiteinheiten) : Neues Feature in OTOBO 10.1

‍

OTOBO Dokumentation

Die offizielle Dokumentation vom OTOBO Ticketsystem befindet sich hier:

OTOBO wiki

Es gibt zwar keinen Wikipedia Artikel über OTOBO, aber einen über OTRS -> wikipedia OTRS Es befinden sich aber auch einige Artikel auf unserer Seite. Es gibt die Möglichkeit im OTOBO Forum Fragen zu Stellen Besuche OTOBOs Forum ; Dort hat man die Möglichkeit Informationen über das OTOBO Ticketsystem zu erhalten. Du kannst im Forum natürlich auch Fragen über die OTOBO Docker Installation stellen.

Nächsten Schritte mit dem OTOBO Ticketsystem

Wie du beim Ticket Erstellen schon bemerkt hast, gibt es sogenannte Queues. Beim Ticket Erstellen legt man fest in welche Queue das jeweilige Ticket gelegt werden soll.

Dashboard

Im Dashboard des OTOBO Ticketsystems befindet sich die Ticket Queue Übersicht.

‍

In der Ticket Queue Übersicht, wird in einer Tabelle angezeigt, wie viele Tickets sich in einer bestimmten Queue in einem gewissen Status befinden.

‍

Dashboard Settings

Jeder Agent hat die Möglichkeit das Dashboard nach den eigenen Vorstellungen einzustellen.

Man kann die Ticket Übersicht ausblenden, in denen man in die Einstellungen vom Dashboard geht.

‍

‍

Ticket-Übersicht Einstellungen

In den Systemkonfigurationen können Änderungen an der Ticket-Queue Übersicht vorgenommen werden

Dafür muss man die Einstellung DashboardBackend###0270-TicketQueueOverview verändern.

‍

Wie funktionieren Systemkonfigurationen des OTOBO Ticketsystems?

‍

Um einzustellen, dass ein Status nicht mehr in der Übersicht angezeigt werden soll, muss dieser beim Punkt States entfernt werden durch klicken des Minus Zeichens.

Neuen Status zur Ticket Queue Ansicht hinzufügen

Damit ein neu angelegter Status auch in der Ticket-Queue Overview angezeigt wird muss dieser mit dem + Zeichen bei States hinzugefügt werden.

Die Nummern geben die Position, bzw. Reihenfolge der Stati in der Ticket-Übersicht an.

Testen der OTOBO Demo

Wenn man in der Übersicht des OTOBO Ticketsystems auf ein Ticket klickt, dann kommt man zu der Ticket-Ansicht(AgentTicketZoom). Dort befinden sich folgende Menü Punkte: Zurück, Sperren, Priorität, Ticket kategorisieren, Personenen, Kommunikation, Warten, Schließen, Sofort Schließen, Verschiedenes und Verschieben.

Beschreibung der Ansicht

In der Überschrift steht der Titel des Tickets sowie die Ticket Nummer. In der Leiste unten drunter hat man mehrere Optionen um das Ticket zu verändern. Auf der rechten Seite sieht man Informationen über das Ticket und den Kunden. Man findet standardmäßig folgende Punkte der Ticket-Informationen: Alter, Erstellt, Erstellt von, Status, Sperre, Priorität, Queue, Kundennummer, Erfasste Zeit und Besitzer.

‍

‍

Dynamisches Feld zur Ansicht hinzufügen

Um zu der Ticket-Informationen Ansicht das eigene Dynamische Feld hinzuzufügen, wird im Admin Bereich die Kachel Dynamische Felder - Oberflächen gewählt.

Dort muss nun das eigene Dynamische Feld zu der Oberfläche AgentTicketZoom hinzugefügt werden.

‍

‍

Nun sieht die Ticket-Information folgendermaßen aus:

Das Dynamische Feld ist jetzt in den Ticket-Informationen zu sehen.

‍

Dynamisches Feld zu einer Option hinzufügen

Um ein Dynamisches Feld bei einer Option in der oberen Leiste hinzuzufügen, wie beispielsweise "Priorität" oder "Ticket kategorisieren", muss das Dynamische Feld nur zu der entsprechenden Oberfläche hinzugefügt werden.

Felder Oberfläschen

• Priorität - AgentTicketPriority
• Ticket kategorisieren - AgentTicketFreeText
• Besitzer - AgentTicketOwner
• Verantwortlicher - AgentTicketResponsible (Wenn Verantwortlicher aktiviert ist)
• Notiz - AgentTicketNote
• Ausgehender Telefonanruf - AgentTicketPhoneOutbound
• Eingehender Telefonanruf - AgentTicketPhoneInbound
• Ausgehende Email - AgentTicketEmail
• Warten - AgentTicketPending
• Schließen - AgentTicketClose

Optionen / Menü Punkte entfernen

In OTOBO ist es außerdem möglich die Menü-Punkte der Ticket-Ansicht zu entfernen.

Dazu muss man das entsprechende MenuModule deaktivieren:

Diese können in der Systemkonfiguration über die Navigation gefunden werden.

‍

Wie kann man OTOBO Einstellungen verändern?

‍

Menü entfernen - Schnell Schließen entfernen

Um nun ein Menü-Modul zu entfernen, muss man es deaktivieren.

Wenn man beispielsweise den Punkt "Schnell Schließen" entfernen will, muss man das MenuModule "QuickClose" deaktivieren.

Danach erscheint der Button "Schnell Schließen" nicht mehr in der Ticket-Ansicht.

‍

‍

Beschreibung

OTOBO bietet eine Menge Konfigurationsmöglichkeiten. In den Systemkonfigurationen, lässt sich fast alles am OTOBO Ticketsystem verändern. Mit diesen Einstellungen kann man das OTOBO Ticketsystem anpassen.

Du brauchst Hilfe beim Anpassen von OTOBO

Die Systemkonfigurationen findet man im Admin Bereich in der Kachel "Systemkonfigurationen".

Systemkonfiguration finden

Es gibt 2 Möglichkeiten, um eine bestimmte Systemkonfiguration zu finden.

Die Erste ist, man nutzt die Baum-Struktur, dabei navigiert man sich, durch die unterschiedlichen Punkte durch. Es ist eine Baum-Struktur, ähnlich wie Ordner im Computer.

Die Zweite Möglichkeit ist, man verwendet die Suche um eine entsprechende Systemkonfiguration zu finde. Dabei gibt man einen entsprechenden Suchbegriff ein, zum Beispiel "Queue", dann findet man alle Systemkonfigurationen, welche mit Queues zu tun haben.

‍

Verändern der Systemkonfiguration

Wenn man eine Systemkonfiguration verändern will, dann muss man zuerst auf bearbeiten drücken, dann die Konfiguration verändern, danach mit dem Haken speichern.

Damit die Veränderungen in Kraft treten, muss man die Systemkonfigurationen in Betrieb nehmen

Was ist das Kunden Portal?

‍

OTOBO hat nicht nur ein Agenten Portal sondern auch ein Kundenportal bzw. customer portal, dieses erreicht man über die URL "DEINEDOMAIN/ otobo/ customer.pl" . Dort können sich die Kundenbenutzer (Customer User) anmelden. Das customer portal ermöglicht es dem Kundenbenutzer, neue Tickets zu erstellen, sowie Tickets zu bearbeiten und Tickets anzuschauen.

Gerne Können Sie das Kunden Portal mit unserer Demo Testen!

Otobo Demo

Kunden Benutzer fürs Kunden Portal erstellen

Neue Kundenbenutzer erstellen dürfen alle Agenten, welche Admin Rechte haben.

Um einen neuen Agenten zu erstellen, muss man in den Admin Bereich gehen und dort die Kundenbenutzer Kachel auswählen. Nachdem man einen Kundenbenutzer erstellt hat, kann sich dieser im OTOBO Kundenportal anmelden. In der Kundenbenutzer Kachel sieht man nun alle bereits bisher erstellten Kundenbenutzer.

‍

Wenn man einen dieser Kundenbenutzer anklickt, dann kann man diesen bearbeiten oder auch löschen, bzw. auf ungültig setzen. Um einen neuen Kundenbenutzer hinzuzufügen klick man auf Kundenbenutzer anlegen.

‍

Für das Login im Kundenportal / customer portal benötigt der Kundenbenutzer seinen Benutzernamen und sein Passwort. Wenn der Kunde sein Passwort vergessen hat, dann kann er sich ein neues Passwort an seine E-Mail schicken lassen.

Man kann Kunden aber auch die Chance geben sich selbst für das customer portal zu registrieren, dies kann über die Einstellung "Customer Panel Create Account" umgestellt werden.

‍

Falls die Einstellung eingestellt ist, können sich Kunden über das Kundenportal registrieren. Man kann über die Einstellung
CustomerPanel CreateAccount:: MailRestrictions:: Blacklist und Whitelist gewisse Emails Blocken oder Freigeben. Zum Beispiel DOmains mit einem gewissen domain name.

‍

In der Login Seite EINEDOMAIN.de/ otobo/ customer.pl gibt es den Link, "Account anfordern", darüber kann man sich einen neuen Account erstellen. Man gibt dort Vorname, Nachname und Email an, danach erhält man sein Passwort per Email, damit dies funktioniert muss natürlich das Versenden von Emails eingestellt sein, darüber gibt es einen separaten Artikel:

Senden von Email-Adressen einstellen

Externe Datenbank für customer portal einbinden

Man kann die Kundenportal Accounts zwar auf diesem Weg manuell eintragen, es ist aber auch möglich diese Daten aus einer externen Datenbank oder einem LDAP zu nehmen. Dafür ist es nötig Inhalte der Datei config.pm zu ändern, diese findet man auf dem Server. Bei einer geringen Menge an Kunden Daten, welche sich nicht so häufig ändern, rentiert es sich mehr die Daten manuell einzutragen. Wenn die Datenmenge größer ist, wird es erforderlich sein eine Datenbank oder LDAP anzubinden, da man sonst viel zu viel Arbeit hätte die Daten manuell zu ändern.

In einer docker Installation ist der Pfad zu der Datei normalerweise: /var/ lib/docker/ volumes/ opt_otobo/ _data/Kernel/ config.pm um auf diese Datei zuzugreifen benötigt man ein Programm, bspw. WinScp oder man benutzt die Kommandozeile/Terminal oder Putty. In dieser Datei findet man dann folgenden Abschnitt:

# CustomerUser
    # (customer user database backend and settings)
    $Self->{CustomerUser} = {
        Name   => Translatable('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',
#            ForeignDB => 0,    # set this to 1 if your table does not have create_time, create_by, change_time and change_by fields

            # CaseSensitive defines if the data storage of your DBMS is case sensitive and will be
            # preconfigured within the database driver by default.
            # If the collation of your data storage differs from the default settings,
            # you can set the current behavior ( either 1 = CaseSensitive or 0 = CaseINSensitive )
            # to fit your environment.
            #
#            CaseSensitive => 0,

            # SearchCaseSensitive will control if the searches within the data storage are performed
            # case sensitively (if possible) or not. Change this option to 1, if you want to search case sensitive.
            # This can improve the performance dramatically on large databases.
            SearchCaseSensitive => 0,
        },

        # customer unique id
        CustomerKey => 'login',

        # customer #
        CustomerID    => 'customer_id',
        CustomerValid => 'valid_id',

        # The last field must always be the email address so that a valid
        #   email address like "John Doe" <john.doe@domain.com> can be constructed from the fields.
        CustomerUserListFields => [ 'first_name', 'last_name', 'email' ],

#        CustomerUserListFields => ['login', 'first_name', 'last_name', 'customer_id', 'email'],
        CustomerUserSearchFields           => [ 'login', 'first_name', 'last_name', 'customer_id' ],
        CustomerUserSearchPrefix           => '*',
        CustomerUserSearchSuffix           => '*',
        CustomerUserSearchListLimit        => 250,
        CustomerUserPostMasterSearchFields => ['email'],
        CustomerUserNameFields             => [ 'title', 'first_name', 'last_name' ],
        CustomerUserEmailUniqCheck         => 1,

#        # Configures the character for joining customer user name parts. Join single space if it is not defined.
#        # CustomerUserNameFieldsJoin => '',

#        # show now own tickets in customer panel, CompanyTickets
#        CustomerUserExcludePrimaryCustomerID => 0,
#        # generate auto logins
#        AutoLoginCreation => 0,
#        # generate auto login prefix
#        AutoLoginCreationPrefix => 'auto',
#        # admin can change customer preferences
#        AdminSetPreferences => 1,
        # use customer company support (reference to company, See CustomerCompany settings)
        CustomerCompanySupport => 1,
        # cache time to live in sec. - cache any database queries
        CacheTTL => 60 * 60 * 24,
#        # Consider this source read only.
#        ReadOnly => 1,
        Map => [

            # Info about dynamic fields:
            #
            # Dynamic Fields of type CustomerUser can be used within the mapping (see example below).
            # The given storage (third column) then can also be used within the following configurations (see above):
            # CustomerUserSearchFields, CustomerUserPostMasterSearchFields, CustomerUserListFields, CustomerUserNameFields
            #
            # Note that the columns 'frontend' and 'readonly' will be ignored for dynamic fields.

            # note: Login, Email and CustomerID needed!
            # var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly, http-link-target, link class(es)
            [ 'UserTitle',        Translatable('Title or salutation'), 'title',          1, 0, 'var', '', 0, undef, undef ],
            [ 'UserFirstname',    Translatable('Firstname'),           'first_name',     1, 1, 'var', '', 0, undef, undef ],
            [ 'UserLastname',     Translatable('Lastname'),            'last_name',      1, 1, 'var', '', 0, undef, undef ],
            [ 'UserLogin',        Translatable('Username'),            'login',          1, 1, 'var', '', 0, undef, undef ],
            [ 'UserPassword',     Translatable('Password'),            'pw',             0, 0, 'var', '', 0, undef, undef ],
            [ 'UserEmail',        Translatable('Email'),               'email',          1, 1, 'var', '', 0, undef, undef ],
#            [ 'UserEmail',        Translatable('Email'),               'email',          1, 1, 'var', '[% Env("CGIHandle") %]?Action=AgentTicketCompose;ResponseID=1;TicketID=[% Data.TicketID | uri %];ArticleID=[% Data.ArticleID | uri %]', 0, '', 'AsPopup OTOBOPopup_TicketAction' ],
            [ 'UserCustomerID',   Translatable('CustomerID'),          'customer_id',    0, 1, 'var', '', 0, undef, undef ],
#            [ 'UserCustomerIDs',  Translatable('CustomerIDs'),         'customer_ids',   1, 0, 'var', '', 0, undef, undef ],
            [ 'UserPhone',        Translatable('Phone'),               'phone',          1, 0, 'var', '', 0, undef, undef ],
            [ 'UserFax',          Translatable('Fax'),                 'fax',            1, 0, 'var', '', 0, undef, undef ],
            [ 'UserMobile',       Translatable('Mobile'),              'mobile',         1, 0, 'var', '', 0, undef, undef ],
            [ 'UserStreet',       Translatable('Street'),              'street',         1, 0, 'var', '', 0, undef, undef ],
            [ 'UserZip',          Translatable('Zip'),                 'zip',            1, 0, 'var', '', 0, undef, undef ],
            [ 'UserCity',         Translatable('City'),                'city',           1, 0, 'var', '', 0, undef, undef ],
            [ 'UserCountry',      Translatable('Country'),             'country',        1, 0, 'var', '', 0, undef, undef ],
            [ 'UserComment',      Translatable('Comment'),             'comments',       1, 0, 'var', '', 0, undef, undef ],
            [ 'ValidID',          Translatable('Valid'),               'valid_id',       0, 1, 'int', '', 0, undef, undef ],

            # Dynamic field example
#            [ 'DynamicField_Name_X', undef, 'Name_X', 0, 0, 'dynamic_field', undef, 0, undef, undef ],
        ],

        # default selections
        Selections => {

#            UserTitle => {
#                'Mr.' => Translatable('Mr.'),
#                'Mrs.' => Translatable('Mrs.'),
#            },
        },
    };

Falls man die Kundendaten aus einer anderen Datenbank nehmen will, muss man dort folgende Einstellungen ändern:

• DSN - Host, Name, Typ und Port der Datenbank
• User - Datenbank-Nutzer
• Password - Datenbank Passwort
• Table - Tabelle, welche die Kundendaten enthält

Danach muss man noch die Tabellen- Spalten ändern, diese findet man in der Map-Tabelle in der 3. Spalte. In dieser Spalte müssen die passenden Attribut Namen aus der Datenbank Tabelle stehen. In dem Fall das man mehr oder weniger Spalten hat, muss man in der Map Tabelle noch Zeilen entfernen oder noch hinzufügen. In der Config.pm hat man noch viel mehr Möglichkeiten, man kann auch die Cache Zeit CacheTTL ändern, sowie ob die Datenbank readonly ist, außerdem noch welche zusätzlichen Felder man haben will. Dabei kann man auch den Typ des Feldes festlegen, zusätzlich hat man auch die Möglichkeit Links zu hinterlegen, welche ausgeführt werden wenn man auf das entsprechende Feld klickt. Das ändern der config.pm hat nämlich nicht nur Auswirkungen auf das Kundenportal sondern auch auf die Kundeninformationen welche beim Ticket erstellen und Ticket anschauen angezeigt werden.

‍

Kunden Benutzer Felder Entfernen oder Hinzufügen

Man kann Felder zum Kundenbenutzer hinzufügen, aber auch entfernen. Dafür muss man die config.pm Datei verändern.

In einer docker Installation ist der Pfad zu der Datei normalerweise: /var/lib/ docker/volumes/ opt_otobo/_data/ Kernel/config.pm um auf diese Datei zuzugreifen benötigt man ein Programm WinScp oder man benutzt die Kommandozeile/Terminal oder Putty. In dieser Datei findet man dann folgenden Abschnitt, wie auch schon im vorherigen Absatz gezeigt wurde.

# CustomerUser
    # (customer user database backend and settings)
    $Self->{CustomerUser} = {
        Name   => Translatable('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',
#            ForeignDB => 0,    # set this to 1 if your table does not have create_time, create_by, change_time and change_by fields

            # CaseSensitive defines if the data storage of your DBMS is case sensitive and will be
            # preconfigured within the database driver by default.
            # If the collation of your data storage differs from the default settings,
            # you can set the current behavior ( either 1 = CaseSensitive or 0 = CaseINSensitive )
            # to fit your environment.
            #
#            CaseSensitive => 0,

            # SearchCaseSensitive will control if the searches within the data storage are performed
            # case sensitively (if possible) or not. Change this option to 1, if you want to search case sensitive.
            # This can improve the performance dramatically on large databases.
            SearchCaseSensitive => 0,
        },

        # customer unique id
        CustomerKey => 'login',

        # customer #
        CustomerID    => 'customer_id',
        CustomerValid => 'valid_id',

        # The last field must always be the email address so that a valid
        #   email address like "John Doe" <john.doe@domain.com> can be constructed from the fields.
        CustomerUserListFields => [ 'first_name', 'last_name', 'email' ],

#        CustomerUserListFields => ['login', 'first_name', 'last_name', 'customer_id', 'email'],
        CustomerUserSearchFields           => [ 'login', 'first_name', 'last_name', 'customer_id' ],
        CustomerUserSearchPrefix           => '*',
        CustomerUserSearchSuffix           => '*',
        CustomerUserSearchListLimit        => 250,
        CustomerUserPostMasterSearchFields => ['email'],
        CustomerUserNameFields             => [ 'title', 'first_name', 'last_name' ],
        CustomerUserEmailUniqCheck         => 1,

#        # Configures the character for joining customer user name parts. Join single space if it is not defined.
#        # CustomerUserNameFieldsJoin => '',

#        # show now own tickets in customer panel, CompanyTickets
#        CustomerUserExcludePrimaryCustomerID => 0,
#        # generate auto logins
#        AutoLoginCreation => 0,
#        # generate auto login prefix
#        AutoLoginCreationPrefix => 'auto',
#        # admin can change customer preferences
#        AdminSetPreferences => 1,
        # use customer company support (reference to company, See CustomerCompany settings)
        CustomerCompanySupport => 1,
        # cache time to live in sec. - cache any database queries
        CacheTTL => 60 * 60 * 24,
#        # Consider this source read only.
#        ReadOnly => 1,
        Map => [

            # Info about dynamic fields:
            #
            # Dynamic Fields of type CustomerUser can be used within the mapping (see example below).
            # The given storage (third column) then can also be used within the following configurations (see above):
            # CustomerUserSearchFields, CustomerUserPostMasterSearchFields, CustomerUserListFields, CustomerUserNameFields
            #
            # Note that the columns 'frontend' and 'readonly' will be ignored for dynamic fields.

            # note: Login, Email and CustomerID needed!
            # var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly, http-link-target, link class(es)
            [ 'UserTitle',        Translatable('Title or salutation'), 'title',          1, 0, 'var', '', 0, undef, undef ],
            [ 'UserFirstname',    Translatable('Firstname'),           'first_name',     1, 1, 'var', '', 0, undef, undef ],
            [ 'UserLastname',     Translatable('Lastname'),            'last_name',      1, 1, 'var', '', 0, undef, undef ],
            [ 'UserLogin',        Translatable('Username'),            'login',          1, 1, 'var', '', 0, undef, undef ],
            [ 'UserPassword',     Translatable('Password'),            'pw',             0, 0, 'var', '', 0, undef, undef ],
            [ 'UserEmail',        Translatable('Email'),               'email',          1, 1, 'var', '', 0, undef, undef ],
#            [ 'UserEmail',        Translatable('Email'),               'email',          1, 1, 'var', '[% Env("CGIHandle") %]?Action=AgentTicketCompose;ResponseID=1;TicketID=[% Data.TicketID | uri %];ArticleID=[% Data.ArticleID | uri %]', 0, '', 'AsPopup OTOBOPopup_TicketAction' ],
            [ 'UserCustomerID',   Translatable('CustomerID'),          'customer_id',    0, 1, 'var', '', 0, undef, undef ],
#            [ 'UserCustomerIDs',  Translatable('CustomerIDs'),         'customer_ids',   1, 0, 'var', '', 0, undef, undef ],
            [ 'UserPhone',        Translatable('Phone'),               'phone',          1, 0, 'var', '', 0, undef, undef ],
            [ 'UserFax',          Translatable('Fax'),                 'fax',            1, 0, 'var', '', 0, undef, undef ],
            [ 'UserMobile',       Translatable('Mobile'),              'mobile',         1, 0, 'var', '', 0, undef, undef ],
            [ 'UserStreet',       Translatable('Street'),              'street',         1, 0, 'var', '', 0, undef, undef ],
            [ 'UserZip',          Translatable('Zip'),                 'zip',            1, 0, 'var', '', 0, undef, undef ],
            [ 'UserCity',         Translatable('City'),                'city',           1, 0, 'var', '', 0, undef, undef ],
            [ 'UserCountry',      Translatable('Country'),             'country',        1, 0, 'var', '', 0, undef, undef ],
            [ 'UserComment',      Translatable('Comment'),             'comments',       1, 0, 'var', '', 0, undef, undef ],
            [ 'ValidID',          Translatable('Valid'),               'valid_id',       0, 1, 'int', '', 0, undef, undef ],

            # Dynamic field example
#            [ 'DynamicField_Name_X', undef, 'Name_X', 0, 0, 'dynamic_field', undef, 0, undef, undef ],
        ],

        # default selections
        Selections => {

#            UserTitle => {
#                'Mr.' => Translatable('Mr.'),
#                'Mrs.' => Translatable('Mrs.'),
#            },
        },
    };

Um ein Feld zu entfernen muss man einfach nur die entsprechende Zeile aus der Map Tabelle entfernen. Dabei muss man aber aufpassen, da man nicht jegliche Felder löschen kann. Dies kann zu Fehlern führen. Felder welche man nicht löschen kann sind, UserLogin, UserEmail und UserPassword. Außerdem sind jene Felder die in den obigen Attributen genannt sind nicht entfernbar. Es gibt diese Attribute CustomerUserListFields, CustomerUserSearchFields, Customner UserPost MasterSearch Fields, Customer UserNameFields, alle in diesen Attributen genannten Feldnamen (Kundenbenutzer Attribute/Spalten) können nicht entfernt werden. Man kann die Feldnamen aber aus den Feldern entfernen und dann die Zeile mit dem Kunden-Attribut löschen.

Man kann Felder nicht nur entfern und hinzufügen sondern auch verändern. Beispielsweise kann man über die zweite Spalte der Map Tabelle in der config.pm Datei den im Agentenportal angezeigten Namen verändern. Zum Beispiel Translatable('Firstname') kann man ändern. Wenn man den Namen in Klammern mit Translatable('X') schreibt, dann wird das Feld übersetzt, sofern ein Eintrag in der Language Datei entdeckt wird. Man kann Namen aber auch ohne Klammern schreiben, wenn man beispielsweise sowie so nur Deutsch Sprachige Nutzer hat kann man auch einfach 'Vorname' schreiben oder 'KundenName'.

Weiterhin hat man auch die Möglichkeit Felder als erforderlich zu definieren dies geht über die 5. Spalte "required". Falls man dort eine 1 eingibt ist das Feld erforderlich, bei einer 0 ist es optional. Wenn man einen neuen Kundenbenutzer für das customer portal erstellt müssen alle required Felder ausgefüllt werden, die optionalen Felder können freigelassen werden. Die Felder UserLogin und Password sollten verpflichtend sein, da sich der Kundenbenutzer andernfalls nicht im Kundenportal anmelden kann.

In der Spalte http-Link kann ein Link angegeben, welcher beim Klicken auf das Attribut aufgerufen wird. Die Kundeninformationen mit dem falls angegeben entsprechenden Link können im Kundeninformationsblock aufgerufen werde. Der Kundeninformationsblock wird beim Ticket erstellen und beim bearbeiten oder anschauen eines Tickets angezeigt.

‍

Kundenbenutzer über LDAP aus einem Active Directory nehmen

Anstatt die Daten aus einer externen Datenbank zu nehmen kann man diese auch aus einem Active Directory nehmen. Dafür muss die Datei /Kernel/Config.pm geändert werden. FOlgendes muss eingefügt werden.

$Self->{CustomerUser} = {
        Name => 'LDAP Backend',
        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 the charset of your ldap server is iso-8859-1, use this:
            # SourceCharset => 'iso-8859-1',
            # die if backend can't work, e. g. can't connect to server
            Die => 0,
            # 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'],
        # Configures the character for joining customer user name parts. Join single space if it is not defined.
        CustomerUserNameFieldsJoin => '',
        # show customer user and customer tickets in customer interface
        CustomerUserExcludePrimaryCustomerID => 0,
        # add a ldap filter for valid users (expert setting)
        # CustomerUserValidFilter => '(!(description=gesperrt))',
        # admin can't change customer preferences
        AdminSetPreferences => 0,
        # cache time to live in sec. - cache any ldap queries
        CacheTTL => 0,
        Map => [
            # note: Login, Email and CustomerID needed!
            # var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly, http-link-target, link class(es)
            [ 'UserTitle',       Translatable('Title or salutation'), 'title',               1, 0, 'var', '', 1, undef, undef ],
            [ 'UserFirstname',   Translatable('Firstname'),           'givenname',           1, 1, 'var', '', 1, undef, undef ],
            [ 'UserLastname',    Translatable('Lastname'),            'sn',                  1, 1, 'var', '', 1, undef, undef ],
            [ 'UserLogin',       Translatable('Username'),            'uid',                 1, 1, 'var', '', 1, undef, undef ],
            [ 'UserEmail',       Translatable('Email'),               'mail',                1, 1, 'var', '', 1, undef, undef ],
            [ 'UserCustomerID',  Translatable('CustomerID'),          'mail',                0, 1, 'var', '', 1, undef, undef ],
            # [ 'UserCustomerIDs', Translatable('CustomerIDs'),         'second_customer_ids', 1, 0, 'var', '', 1, undef, undef ],
            [ 'UserPhone',       Translatable('Phone'),               'telephonenumber',     1, 0, 'var', '', 1, undef, undef ],
            [ 'UserAddress',     Translatable('Address'),             'postaladdress',       1, 0, 'var', '', 1, undef, undef ],
            [ 'UserComment',     Translatable('Comment'),             'description',         1, 0, 'var', '', 1, undef, undef ],

            # this is needed, if "SMIME::FetchFromCustomer" is active
            # [ 'UserSMIMECertificate', 'SMIMECertificate', 'userSMIMECertificate', 0, 1, 'var', '', 1, undef, undef ],

            # Dynamic field example
            # [ 'DynamicField_Name_X', undef, 'Name_X', 0, 0, 'dynamic_field', undef, 0, undef, undef ],
        ],
    };

Danach müssen die angegebenen Einstellungen, wie um Beispiel host, port usw. verändert werden.

Kundenbenutzer - Mandantenfähigkeit

Über das zusätzliche Paket "CustomerMultitenancy", kann man dem Ticketsystem Mandantenfähigkeit hinzufügen.

Beschreibung des Pakets:

Dieses Paket ermöglicht gruppenbasierte Einschränkungen von Kunden- und Kundenbenutzerinformationen für Agenten.
Standardmäßig sind alle Kunden für Agenten sichtbar. Nach der Installation dieses Pakets können die Kunden
einer Agentengruppe zugewiesen werden. Diese Kunden sind dann nur für Agenten sichtbar, die Zugriffsrechte auf diese
bestimmten Gruppe. Auch komplette Kundenquellen können eingeschränkt werden.
Die Zugriffsrechte auf die Kundenbenutzer werden von den auf den Kunden gesetzten Rechten geerbt, können aber auch individuell gesetzt werden.
Diese Funktionalität funktioniert für die Kunden-(Benutzer-)Tabellen von OTOBO und nur lesend für Remote-Datenbanken
als auch LDAP.

(Rother OSS GmbH)

In der Config.pm ist eine Reihe von Anpassungen erforderlich. Sowohl für DB als auch für LDAP ist es notwendig, die Blöcke CustomerCompany und/oder CustomerUser zu ändern. (Falls diese nicht vorhanden sind, kopieren Sie sie bitte für Kernel/Config/Defaults.pm nach Kernel/Config.pm und passen Sie sie dort an!) Um das Setzen der Agentengruppe in AdminCustomer und AdminCustomerUser zu ermöglichen, müssen die Variablen zu den Maps hinzugefügt werden.

$Self->{CustomerUser} = {
# ...
Map => [
# ...
[ 'UserGroupID', Translatable('Only visible to agents in group'),
'group_id', 0, 0, 'var', '', 0, undef, undef ],
# ...
],
};

Somit hat man ein weiteres Feld beim Kundenbenutzer bearbeiten. Jede Reihe sollte einen Gruppen Namen haben. Man kann in der Map aber auch einstellen das Felder readonly sein sollen

Gruppen Beschränkung

UserGroupIDSync => {
# Match group names instead of group IDs.
UseGroupNames => 1,
# Remap group names or IDs.
# The key is the group name/ID on the remote system (DB or LDAP-Attribute)
# and the value is the group name/ID on the local system.
RemoteGroupToLocalGroup => {
'ad-admin-group' => 'admin',
'ad-user-group' => 'users',
},
},

Remote Group beinhaltet die Gruppen Namen aus der angegebenen LDAP oder Datenbank. Die angegebene Remote Gruppe hat dann nur Zugriff auf Kundenbenutzer welche in der angegbenen Local Group sind.

Login im OTOBO Kunden Portal

Für das Login im Kundenportal, muss der Kunde folgende URL aufrufen - DEINEDOMAIN.de/ otobo/customer.pl.

Falls sie Ihr Passwort für das Kundenportal vergessen haben, dann klicken sie auf "Passwort vergessen?". Daraufhin wird eine Email mit einem Link geschickt, nachdem sie auf diesen Link geklickt haben, bekommen Sie eine zweite Email mit Ihrem neuen Passwort. Sie können diese Passwort Vergessen Funktion ein oder aus stellen über die Systemkonfiguration "CustomerPanel LostPassword", über die Einstellung CustomerPanel BodyLost Password sowie die Konfiguration "CustomerPanel BodyLost PasswordToken" können sie Email mit dem Passwort-Link und die Email mit dem Passwort geändert werden.

Kunden Portal Logo ändern

‍

Um das Bild welches beim Kunden Portal Login angezeigt wird zu verändern, muss man in der Systemkonfiguration "Customer Login:: Settings" die URL verändern.

Dort kann man mit der Einstellung "Background" verändern, welches Bild gewählt wird. Sowohl eine URL zu einer Bild Datei, als auch ein Pfad zum Bild auf dem Server sind möglich. Mit "LoginText" kann, man den Text welcher im Kundenportal angezeigt wird verändern.

Dashboard des OTOBO Customer Portals

Nachdem Sie sich im OTOBO Kundenportal eingeloggt haben, landen Sie im Dashboard des OTOBO Kundenportals

Dort können Sie Ihre letzen Tickets einsehen, als auch Links zu externen Tools. Über das Feld Ticket erstellen, können sie ein neues Ticket anlegen.

‍

Kundenportal Dashboard verändern

Man kann in den Systemkonfigurationen des Agentenportals, das Aussehen des OTOBO Dashboards ändern. Diese Konfigurationen befinden sich an folgender Stelle:

Frontend -> Customer -> ModelRegistration

Dort werden alle Navigationselemente festgelegt.

In der Einstellung " CustomerFrontend: :Navigation ###CustomerDashboard## #002-CustomerDashboard" ist das oberste Navigationselement festgelegt. Mit der Prio kann man die Reihenfolge der Navigationselemente ändern. Kleinere kommen zuerst. Mit dem svgIcon, kann man das angezeigt Piktogramm ändern. Mit der Description wird der Hover-Text festgelegt. Mit Group und GroupRo könnten Sie Menüpunkte für bestimmte Kundenbenutzer ausschalten.

Mit der Einstellung " CustomerDashboard: :Configuration:: Text" kann die Seitenüberschrift, sowie der Begrüßungstext geändert werden.

Über die Tiles im Konfigurationspfad Frontend -> Customer -> View -> Dashboard -> Tiles. Können die Elemente des Dashboards geändert werden. Folgende Tiles gibt es im Standard Fall:

• CustomerDashboard :Tiles# ##PlainPicture- 01 definiert das Bild auf dem Dashboard(das ganz unten "Overview"; man könnte das angezeigte Bild austauschen
• CustomerDashboard: :Tiles### PlainText-01 - erzeugt eine Kachel, welche einen Text anzeigt. Standardmäßig steht in diesem "Hello World"
• CustomerDashboard: :Tiles## #NewTicket -ist ein Button zum Erstellen eines Tickets. Es kann die Farbe des Textes eingestellt werden
• CustomerDashboard: :Tiles## #FeaturedLink-01 - zeigt das Bild mit dem Schriftzug Thats new in OTOBO, Background Image Link und Text können verändert werden.
• CustomerDashboard: :Tiles# ##TicketList-01 - zeigt die Liste der Letzten Tickets; Es kann die Reihenfolge, Anzahl der Tickets und weiteres verändert werden
• CustomerDashboard: :Tiles# ##ToolBox-01 - stellt Icons mit Links da

‍

Ticket im OTOBO Kunden Portal erstellen

In der Ticket-Erstell Maske, können Sie verschiedene Attribute festlegen. Die Felder des Ticket Erstellens können Sie im Admin Bereich verändern.

Felder der Ticket-Erstellung:

• Typ: Der Typ des Tickets - z.B Problem oder Frage
• An: Die Queue in welcher das Ticket erstellt werden soll
• Betreff: Die Überschrift des Tickets
• Text: Beschreibung des Tickets
• Dateien: Dort können Dateien hochgeladen und dem Ticket angehängt werden
• Priorität: Wie wichtig das Lösen des Tickets ist

Kundenportal Ticket Informationen

Nachdem man ein Ticket angeklickt hat, kann man alle Artikel (Betreff, Nachrichten) . In den Systemkonfiguration kann man einstellen, welche Attribute in dieser Tabelle angezeigt werden.

Wenn ein Feld auf 1 gesetzt ist, wird es angezeigt. Um Dynamische Felder zu der Ansicht hinzuzufügen, muss man dieses Feld zu der dynamischen Felder Oberfläsche  - Ticket:: Frontend:: CustomerTicketZoom

Tickets im Kunden Portal bearbeiten

Natürlich kann man auch bestehende Tickets bearbeiten. Dafür wählt man ein bestimmtes Ticket aus und wählt dann Antworten aus, daraufhin kann man eine Antwort zum Ticket schreiben.

Daraufhin kann man dem Ticket eine Nachricht hinzufügen, sowie einen neuen Status des Tickets festlegen.

Einstellungen im Kunden Portal ändern

Im Otobo Kundenportal kann der Kundenbenutzer seine persönlichen Einstellungen ändern, dafür muss er die Maus über den unten links befindenden Avatar bewegen und dann auf das Zahnrad drücken. In den Einstellungen können die Sprache, das Passwort, die Anzahl angezeigten Tickets sowie die Ticketaktualisierung geändert werden.

OTOBO Kunden Portal anpassen

Es gibt einige Anpassungsmöglichkeiten für das OTOBO Kundenportal, auf diese können über den Admin Bereich des Agentenportals zugegriffen werden. Die Anpussungs Möglichkeiten findet man in den Systemkonfigurationen. Dort dann unter Frontend -> Customer.

Einstellungs Möglichkeiten

• CustomerFrontend:: Active - schaltet das Kundenportal aus oder an.
• CustomerPanel CreateAccount - gibt Kunden die Möglichkeit sich selbst einen Account zu erstellen
• CustomerPanel LostPassword - schaltet die Passwort vergessen Funktion ein
• Customer Logo - stellt das verwendete Logo im Kundenportal ein
• CustomerPanel BodyLostPassword - stellt die Nachricht, welche das neu eingestelte Passwort hat ein
• CustomerPanel BodyLost PasswordToken - stellt die gesendete Nachricht ein, die gesendet wird wenn jemand auf den Passwort vergessen Button geklickt hat
• CustomerPanel Body NewAccount - stellt die Nachricht ein, welche neue Nutzer des Otobo Ticketsystems erhalten
• Customer PanelCreate Account:: MailRestrictions ::Blacklist - Verbietet es Nutzern mit bestimmten Emails einen Account zu erstellen - Alle Emails welche diesen regulären Ausdruck erfüllen sind verboten
• CustomerPanel CreateAccount:: MailRestrictions:: Whitelist - falls aktiviert, können sich nur Nutzer einen Account erstellen, wessen Email Account diesen regulären Ausdruck erfüllt
• Customer PanelLogin URL - legt die URL des Kundenportal Logins fest

Weitere Felder beim Ticket erstellen im Kunden Portal

Man hat die Möglichkeit noch weitere Felder zur Ticket-Erstell Maske hinzuzufügen. Dies geht über die Dynamischen Felder, es gibt folgende Arten an dynamischen Feldern:

• Kontrollkästchen
• Kontaktdaten
• Datenbank
• Datum
• Datum / Zeit
• Einfachauswahl
• Mehrfachauswahl
• Text
• Textfeld
• Titel
• Webservice

Man kann dort einer dieser Arten auswählen, danach kann man die Einstellungen des Feldes festlegen. Wenn man ein Textfeld hinzufügt, dann kann man Name, Beschriftung, Feldreihenfolge, Tooltip-Text, Anzahl der Zeilen, Anzahl der Spalten, Standardwert und ob man die Eingabe mit einem Regulären Ausdruck auf Richtigkeit prüfen will.

Nachdem das Feld erstellt wurde müssen wir jetzt noch festlegen in welchen Oberflächen das Feld angezeigt werden soll, dafür gehen wir auf die Kachel "Dynamische Felder Oberflächen".

Kundenportal anpassen

Im Admin Bereich des Agentenportals, können Sie das Kundenportal anpassen.

OTOBO Demo des Kundenportals

‍

OTOBO Logo ändern

Sie können im OTOBO Ticketsystem das Logo, welches beim Login angezeigt wird, als auch das Logo im Agenten Bereich und sogar das Logo des Kundenportals verändern. Im folgenden zeigen wir dir, wie du das Logo ändern kannst.

‍

Login Logo ändern

Das Logo welches beim Login angezeigt wird können sie folgendermaßen verändern:

‍

1. Gehen Sie in den Admin Bereich
2. Wählen Sie die Systemkonfigurationen aus (Anleitung der Systemkonfigurationen)
3. Suchen Sie nach "LoginLogo"
4. Verändern der AgentLoginLogo - URL :

Mit der "Style Height", können Sie auch die Höhe des Logos anpassen. Die URL kann eine relative oder eine absolute URL zu dem Logo sein.

‍

Agenten Portal Logo ändern

Das Logo welches oben rechts im Agenten Portal angezeigt wird, können Sie folgendermaßen ändern:

1. Gehen Sie in den Admin Bereich
2. Wählen Sie die Systemkonfigurationen aus (Anleitung der Systemkonfigurationen)

1. Suchen Sie nach "AgentLogo"
2. Verändern Sie die URL der Einstellung "AgentLogo"

‍

Agent Logo Attribute

• StyleHeight : Die Höhe des Logos
• StyleRight : Abstand des Logos nach rechts (höherer Wert verschiebt das Logo nach links)
• StyleTop : Abstand des Logos nach oben (höherer Wert verschiebt das Logo nach unten)
• StyleWidth : Die Breite des Logos
• URL : URL zur Bildquelle, welche als Logo verwendet werden soll (kann eine absolute oder relative URL zu einem Bild sein)

Kunden Portal Logo ändern

‍

Um das Bild welches beim Kunden Portal Login angezeigt wird zu verändern, muss man in der Systemkonfiguration "CustomerLogin::Settings" die URL verändern.

Dort kann man mit der Einstellung "Background" verändern, welches Bild gewählt wird. Sowohl eine URL zu einer Bild Datei, als auch ein Pfad zum Bild auf dem Server sind möglich. Mit "LoginText" kann, man den Text welcher im Kundenportal angezeigt wird verändern.

Beschreibung

Eine Queue im OTOBO Ticketsystem ist eine Sammlung an Tickets. Beim erstellen eines Tickets, wird das Ticket in eine Queue verschoben. Ein Ticket kann aber auch im Nachhinein in eine andere Queue verschoben werden.

Dokumentation OTOBO Queues

In dem Artikel OTOBO Berechitgungskonzept, wird beschrieben, wie man die Berechtigungen von Agenten auf Queues verändern kann.

‍

Queues-Verwalten

‍

‍

Im Admin Bereich kann man in der Kachel Queues, die Queues verwalten und neue hinzufügen.

‍

Neue Queue hinzufügen

Die Gruppe ist dabei wichtig, um die Berechtigungen für die Queue festzulegen. Nur Agenten welche entsprechende Rechte auf die Gruppe der Queue haben, können bestimmte Aktionen in der Queue ausführen.

Mehr zum OTOBO Berechtigungskonzept

‍

‍

OTOBO Ticket Queue Übersicht im Dashboard

Im folgendem Artikel finden Sie mehr darüber, wie sie die Queue Übersicht auf der Startseite verändern können.

OTOBO Ticket Queue Übersicht

‍

‍

Welche Entitäten gibt es im OTOBO Ticketsystem

Einfache und komplexe Unternehmen benötigen eine flexible Möglichkeit, den Zugriff auf ihren Service-Desk zu steuern. Zugriff, Ressourcen und Berechtigungen müssen so aufeinander abgestimmt sein, dass die Benutzer und Kunden Zugriff auf die benötigten Ressourcen haben und ihre Daten bei Bedarf vom System geschützt werden.

OTOBO stellt dafür leistungsfähige Werkzeuge zur Verfügung, deren Verwendung im folgenden Artikelbeschrieben wird.

Im Otobo Ticketsystem gibt es Agenten, Gruppen und Rollen. Die Beziehung dieser ist wichtig um die Berechtigungen der Agenten auf die Queues zu steuern.

Was ist ein Agent im OTOBO Ticketsystem?

Das Agenten- und Zugriffsmanagement für Ihren Service-Desk sollte einfach sein. Flexibilität beim Hinzufügen, Bearbeiten, Entwerten des Zugriffs und ein schneller Überblick darüber, welche Berechtigungen ein Benutzer hat, helfen Ihnen, ein sauberes Berechtigungssystem zu pflegen und Ihr Setup in OTOBO aufzuzeichnen.

OTOBO unterstützt Sie dabei, Agenten innerhalb von OTOBO über mehrere Backends hinweg zu verwalten. OTOBO kann bis zu zehn Backend-Quellen verwenden und sogar einige als schreibgeschützt markieren. Durch die zentrale Verwaltung der Benutzereinstellungen kann ein Administrator im Falle einer unerwarteten Krankheit schnell ein kompromittiertes Konto ungültig setzen oder ein Konto auf Abwesenheitsnotiz setzen.

Verwenden Sie diese Ansicht, um Agenten zum System hinzuzufügen. Eine neue OTOBO-Installation enthält standardmäßig einen Agent mit Administrator-Rechten. Die Ansicht zur Verwaltung der Agenten ist im Modul Agenten in der Gruppe Benutzer, Gruppen & Rollen verfügbar.

Im Otobo Ticketsystem gibt es Agenten, diese sind Nutzer welche das Systemnutzen. Sie können Tickets erstellen und bearbeiten. Welche Zugriffsrechte sie haben, hängt von den Rollen und Gruppen ab denen sie zugeordnet sind.

OTOBO Agenten aus Backend Quelle

Sie können die Agenten Daten auch aus einer externen Quelle nehmen. Entweder aus einem Active Directory oder einer Datenbank. Dies erspart Ihnen die Arbeit alle Agenten manuell einzufügen. Außerdem bleiben die Daten so synchron.

. Um dies zu erreichen, kopieren Sie den folgenden Block aus der Defaults.pm, bei einer docker Installation im Pfad /var /lib / docker /volumes / otobo opt otobo /Kernel /Config und fügen ihn in die Config.pm (ein Verzeichnis höher) ein.

# This is an example configuration for an LDAP auth. backend.

# (take care that Net::LDAP is installed!)

.....

...

‍

.

....

# Net::LDAP new params (if needed - for more info see perldoc Net::LDAP)

#    $Self->{'AuthModule::LDAP::Params'} = {

#        port    => 389,

#        timeout => 120,

#        async   => 0,

#        version => 3,

#    };

# Die if backend can't work, e. g. can't connect to server.

#    $Self->{'AuthModule::LDAP::Die'} = 1;

‍

Das Minimum, das für die Verbindung zu einem Verzeichnis-Server erforderlich ist, sind:

$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';

Host

Der DNS-Name oder die IP Ihres Verzeichnis-Servers.

BaseDN

Der Startpunkt in Ihrem Verzeichnisbaum.

UID

Das Attribut, das für die Anmeldung und Identifizierung verwendet wird. Das ist ein sAMAccountName für ein Active Directory.

‍

‍

Was können Agenten?

Die Agenten können Tickets erstellen, bearbeiten, Prioritäten setzen. Die Unterschiedlichen Agenten sind aber in Ihren Zugriffsrechten beschränkt.

OTOBO Agenten

Wofür werden Gruppen im OTOBO Ticketsystem verwendet ? 

Die Gruppen legen fest welche Zugriffsrechte ein Agent hat. Die Gruppen legen die Berechtigungen der Agenten fest. Eine neue OTOBO-Installation enthält standardmäßig einige Standardgruppen. Die Verwaltung der Gruppen ist im Modul Gruppen in der Gruppe Benutzer, Gruppen und Rollen verfügbar.

Offizielle OTOBO Gruppen Dokumentation

‍

‍

Welche Standard Gruppen gibt es im OTOBO Ticketsystem?

‍

‍

Was gibt es bei der Beziehung von Agenten und Gruppen zu beachten ?

Einzelne Agenten können Zugriff auf eine Gruppe bekommen.

Dabei gibt es mehrere Zugriffsrechte.

Welche Zugriffsrechte gibt es im Ticketsystem?

RO / Read Only

• read-only; Nur Lese Zugriff, Tickets können gelesen werden

‍

‍

Verschieben In / Das Verschieben von Tickets

• Tickets können in eine andere Queue verschoben werden

‍

Erstellen / Das Erstellen von Tickets

• Es dürfen Tickets erstellt werden

‍

Notiz / Notizen zum Ticket hinzufügen

• Es dürfen zu einem bereits erstelltem Ticket Notizen hinzugefügt werden

‍

‍Besitzer / Besitzer des Tickets

• Der Besitzer eines Tickets kann geändert werden.

‍

Priorität / Die Priorität eines Tickets ändern

• Die Priorität des Tickets darf geändert werden.

‍

‍

‍

RW / Read and Write

• read-write; voller Lese und Schreib-Zugriff

‍

Folgende Optionen können in der System::Permission noch hinzugefügt werden.

Wie funktionieren die OTOBO Systemkonfigurationen?

stats / Zugriff auf stats

• Erlaubt den Zugriff auf die Statistik Seite.

Umleiten / E-Mails umleiten

• Das Recht eine E-Mail umzuleiten (mit „Umleiten“-Schaltfläche in der Ticket-Detailansicht)

‍

Verfassen / Das Verfassen von Emails

• Das Recht eine Antwort zu einem Ticket zu verfassen.

‍

Kunde / Kunde des Tickets ändern

• Berechtigungen zum Ändern des Kunden eines Tickets.

‍

Weiterleiten / Weiterleiten einer Nachricht

• Das Recht eine Nachricht weiterzuleiten (mit der „Weiterleiten“-Schaltfläche)

‍

Warten / Ticket auf Warten Setzen

• Das Recht ein Ticket auf „warten“ zu setzen.

‍

Telefon / Telefonanruf hinzufügen

• Das Recht einen Telefonanruf zu einem Ticket hinzuzufügen.

‍

Verantwortlicher / Den Verantwortlichen des Tickets ändern

• Das Recht den Verantwortlichen Agenten eines Tickets zu ändern.

‍

OTOBO Agenten <-> Gruppen

Wozu verwendet man die Rollen?

• ‍Rollen ermöglichen es, mehreren Agenten einfach die selben Zugriffsrechte zugeben. Dies ist möglich indem man eine Rolle erstellt. Die Agenten weist man daraufhin einer Rolle zu.

• Die Rolle legt fest welche Zugriffsrechte die Agenten haben, die dieser Rolle zugeordnet sind..

• Ein Agent kann mehreren Rollen zugeordnet sein.

‍

Wie kann man die Zugriffsrechte verändern?

Die Rollen bieten eine zusätzliche Möglichkeit die Zugriffsrechte im OTOBO Help Desk zu konfigurieren.

Offizielle OTOBO Rollen Dokumentation

Mit den Queues Tickets dem richtigen Team/Abteilung zu ordnen

Die Queues sind Ansammlungen von Tickets. Die Tickets einer Queue können nur von berechtigten Agenten gelesen werden. Über die Gruppen und Rollen ist festgelegt, welcher Agent wie viele Berechtigungen auf eine Queue hat.

‍

OTOBO verwendet Queues, um Ihren Teams eine Struktur zu geben. Queues bieten eine leistungsstarke Möglichkeit, die Arbeit aufzuteilen und an die verantwortliche Personengruppe zu verteilen. In einer neuen OTOBO-Installation gibt es standardmäßig vier Queues: Junk, Misc, Raw und Postmaster.

OTOBO Queue Einstelungen

Queue-Einstellungen

Die folgenden Einstellungen sind verfügbar, wenn Sie diese Ressource hinzufügen oder bearbeiten. Die mit einem Sternchen gekennzeichneten Felder sind Pflichtfelder.

Name *Der Name der Ressource. In dieses Feld können beliebige Zeichen eingegeben werden, einschließlich Großbuchstaben und Leerzeichen. Der Name wird in der Übersichtstabelle angezeigt.Unter-Queue vonEs ist möglich, die neue Queue als Unter-Queue einer existierenden Queue hinzuzufügen. Das wird als Eltern Queue::Kind Queue angezeigt.Gruppe *Es ist möglich, den Zugriff auf die ausgewählte Gruppe zu beschränken. Die Gruppe erstellt einen Berechtigungs-Link zwischen der Queue und einem Agenten oder einem Kundenbenutzer.Freigabe-Zeitintervall MinutenJedes Ticket beim Öffnen, das in dieser Queue gesperrt ist, wird nach der eingestellten Anzahl von Minuten automatisch entsperrt. Der Wert 0 (Standard) bedeutet, dass Tickets in dieser Queue gesperrt bleiben.Eskalation - Zeit für erste Reaktion (Minuten)

Die maximal erlaubte Arbeitszeit, in der ein Agent mit dem Kunden erstmals nach einer Anfrage in Kontakt tritt.

Bemerkung

Die Zeit für die erste Reaktion wird nicht für ein E-Mail-Ticket oder ein Telefon-Ticket ausgelöst, das von einem Agenten erstellt wurde.

Notify byNotify before time limit is reached (in percent).Eskalation - Aktualisierungszeit (Minuten)Die maximal erlaubte Arbeitszeit, innerhalb der ein Agent eine Aktualisierung vornimmt.Notify byNotify before time limit is reached (in percent).Eskalation - Lösungszeit (Minuten)

Die maximal erlaubte Arbeitszeit, innerhalb der das Ticket als „erfolgreich“ markiert wird.

Bemerkung

Die Lösungszeit wird nicht zurückgesetzt, wenn ein Ticket neu geöffnet wird.

Notify byNotify before time limit is reached (in percent).Nachfrage-Option *

Legt das Verhalten bei einer Rückmeldung für geschlossene Tickets fest. Mögliche Werte sind:

neues TicketDie Rückmeldung erstellt ein neues Ticket.möglichDie Rückmeldung öffnet ein bereits geschlossenes Ticket nochmal.ablehnenThe follow up will be rejected.

Siehe auch

See Automatische Antworten chapter for more information.

Ticket sperren nach einer Rückmeldung *

Nur anwendbar, wenn die Rückmeldung Option auf möglich gesetzt ist. Sperrt das zuvor geschlossene Ticket bei Wiedereröffnung für den letzten Besitzer. Dadurch wird sichergestellt, dass eine Rückmeldung für ein Ticket von dem Agenten bearbeitet wird, der dieses Ticket zuvor bearbeitet hat.

Warnung

Abwesenheiten werden dabei nicht berücksichtigt. Verwenden Sie diese Einstellung mit Bedacht, um sicherzustellen, dass es sich um eine Zeitüberschreitung handelt oder in Kombination mit Entsperrzeit-Minuten.

Systemadressen *

Wählen Sie eine der E-Mail-Adressen als Identität für den Sender in dieser Queue.

Bemerkung

Das ist eine ID in der Datenbank. Änderungen an E-Mail-Adressen kann hier negative Auswirkungen haben.

Standardschlüssel zum SignierenDas ist nur aktiv, wenn PGP-Schlüssel oder S/MIME-Zertifikate in der Systemkonfiguration aktiviert ist. Wählen Sie den Standardschlüssel zum Signieren von E-Mails.

‍Anrede *Wählt eine der definierten Anreden.

‍Signatur *Wählt eine der definierten Signaturen.

‍KalenderWählt den Kalender aus, der die Arbeitszeiten für diese Queue definiert. Kalender können in der Systemkonfiguration definiert werden.

‍Gültigkeit *Setzt die Gültigkeit dieser Ressource. Jede Ressource kann nur in OTOBO verwendet werden, wenn dieses Feld auf gültig gesetzt ist. Wenn Sie dieses Feld auf ungültig oder ungültig-temporär setzen, wird die Nutzung der Ressource deaktiviert.

‍KommentarFügen Sie dieser Ressource zusätzliche Informationen hinzu. Es wird empfohlen, dieses Feld als Beschreibung der Ressource zur besseren Übersichtlichkeit immer mit einem vollständigen Satz zu füllen, da der Kommentar auch in der Übersichtstabelle angezeigt wird.‍

Chat-KanalChat-Kanal, der für die Kommunikation zu Tickets in dieser Queue verwendet wird.

Über neue Tickets benachrichtigt werden

Um über neue Tickets aus einer Queue benachrichtigt zu werden, muss der Agent eine Queue abonnieren.

OTOBO Queues Offizielle Dokumentation

OTOBO Email Benachrichtigungen Dokumentation

Was sind Unterqueues?

Eine Queue kann auch noch weitere Unterqueues haben.

Wie kann man kostenlos OTOBO Testen?

Mit unserer Demo können Sie das Ticketsystem kostenlos testen.

Demo von OTOBO

‍

Wie kann man im OTOBO Ticketsystem Benachrichtigungen versenden ?

Das OTOBO Ticket-System sendet Email Benachrichtigungen, bei unterschiedlichen Aktionen(Ticket erstellen, Notiz, Antwort, …) an die Agenten, die dafür eingerichtet wurden.

 Im Admin Bereich des Helpdesks können in der Kachel Email-Adressen, die verwendeten Email-Adressen gesehen und verändert werden.

‍

‍

‍

Was ist das Kommunikationsprotokoll ?

Im Admin → Kommunikationsprotokoll können, alle versendeten E-Mails angeschaut werden.

Manager, Führungskräfte, Teamleiter und Systemadministratoren müssen möglicherweise die Kommunikation in der Vergangenheit verfolgen, um bestimmte Nachrichten zu verfolgen. In einigen Fällen treten Probleme auf, und ein Zielempfänger hat keine Nachricht erhalten. Ohne Zugriff auf die Mailserver-Protokolle ist die Verfolgung der Kommunikation schwierig.

OTOBO führt das Modul Kommunikationsprotokoll ein. Es wurde entwickelt, um die Kommunikation zu verfolgen: Aufbau und Spooling der Mail und der Verbindung zwischen Client und Server.

Verwenden Sie diese Ansicht, um die internen Protokolle über die Kommunikationsabwicklung zu überprüfen. Die Ansicht des Kommunikationsprotokolls ist im Modul Kommunikationsprotokoll in der Gruppe Kommunikation & Benachrichtigungen verfügbar.

‍

‍

Die Übersichtsseite des Kommunikationsprotokolls ist ein Dashboard ähnlicher Bildschirm mit mehreren Metriken, die den Gesamtzustand des Systems in Abhängigkeit von gefilterter Kommunikation anzeigen.

‍

Kontostatus In diesem Widget wird angezeigt, wenn Sie Probleme mit konfigurierten Konten haben, die zum Abrufen oder Senden von Nachrichten verwendet werden.

‍Kommunikationsstatus In diesem Widget wird angezeigt, wenn es Fehler bei der Kontoverbindung oder der Nachrichtenverarbeitung gibt.

‍KommunikationsstatusIn diesem Widget wird angezeigt, wenn derzeit eine aktive Kommunikation im System besteht.

‍Durchschnittliche VerarbeitungszeitIn diesem Widget wird kumulativ die Zeit angezeigt, die benötigt wird, um eine Kommunikation abzuschließen.Sie können den Zeitbereich in der linken Seitenleiste auswählen, um die Kommunikation nach ihrer Erstellungszeit zu filtern. Darüber hinaus können Sie auch dynamisch nach beliebigen Schlüsselwörtern, dem Zustand der Kommunikation und der Sortierung der Übersichtstabelle nach allen Spalten filtern.

Wenn Sie auf einen Eintrag in der Tabelle klicken, wird Ihnen eine Detailansicht der Kommunikation angezeigt.

Wann werden Ticket-Benachrichtigungen versendet ?

Welche Benachrichtigungen an wen gesendet werden, können in der Kachel “Ticket-Benachrichtigungen“ verändert werden.

Standardmäßig gibt es folgende Benachrichtigungen:

‍

‍

Bevor Emails versendet werden, muss man aber noch die Email einrichten, damit OTOBO weiß von welchem Mail die Benachrichtigungen gesendet werden.

Wie kann man das Email Versenden Einrichten ?

Sie müssen in den Systemkonfiguration folgende Einstellungen ändern. Sie müssen das Passwort für Ihre Email SMTP Account angeben, dann noch Host, Port und der User(dies ist meistens die Email Adresse).

• SendmailModule
• SendmailModule::AuthPassword
• SendmailModule::AuthUser
• SendmailModule::Host
• SendmailModule::Port

Gibt es eine OTOBO Demo?

Mit unserer kostenlosen OTOBO Demo können Sie das Ticketsystem ausprobieren.

Unsere OTOBO Demo

Wo finde ich die Systemkonfigurationen?

Email Konto einrichten

Um im Otobo Ticketsystem einzustellen, dass Tickets die an eine bestimmte E-Mail Adresse gesendet werden, auch im Ticketsystem ankommen, kann man die Postmaster Email-Konten nutzen. Bei einer eingehenden EMail können so automatisch Tickets mithilfe von IMAP im OTOBO Helpdesk erstellt werden.

Offizielle OTOBO Dokumentation PostMaster Mail Accounts

Email Konto hinzufügen

Zu den Postmaster Email-Konten gelangt man über den Admin-Bereich. Wenn man dort ein Email Konto hinzufügt hat man folgende Felder.

‍

Wichtiger Hinweis Zur Email Einstellung

OTOBO speichert keine Kopie der Emails im Email-Postfach. Um eine Kopie der Emails zu haben, muss man bei seinem Web-Hoster eine Weiterleitung einrichten.

‍

Weitere Email Einstellungen

In den Systemeinstellungen gibt es weitere Einstellungsmöglichkeiten zu den Postmaster Email Konten:

Verändern der OTOBO Mail Fetch Frequenz

Standardmäßig, holt sich OTOBO alle 10 Minuten die neuen Emails aus dem Postfach. In der Einstellung Daemon:: SchedulerCronTaskManager:: Task###MailAccountFetch kann dies verändert werden.

‍

In dem Screenshot ist die Einstellung so verändert, das jede Minute das Email Postfach abgerufen wird. Die Schedule Angaben sind Cronjob Zeit Angaben . Configuring cron job schedules  |  Cloud Scheduler Documentation  |  Google Cloud

‍

Priorität, Queue, Status

• PostMasterDefaultPriority
• PostMasterDefaultQueue
• PostMasterDefaultState

Mit diesen Einstellungen, kann man die Standard Queue, Priorität und State verändern.

Die Default-Queue wird aber von unserem Email-Einstellungen überschrieben.

Mehr über Prioritäten erfahren

Mehr über Queues erfahren

Mehr über Stati erfahren

Status nach Antwort

Wenn man auf eine Email vom Ticketsystem antwortet, dann wird diese Antwort als Notiz in dem Ticket gespeichert.

Man kann in OTOBO einstellen, dass sich der Status eines Tickets ändert, nachdem eine Nachricht angekommen ist.

Dafür muss die Einstellung PostmasterFollowUpState verändert werden.

‍

PostMaster Filter

Man kann die Ankommenden Emails auch automatisiert verarbeiten, sodass zum Beispiel Emails die ein bestimmtes Wort enthalten in eine andere Queue kommen. Die PostMaster-Filter sind im Admin Bereich abrufbar.

PostMaster Filter Dokumentation

Neuen Postmaster Filter hinzufügen

Wenn man dort ein neues hinzufügt, gelangt man zu folgender Ansicht. Bei den Filterbedingungen, gibt man die Bedingung an, welche dazu führen soll, das eine Wertänderung ausgeführt wird.

Was sind OTOBO-Header?

Die E-Mails von OTOBO enthalten verschieden OTOBO-Header.

Beispiel:

Alle Emails die, das Wort Ticketsystem enthalten, werden in der Queue “Ticketsystem-Queue“ erstellt.

‍

PostMaster Filter Dokumentation

‍

‍

Beschreibung

Mit den Access Control Lists(ACLs) des Otobo Ticketsystems kann man verändern, welche Ticket Optionen ausgeführt werden dürfen und welche Werte man in einem Ticket auswählen kann, unter bestimmten Bedingungen. Die ACLs können im Admin Bereich aufgerufen werden.

Dort kann man alle ACLs sehen, welche bereits erstellt wurden. Mit der Gültigkeit, kann ein ACL aktiviert und deaktiviert werden.

Neues ACL erstellen

Wenn man auf der linken Seite, auf “Neuen ACL erstellen” drückt kann man ein ACL erstellen. Dort gibt man den Namen, des ACLs an, sowie einen Kommentar und eine Beschreibung. Nachdem man auf Speichern gedrückt hat, kommt man in die nächste Ansicht, in welcher man nun einstellen kann, bei welcher Bedingung, welche Werte geändert werden. Ein ACL hat eine Filterbedingung und eine Wertveränderung.

Wenn die Filterbedingung wahr ist, wird die Wertveränderung ausgeführt.

‍

Es gibt folgende Bedingungen:

Werte - Änderung

Mögliche Wertänderungen:

‍

Es können auch mehrere Wertänderung eingestellt werden.

• Possible  -   stellt ein, welche Werte möglich sind
• PossibleNot  -  entfernt Möglichkeiten
• PossibleAdd  - fügt Möglichkeiten hinzu

ACLs in Betrieb nehmen

Damit die ACLs eine Auswirkung haben, muss man diese in Betrieb nehmen. Dies macht man in der ACL Übersicht.

‍

Die Offizielle ACL Dokumentation von OTOBO.

‍

Jetzt ACLs in unserer Demo testen!

Fazit

Mit den OTOBO ACLs kann man komplexe Berechtigungen vergeben. Es lassen sich bestimmte Ticket-Aktionen für Rollen Gruppen oder einzelne Nutzer des OTOBO Ticketsystems erlauben oder verbieten.

Grundsätzlich ist es am besten den Agenten so wenig Berechtigungen wie möglich zugeben.

1. Aus Sicherheitsgründen

2. Damit die Agenten nicht von Optionen abgelenkt werden, die sie gar nicht benötigen

Dabei hat der Agent die Qual der Wahl, da er zu viele Möglichkeiten hat, dabei sollte man die Optionen verringern.

Wie kann man Befehle auf selektierte Tickets ausführen?

Mit dem Otobo Generic Agent kann man eine bestimmte Aktion für ausgewählte Tickets im OTOBO Ticketsystem durchführen. Wenn man im OTOBO Ticketsystem viele Tickets auf einmal verändern will, dann kann der Generic Agent des OTOBO Ticketsystems sehr hilfreich. Es gibt auch die Möglichkeit mit dem Generic Agent eine gewisse Aufgabe in wiederkehrenden Intervallen durchzuführen; bspw. alle 2 Stunden. Somit kann man OTOBO Befehle automatisiert ausführen lassen. Durch Selektieren der Tickets kann auf die Tickets eine bestimmte Aktion auswählen.

Wenn man den Status von Tickets ändern will, kann man dies mit dem Generic Agent erledigen. Man kann sogar befehle Event-basiert ausführen lassen.

Was macht der Generic Agent?

Der Generic-Agent findet sich im OTOBO Admin Bereich in der Kachel "Generic Agent", mit diesem kann man die Befehle erstellen

Erstellung einer neuen wiederkehrenden Aufgabe

Automatische Ausführung

Man erstellt einen neuen Generic Agent. Danach kann man einstellen, ob der Auftrag zu bestimmten Zeiten durchgeführt werden soll, z.B einmal am Tag.

Ereignisbasierte Ausführung

Der Auftrag kann auch bei einem bestimmten Ereignis ausgeführt werden zum Beispiel wenn die Priorität des Tickets verändert wird.

‍

‍

‍

OTOBO Tickets Selektieren

Im Punkt Tickets Selektieren gibt man Kriterien an, nach denen die Tickets ausgewählt werden, auf welche dann bestimmte Aktionen ausgeführt werden. Zum Beispiel alle Tickets mit der Priorität "hoch".

Ticket Änderungen

Unter dem Punkt "Ticket Attribute aktualisieren/hinzufügen" gibt man an was an dem Ticket Attribute geändert werden soll, zum Beispiel Queue "Kundenservice".

‍

Notiz

‍

‍

‍

Man hat noch die Möglichkeit eine Notiz hinzuzufügen.

Ticket Befehle

Zusätzlich kann man auch noch Befehle ausführen. Danach kann man die Änderungen speichern und den Generic Agent ausführen.

Was sind OTOBO Addons ?

Es lassen sich Addons zum OTOBO Ticketsystem hinzufügen. Diese Plugins findet man im Admin-Bereich des OTOBO Ticketsystems in der Kachel "Paketverwaltung" (Package Manager). Die OTOBO Erweiterungen lassen sich im Paketmanager des Admin Bereichs installieren, diese Addons fügen zusätzliche Funktionen zu OTOBO hinzu. Alle verfügbaren Addons sind kostenlos. Die Erweiterungen lassen sich natürlich auch wieder deinstallieren. Es gibt einige OTOBO Pakete welche von OTOBO selbst entwickelt wurden, außerdem gibt es aber auch noch Plugins welche von anderen Firmen erstellt wurden. Die Addons lädt man über die Verzeichnisse (siehe im Bild unten links "Verzeichnis Aktualisieren"). Zu den meisten der Pakete gibt es Dokumentation, welche man nutzen kann. Diese Addon Dokumentation befindet sich in der zweiten Spalte der untenstehenden Tabelle.

Im unten stehenden Bild sieht man außerdem noch die Version von dem Plugin, den Anbieter, in diesem Fall die Rother OSS GmbH (die Ersteller von OTOBO). Es gibt dazu noch eine kurze Beschreibung zu dem Add-On. Bei Aktion kann man das Plugin installieren. Um Addons von anderen Anbietern anschauen zu können müssen Sie bei Verzeichnis aktualisieren, "OTOBO Addons", mit einem anderen Verzeichnis wechseln.

Über "Pakete installieren", kann man über eine Datei ein zusätzliches Addon installieren, dabei lädt man eine Datei hoch. Danach wird das Plugin installiert. Mit dieser Funktionalität, kann man eigene OTOBO Pakete entwickeln. Diese dann an andere Unternehmen schicken, welche diese dann ganz einfach installieren kann. Weiter unten in diesem Artikel erklären wir ganz grob wie das Entwickeln eines Addons ungefähr funktioniert. Für genaueres sollten Sie sich aber die offizielle OTOBO Dokumentation anschauen.

‍

‍

Finde Heraus wie dir die OTOBO Add-Ons helfen können!

• AppointmentToTicket -
• CustomerMultitenancy - Plugin ermöglicht Gruppenbasierte Mandantenfähigkeit
• DownloadAllAttachments - Plugin ermöglicht den Download aller Anhänge eines Tickets
• DynamicFieldAttachment - Dieses Plugin fügt den Dynamic Field Typen Attachment hinzu
• CodePolicy - OTOBO Add-On zum überprüfen der Code Quality
• FAQ - Add-On zum hinzufügen von FAQ - Funktionalität
• Fred - Plugin zur Hilfe der Entwicklung
• ITSM - Plugin für das IT Service Management
• MailAccount-OAuth2 - Plugin welches erlaubt Emails über OAuth2 zu erhalten - Wie kann man einen OAuth2 Account hinzufügen?
• MakticketSeenUnseen - Plugin,welches die Möglichkeit gibt Tickets als gelesen oder ungelesen zu markieren
• MasterSlave - Add-On, welches die Ticket Master/Slave Funktion hinzufügt
• Survey - OTOBO Plugin für Umfragen an Kunden
• System Monitoring - OTOBO Addon welches eine Schnittstelle zur System Monitoring Suite bereitstellt
• Time Accounting - OTOBO Plugin für das Zeiteintragungs Modul

Im Video sehen Sie, wie man ein Plugin installieren kann. In folgendem Video zeigen wir wie man das ITSM-Plugin installieren kann:

Das Installieren eines OTOBO Addons ist sehr einfach.

Erfahre wie du ein Plugin installieren kannst

Wenn du dich für ein OTOBO Plugin entschieden hast, welches du auf dem OTOBO Ticket System installieren willst. Dann kannst Du auf folgenden Installieren Link klicken:

Wenn du beispielsweise, das ITSM Paket installieren willst, dann sieht der Installationsprozess folgendermaßen aus:

Es gibt dort einige Hinweise zu dem Plugin, welche auf diesem Bild leider schlecht zu sehen sind. Oben sehen Sie welche Pakete installiert werden, bedeutet, dass das ITSM Paket mehrere Pakete umfasst. Welche alle installiert werden, wenn man die ITSM Funktionen nutzen will. Unter dem Punkt Achtung gibt es einige Warnungen.

Nach erfolgreicher Installation sieht man in der Plugin Übersicht, welche Pakete installiert sind. Nun sehen wir welche Pakete für das ITSM Add-On installiert wurden. Bei Status sieht man, dass die Pakte installiert sind. Das Add-On ist nun installiert und sie können jetzt die ITSM Funktionen nutzen. Im Admin Bereich haben Sie nun auch im Falle des ITSM Pakets weitere Kacheln, es fügen aber nicht alle Addons neue Kacheln hinzu. Das ITSM Paket ist sehr umfangreich und ist nur zu empfehlen wenn man es wirklich braucht. Durch das Installieren des ITSM Pakets wird das Ticketsystem nämlich viel komplexer.

Wie erhalte ich Informationen über ein Plugin?

Zu den meisten Plugins gibt es eine zusätzliche Dokumentation. Diese findet man bei den Plugins in der 2. Spalte. Wenn man auf das Icon klickt, dann wird eine PDF Datei mit der Dokumentation heruntergeladen.

Noch Mehr Plugins

Es gibt auch die Möglichkeit noch weitere Plugins aus anderen Repositories zu laden, dafür muss man bei den Repositiories auf der linken Seite des Bildschirms, das Repository der Wahl auswählen und dann auf neu laden klicken. Dabei handelt es sich um Plugins, welche nicht von OTOBO selbst sondern von anderen Unternehmen entwickelt wurden.

‍

Es gibt folgende Repositiories, mit diesen Plugins / Addons:

Welche weiteren Erweiterungen gibt es?

‍

Dort sehen Sie nun einige Plugins, diese Plugins sind wie man sieht alle von der Firma Perl-Services entwickelt worden. Auch diese Add-Ons sind alle kostenlos.

Im Verzeichnis OTOBO Addons gibt es folgende Plugins:

• ChangeArticleCustomerVisibility - Sichtbarkeit für Kunden von Artikeln ändern
• CustomerTicketOverviewStateCategory - Status und Service können als Ticketkategorien
• DashboardMyTickets - Ein Dashboardwidget, das alle Tickets eines Agentzen anzeigt
• DynamicFieldOTOBOAgents - OTOBO-Agenten in einem Dropdown als Dynamisches Feld
• DynamicFieldRoText - Zeige einen Text in einem Read-Only Textfeld
• QuickCLose - EIn Modul mit dem Tickets einfacher, schneller geschlossen werden können
• QuickOwnerChange - Ticketbesitzer leichter wechseln.
• TicketCheckList - Eine Checkliste für Tickets
• TransitionActionsShowParams - Zeige Aktionsmodul-Parameter in Übergangsaktionen

Third-Party Addons

Bisher gibt es noch nicht so viele Third Party Plugins.

Eigenes Plugin entwickeln

Ebenso gibt es auch noch die Möglichkeit eigene Plugins zu entwickeln. Um ein Plugin zu erstellen muss man einigen Schritten folgen.

1. Ein Terminal (Putty) öffnen und sich per SSH mit dem Otobo Server verbinden.
2. Dort einige Befehle ausführen (siehe offizielle OTOBO Dokumentation)

Nun führt man seine gewünschten Änderungen an beliebigen Dateien vor. Beim erstellen, des Plugins gibt man nun an, welche Dateien man verändert hat. Darauf folgend hat man nun ein Plugin entwickelt .Dieses Plugin hat eine Versionsnummer, wenn man eine neue Version erstellen will, muss man daran denken die Versionsnummer zu erhöhen.

Nun kann man das Plugin auch ganz einfach auf einem anderen OTOBO Ticketsystem installieren. Dafür muss man lediglich die Plugin-Datei übertragen.

Beschreibung der vorhandenen Erweiterungen

Mail Account OAuth 2

Mit dem Plugin Mail Account OAuth2 kann man das Abholen von Mails über OAuth2 einstellen.

Artikel über OAuth2

CustomerMultitenancy Plugin

Mit dem Customer Multitenancy Add On kann man Kundenbenutzer Gruppen zuordnen. Die Agenten können dann nur Kundenbenutzer aus bestimmten Gruppen betrachten.

Mandantenfähigkeit Plugin

Add On - AppointmentToTicket

Beschreibung

Dieses Plugin bietet die Funktionalität, automatisch ein Ticket mit konfigurierbaren Parametern zu einem frei wählbaren Zeitpunkt in Bezug auf einen Termin zu erstellen. Die Ticketerstellung wird in der Maske AppointmentEdit unter dem Abschnitt 'Ticketerstellung' initiiert. Ein Zeitpunkt
Zeitpunkt relativ zum Termin sowie die Ticketdaten können konfiguriert werden. Wiederkehrende Termine werden
unterstützt.
Die Funktion unterstützt zur Zeit keine dynamischen Felder vom Typ Datenbank.

Systemkonfigurationen

Loader::Module: :AgentAppointmentCalendarOverview### 009-AppointmentTicket

Loadermodul-Registrierung für die Agentenschnittstelle.

Ticket::Frontend: :AgentAppointmentEdit###ServiceMandatory

Stellt ein ob der Service vom Agenten eingestellt werden muss

Ticket::Frontend:: AgentAppointmentEdit###DynamicField

Dynamische Felder, die in der Terminbearbeitungsmaske der Agentenschnittstelle angezeigt werden

Ticket::Frontend: :AgentAppointmentEdit## #StateDefault

Legt den Standardnachfolgestatus für neue Tickets in der Schnittstelle AgentAppointmentEdit fest.

Ticket::Frontend::AgentAppointmentEdit## #SLAMandatory

Legt fest, ob SLAs vom Agenten ausgewählt werden muss.

‍

Ticket:: Frontend::AgentAppointmentEdit# ##Priority

Legt die Standardpriorität für neue Tickets in der Schnittstelle AgentAppointmentEdit fest.

‍

Ticket::Frontend: :AgentAppointmentEdit###StateType

Ermittelt die nächstmöglichen Ticketzustände nach der Erstellung eines neuen Tickets aus einem Kalendertermin in der Agentenschnittstelle.

DynamicFieldScreens# ##AppointmentTickets

Diese Konfiguration definiert alle möglichen Bildschirme, um dynamische Felder zu aktivieren oder zu deaktivieren.

‍

DynamicFieldAttachment Plugin

Beschreibung

1. Ein DynamicFieldAttachment hinzufügen

Diese Funktion hält ein Konfigurationsinterface zur Erstellung von DynamicFieldAttachments bereit. Auf die gleiche Weise, auf die auch andere Dynamische Felder angelegt werden, können DynamicFieldAttachments über ADMIN -> Ticket Einstellungen -> Dynamische Felder angelegt werden. Darin ist auswählbar, ob dass gewünschte Feld ein Artikel oder ein Ticket Feld sein soll. Artikel Felder nehmen Anhänge für jeden Ticket-Artikel auf. Anhänge die in einem DynamicFieldAttachment vom Typ Artikel gespeichert sind, können nur heruntergeladen, jedoch nicht gelöscht oder geändert werden. Ticket Felder nehmen Anhänge für jedes Ticket auf. Anhänge die in einem DynamicFieldAttachment vom Typ Ticket gespeichert sind, können heruntergeladen und gelöscht werden. Wie auch andere Dynamische Felder müssen DynamicFieldAttachments einen einzigartigen

"Namen" haben, der nur aus Buchstaben oder Ganzzahlen bestehen darf.

Die "Beschriftung" für DynamicFieldAttachments kann frei gewählt werden und wird als Titel

des Felds in der OTOBO Benutzeroberfläche angezeigt.

Die "Feldreihenfolge" erlaubt es dem Administrator, die Anzeigereihenfolge bezogen auf

andere angelegte Dynamische Felder festzulegen.

"Gültigkeit" muss für alle Felder, die in Verwendung sind, auf "gültig" gestellt sein. Wenn die

Gültigkeit auf "ungültig" gestellt wird, verschwinden die Dynamischen Felder aus allen OTOBO

Oberflächen. "Maximale Anzahl an Dokumenten" ist eine verpflichtende Einstellung, welche die maximale Anzahl an Anhängen die dieses DynamicFieldAttachment pro Ticket oder Artikel aufnehmen kann, festlegt. Wird dieser Wert erhöht, können mehr Anhänge in das DynamicFieldAttachment gespeichert werden. Wird der Wert reduziert, werden keine bestehenden Anhänge gelöscht, lediglich beim Anlegen neuer Tickets oder der Veränderung von DynamicFieldAttachment-Ticket Feldern stehen nur mehr die reduzierte Anzahl an Hochlade-Optionen zur Verfügung. "Maximale Dateigröße" ist eine verpflichtende Einstellung, welche die Maximalgröße die eine hochgeladene Datei haben darf in MegaByte zeigt. Wenn ein Agent oder Admin ein Dokument

größer als das hier angegebene Maximum hochlädt, wird das Dokument zuerst akzeptiert.

Sobald das Hochladen abgeschlossen ist, wird die Dokumenten Größe überprüft. Das Dokument

wird gelöscht, sollte es größer als das hier angegebene Maximum sein, sowie der Agent

oder Admin darüber informiert, dass das Dokument gelöscht worden ist weil es die Maximale

Dateigröße überschritten hat.

2. DynamicFieldAttachments konfigurieren um sie in der Agent Oberfläche anzuzeigen

So wie auch andere Dynamische Felder müssen DynamicFieldAttachments in den Oberflächen Bereichen hinzugefügt werden, in denen sie angezeigt werden sollen.

Dies kann über ADMIN -> Systemverwaltung -> SysConfig gemacht werden, in der links die

Auswahl "Ticket" gewählt werden muss.

Für jeden Oberflächenbereich (Frontend), in denen DynamicFieldAttachments angezeigt werden sollen, muss der Admin in dessen Konfiguration gehen. Beispiele:

Frontend:: Agent::Ticket ::ViewZoom für die Ticketanzeige.

Frontend:: Agent::Ticket: :ViewPhoneNew für die Oberfläche, die für neue Telefontickets angezeigt wird.

Frontend: :Agent::Ticket: :ViewNote für die Notiz Oberfläche.

In jeder dieser Oberflächen Konfigurationen gibt es den Punkt Ticket::Frontend::AgentTicketOberflächenname###DynamicField. Dort muss der Admin einen Wert hinzufügen in dem

er das "+" Symbol anklickt. Es erscheint eine neue Zeile, in die unter "Schlüssel" der Name

des DynamicFieldAttachments sowie unter "Inhalt" die Zahl 1 für das Anzeigen des DynamicFieldAttachments bzw. die Zahl 2 um dieses Feld zu einem Pflichtfeld in der Oberfläche zu

machen, eingetragen werden muss.

‍

ImportExportTicket Plugin

Beschreibung

Im Bereich ImportExport der Verwaltungsoberfläche ist ein neues Backend (Ticket) verfügbar. Die allgemeine Verwendung ist die gleiche wie bei den anderen ImportExport-Modulen. Identifikatoren können für Tickets und Artikel verwendet werden, um möglicherweiseden Artikel zu überspringen. Die Regeln sind wie folgt:

- TicketID oder TicketNumber müssen als Bezeichner für die Identifizierung von Tickets angegeben werden.

- Article_ArticleID muss als Bezeichner für die Identifizierung von Artikeln angegeben werden.

- Wenn die Kennung verwendet wird und das Objekt im System gefunden wird, werden Tickets nur aktualisiert, anstatt erstellt, Artikel werden übersprungen

- Unabhängig davon, ob die Identifizierung verwendet wird oder nicht, wenn Objekte erstellt werden, werden TicketID und ArticleID von OTOBO neu generiert, TicketNumber (falls enthalten) wird auf diejenige der csv gesetzt.Letzteres führt zu einem Importfehler, wenn die TicketNumber bereits existiert (keine Identifikation verwendet), und kann auch problematisch sein, wenn sie aus einem System mit einer anderen SystemID oder einem anderen TicketNumber Generator importiert wird - mit Vorsicht verwenden.

Bei Verwendung der erweiterten Synchronisation müssen sowohl TicketID als auch Article_ArticleID angegeben werden.

MasterSlave Plugin

Kapitel 1. Liste der Merkmale

1. Basis-Modus

• Dies ist der Standardmodus für dieses Paket. Im Basismodus ist es möglich, ein Master-Ticket und einige Slave-Tickets wie folgt zu definieren Aktualisierungen der Master-Tickets:
• Antworten (neue Artikel werden per E-Mail gesendet)
• Notizen (jeder neue Artikel)
• Statusänderungen (einschließlich ausstehender Zeiteinstellungen)
• Änderungen der Priorität
• Änderungen des Eigentümers
• Verantwortliche Änderungen
• Änderungen des Sperrstatus

Warnung

Im Grundmodus kann der Master-Slave-Status nicht geändert werden.

2. Erweiterter Modus

Der erweiterte Modus ermöglicht eine flexiblere Nutzung der Master-Slave-Beziehungen durch Unterstützung für die folgenden Aktionen hinzugefügt wird:

• Neue Master Slave-Tickets können in neue Master-Tickets umgewandelt werden.
• Slave von Ticket# ***** Master-Tickets können in Slave-Tickets eines anderen Master-Tickets umgewandelt werden.
• Aufgelöster Master Master-Tickets können zu normalen Tickets werden.
• Aufgelöster Slave Slave-Tickets können zu normalen Tickets werden.

Hinweis

Die oben genannten Funktionen können in der SysConfig aktiviert oder deaktiviert werden, weitere Informationen finden Sie im Kapitel "Konfiguration" nachlesen.

MasterSlave - Bildschirm

Eine neue Schaltfläche "MasterSlave" wird in das Ticket-Menü im Ticket-Zoom-Bildschirm eingefügt.

Hinweis

Während dieser Bildschirm auch im Basismodus verfügbar ist, ist das Feld "Master-Ticket" nicht verfügbar, sondern nur im erweiterten Modus, wo dieser Bildschirm die Änderung des Master

Slave-Status.

2.2. Bulk-Aktion

Wenn der erweiterte Modus aktiviert ist, ermöglicht der Bulk Action-Bildschirm das Feld "Master Ticket", um die Änderung des MasterSlave-Status.

3. Ersetzen von Kunden aus dem Master-Ticket

Wenn ein neuer Artikel auf dem Master-Ticket erstellt wird, repliziert das Slave-Ticket den Artikel mit dem Kunden aus dem Master-Ticket und nicht mit dem eigenen aus dem Slave-Ticket. Aktivierte Artikeltypen, die in der SysConfig-Option "ReplaceCustomerRealNameOnSlaveArticleTypes" definiert sind, behalten den Kunden bei, der in den Slave-Tickets für Master-Tickets eingestellt ist replizierte Artikel.

‍

Installieren des ITSM Plugins

Das OTOBO ITSM Add-On, kann über den Packet-Manager kostenlos installiert werden.

IT-Service-Management (ITSM) bezeichnet die Gesamtheit von Maßnahmen und Methoden, die nötig sind, um die bestmögliche Unterstützung von Geschäftsprozessen (GP) durch die IT-Organisation zu erreichen. ITSM beschreibt insofern den Wandel der Informationstechnik zur Kunden- und Serviceorientierung. Von Bedeutung ist die Gewährleistung und Überwachung der Business Services, also die für den Kunden sichtbaren IT-Dienstleistungen. Auf diese Weise können kontinuierlich Effizienz, Qualität, und Wirtschaftlichkeit der jeweiligen IT-Organisation verbessert werden sowie gemeinsame Wertschöpfung mit dem Kunden erzeugt werden. - Quelle: https://de.wikipedia.org/wiki/IT-Service-Management

In OTOBO lässt sich das ITSM Plugin installieren. Dies ist über den Paketmanager möglich. Dieser befindet sich im Admin Bereich.

Dort kann man nun das ITSM Plugin installieren.

Fazit

Bei den OTOBO Ticketsystem Plugins handelt es sich um eine sehr gute Methode, um noch weitere Funktionen zum System hinzuzufügen. OTOBO bietet sehr viele nützliche kostenlose Addons an. Außerdem gibt es aber auch noch OTOBO Plugins, welche von anderen Firmen entwickelt wurden.

Funktion der Skins

Es ist möglich das Aussehen des OTOBO Ticketsystems zu verändern, dafür kann man einen neuen Skin erstellen.

Jeder Agent kann selbst auswählen welchen Skin er verwenden will. Nach der OTOBO Installation gibt es nur den Standard Skin. Der OTOBO Skin definiert das Design der Oberfläche. In seinen persönlichen Einstellungen, findet man die Option seinen aktuellen Skin durch einen anderen Skin zu ersetzen.

‍

Neuen Skin erstellen

CSS verändern

Falls Sie eine docker OTOBO Installation haben, finden sich die Skins in folgendem Ordner :

/var/lib/docker /volumes/ otobo_opt_otobo /_data/var/ httpd/htdocs/ skins/Agent andernfalls in $OTOBO_HOME/ var/httpd/ htdocs/skins/ Agent/ $SKIN_NAME

Neuer Ordner

Wenn noch kein Skin hinzugefügt wurde, dann findest sich in diesem Pfad nur der Ordner "default". Um einen neuen Skin hinzuzufügen muss man zuerst einen neuen Ordner hinzufügen. Zum Beispiel "my_skin".

Design Verändern

Um nun das Design zu verändern kann man in den Ordner "my_skin" den Ordner "css" erstellen. Die Skins funktionieren so, das immer der Standard CSS Skin geladen wird. In dem eigenem Skin kann man daraufhin, die Werte aus dem Standard Skin überschreiben. Indem man Beispielsweise CSS Klassen aus dem Default Skin überschreibt:

CSS aus dem Standard Skin:

/* Skin/default/Core.css
.Navigation{
	height:100px;
}

Könnte man zum Beispiel mit:

/* Skin/my_skin/Core.css
.Navigation{
	height:30px;
}

überschreiben.

Daraufhin muss man noch eine Konfigurations Datei im Ordner $OTOBO-HOME/ Kernel/ Config/ Files/ XML/{skin Name}.xml .Diese sollte folgende Struktur haben:

<?xml version="1.0" encoding="utf-8" ?>
<otobo_config version="2.0" init="Changes">
<ConfigItem Name="AgentLogo" Required="0" Valid="1">
        <Description Translatable="0">The logo shown in the header of the agent interface. The URL to the image must be a relative URL to the skin image directory.</Description>
        <Group>Framework</Group>
        <SubGroup>Frontend::Agent</SubGroup>
        <Setting>
            <Hash>
                <Item Key="URL">https://otobo.de/wp-content/uploads/2019/12/Otobo_Wortmarke_Sub_Digital_Blau_156hoch-zugeschnitten-300x113.png</Item>
                <Item Key="StyleTop">13px</Item>
                <Item Key="StyleRight">75px</Item>
                <Item Key="StyleHeight">67px</Item>
                <Item Key="StyleWidth">244px</Item>
            </Hash>
        </Setting>
    </ConfigItem>

<ConfigItem Name="Loader::Agent::Skin###001-softoftSkin" Required="0" Valid="1">
        <Description Translatable="0"></Description>
        <Group>Framework</Group>
        <SubGroup>Frontend::Agent</SubGroup>
        <Setting>
            <Hash>
                <Item Key="InternalName">softoftSkin</Item>
                <Item Key="VisibleName">softoftSkin</Item>
                <Item Key="Description"></Item>
                <Item Key="HomePage"></Item>
            </Hash>
        </Setting>
    </ConfigItem>
</otobo_config>

‍

Verfügbare Skins

Es gibt bereits von anderen Firmen erstellte Skins.

Dark Skin

Link zum Skin: Github Dark Skin

‍

Modern Skin von Efflux

Github Link zum Skin: Efflux Modern Skin

Offizielle OTOBO Skin Dokumentation

‍

‍

OTOBO Statistiken Einführung

Im OTOBO Ticketsystem lassen sich Auswertungen erstellen. Über den Menüpunkt Berichte, lassen sich so Zusammenfassungen der Ticketsystem Daten erstellen. Diese können Informationen über unterschiedliche Aspekte beinhalten zum Beispiel Anzahl Tickets in einer Queue.

Um OTOBO Statistiken erstelle zu können, benötigt man die stats Berechtigungen, diese kann man in der Agenten Kachel des Admin Bereichs verändern.

Dort kann man neue Statistiken erzeugen. Zum Beispiel wie viele Tickets wurden in Queue A in der letzten Woche erstellt.

‍

Neue Auswertung erstellen

Man kann sich unterscheiden zwischen einer Dynamischen Matrix einer Dynamischen Liste oder einer Statischen Statistik.

‍

Statistik - Dynamische Matrix

‍

Titel und Beschreibung sollten der Statistik einen einfach zu verstehenden Namen geben. Titel und Beschreibung manipulieren die Statistik aber nicht. Diese sind nur dazu da um den Nutzern der Statistik zu helfen, die Statistik wieder zu finden.

1. Objekttyp
2. Berechtigungen gibt an, welche Agenten auf die Statistik Zugreifen kann, also in dem Fall alle die Mitglied der Gruppe stats sind

Ergebnisformate sind alle Formate in welchen die Statistik dem Nutzer zur Verfügung gestellt worden wird. Zeitzone ist einfach die Zeitzone, Statistiken der Berichte nehmen als Zeit diese angegebene Zeitzone. Summenzeile und Spaltenzeile fügen der Tabelle noch zusammenfassende Daten hinzu.

‍

Nachdem man diese Informationen gespeichert hat. Kann man im nächsten Schritt angeben, welche Attribute in der Statistik angezeigt werden sollen. X und Y Achsen, sind Daten welche erscheinen. Über den Filter kann man Tickets nach bestimmten Kriterien selektieren. Direkt nach dem auswählen von Daten, kann man die Vorschau betrachten.

In der Abbildung habe ich für die X-Achse Status und als Filter Ticket-Erstellzeit in den letzten 10 Tagen. Nun könnte man auch noch ein Y-Achse hinzufügen. Wenn man auf Speichern klickt, sollte danach die neu erstellte Statistik in der Statistik-Liste auftauchen.

‍

Man sieht in den Spalten die Optionen eine Statistik herunterzuladen zu löschen oder auszuführen.

Beim Ausführen kann man das gewünschte Format angeben, welches man haben will.

Statistik im Dashboard Anzeigen

Man kann sich die Statistiken auch im Dashboard als Widget anzeigen lassen. Dazu muss man die Einstellungen der Statistik öffnen, also einfach die Statistik anklicken.

Dann die Einstellung "Als Dashboard-Widget anzeigen:" auf Ja setzen

Daraufhin erscheint die Statistik als Widget im Dashboard Bereich.

Jetzt mit der Demo das OTOBO Ticketsystem testen

‍

OTOBO Bericht erstellen

Über das Statistik Navigationsmenü kann man einen neuen Bericht erstellen. Der neue Bericht hat einen Namen und eine Beschreibung. Dieser Bericht wird in regelmäßigen Zeit Abständen per Email versendet. Dem Bericht werden Statistiken angehängt.

• Zeitpunkte für die automatische Erzeugung (cron) - In cron Angaben gibt man an, wann der Bericht erstellt wird :

min / hour / day of month / month / day of week

• Sprache für automatische Erzeugung
• Email Betreff - Der Betreff der Email welche regelmäßig versendet wird
• E-Mail-Inhalt - Der Inhalt der Email
• E-Mail-Empfänger - Die Empfänger des Berichts durch Komma getrennt

Danach kann man verschiedene STatistiken zum Bericht hinzufügen.

Wie kann man Prozesse mit dem OTOBO Prozessmanagement abbilden ? Über die Kachel Prozessmanagement im Admin Bereich kannst du neue Prozesse erzeugen. Prozesse bestehen aus Aktivitäten und Übergängen:

Überblick

Aktivitäten

Aktivitäten sind Ereignisse welche eintreffen. Diese bestehen wiederum aus Aktivitäts Dialogen. Die Aktivitäten sind miteinander per Übergänge verbunden. Eine Aktivität kann viele Übergänge haben. Aus dieser Struktur ergibt sich ein Flussdiagramm.

Übergänge

Die Übergänge haben Bedingungen, der Prozess ist immer an einer bestimmten Aktivität. Wenn die jetzige Aktivität keine ausgehenden Übergänge hat dann ist der Prozess beendet. Wenn die Bedingung eines Übergangs, welcher beim jetzigen Prozess ausgehend ist, dann wird die Aktivität gewechselt. Wenn ein Übergang genutzt wird, dann werden die Übergangs Aktionen ausgeführt.

Neuen Prozess Erstellen

Über die Kachel "Prozessmanagement" kann man einen neuen Prozess erstellen.

Danach fügt man dem Prozess Aktivitäten hinzu. Dieser Aktivität können Aktivitätsdialoge hinzugefügt werden. Bei diesen Aktivitätsdialogen gibt der Agent verschiedene Informationen in Felder ein. Diese werden dem Prozess Ticket hinzugefügt.

Neue Aktivität erstellen

Jetzt können neue Aktivitäten erstellt werden, ebenso neue Aktivitätsdialoge.

Einer Aktivität können Aktivitätsdialoge hinzugefügt werden. Außerdem hat die Aktivität einen Namen.

Neue Aktivitätsdialoge

Ebenso kann man neue Aktivitätsdialoge erstellen.

Aktivitätsdialog Felder

• Name des Aktivitätsdialogs - der Name ist nur zur Beschreibung und hat keine weitere Funktion
• Verfügbar In - Gibt an ob es im Kunden, Agenten oder in Beiden gezeigt werden soll
• Beschreibung kurz - Ebenfalls nur zur Dokumentation
• Beschreibung lang - längere Beschreibung ebenfalls keine Funktion
• Berechtigungen
• Erforderliche Sperre
• Hinweistext beim Absenden
• Hinweistext für die Schaltfläche Absenden
• Felder - Liste aller Felder welche im Dialog vom Nutzer ausgefüllt werden sollen

Nach der Aktivität wird der Übergang, mit einer wahren Bedingung ausgeführt. Dabei werden die Übergangsaktionen ausgeführt. Mit den Übergangsaktionen können beliebige Attribute des Prozess Tickets geändert werden.

Wenn die Übergangsaktionen ausgeführt werden, dann ist die nächste Aktivität aktiviert. Welche wiederum Aktivitätsdialoge haben.

Prozess Tickets erstellen

Nachdem ein Prozess erstellt wurde, können über die Navigations Leiste "Tickets" -> "Neues Prozess Ticket erstellen". Dann kann einer der Prozesse ausgewählt werden. Danach füllt der Agent die Eingabe Felder aus. Nun ist ein neues Prozess- Ticket erstellt.

‍

Oft antwortet man auf Tickets mit den selben Nachrichten oder man gibt häufig den selben Text beim Erstellen ein. Wäre es nicht schön, wenn man vorgefertigte Antworten hätte? Dies ist in OTOBO leicht möglich, dazu gibt es die Vorlagen. Mit diesen kann man vorab Antworten erstellen, welche oft geschrieben werden. Somit werden häufige OTOBO Artikel gespeichert. Damit man nicht so viel Schreibarbeit hat.

Im Ticketsystem OTOBO gibt es Vorlagen für Antworten. Man kann die Vorlagen Queues zu weisen. Damit der Nutzer nicht die Nachrichten tippen muss auch, insbesondere Nachrichten, welche oft der selben Struktur entsprechen. Dafür gibt es die OTOBO Vorlagen. Der Vorlage kann man Attachments hinzufügen, zum Beispiel Bilder und PDFs. In dem Vorlagen Text können Placeholder verwenden.

‍

Neue Vorlage Erstellen

• Admin Bereich öffnen
• Vorlagen auswählen

Danach Vorlage hinzufügen

Typ Auswählen

Der Typ gibt an, bei welcher Aktion die Vorlage genutzt werden kann. Zum Beispiel kann beim Typ "Erstellen", die Vorlage beim Hinzufügen eines neuen Tickets genutzt werden.

Vorlagen Name

Der Name sollte beschreiben, welchen Inhalt die Vorlage hat.

Vorlagen Inhalt

Im Feld Vorlage, kann nun ein freier Text ein getragen werden. Dazu können alle möglichen Formatierungsoptionen genutzt werden. In diesem Text kann man auch die OTOBO Placeholder nutzen diese sehen folgend aus:

Diese Placeholder können dann eingefügt werden und nehmen den entsprechenden dynamischen Wert an.

Anhänge

Der schnellen Antwort Möglichkeit kann man auch noch Dateien durch Anhänge hinzufügen. Dazu ist es nötig in der anderen Kachel Anhänge, neue Anhänge hinzuzufügen.

Neuen Anhang erstellen

Wie man sieht gibt man beim neuen Anhang nur den Namen und die Datei an.

Anhang-Vorlage zu ordnen

Die Anhänge zu Vorlagen ist eine "Many to Many" Beziehung. Um einer Vorlage einen Anhang hinzuzufügen muss man lediglich im Dropdown den entsprechenden Anhang auswählen

Was ist Oauth 2?

Mit Oauth 2 kann man sich sicher authentifizieren. Dies kann auch für das Senden und Abrufen von Emails verwendet werden. Bei Oauth2 wird dem Client vom Server ein Token zugesendet, mit welchem dieser dann auf die Emails zugreifen kann. Ein weit verbreiteter Anbieter ist Microsoft Azure Active Directory.

Wie kann man Benachrichtigungen im OTOBO Ticketsystem einstellen ?

Dies ist eine kurze Beschreibung, wie Sie OTOBO so einrichten, dass es OAuth2 für die Authentifizierung am Mail-Server zu verwenden.Dies wird in drei Schritten durchgeführt:

- In der SysConfig wird zunächst ein Provider (z.B. Microsoft Azure) und

- zweitens ein Profil, das diesen Provider verwendet, konfiguriert werden,

- und schließlich in der Postmaster-E-Mail-Adressverwaltung im Admin-Bereich,

IMAPOAuth2 oder POP3OAuth2 ausgewählt und eingerichtet werden.

‍

Unser OTOBO Support

Otobo Oauth 2 Paket

Um in OTOBO über Oauth2IMAP oder Oauth2POP3 Emails zu empfangen muss man sich das Paket “ Mailaccount-OAuth2” installieren. Neue Pakete kannst du über die Paketmanagement Kachel installieren. Über den Admin Bereich auf die Paketmanagement Kachel dort dann auf den installieren Button in der Spalte des Otobo Oauth2 Mailempfang drücken.

Erfahre mehr über die Plugin Installation

Nach erfolgreicher Installation:

Otobo Oauth2 Systemkonfigurationen

Nach der erfolgreichen Installation müssen Sie folgende Einstellungen ändern:

OAuth2 ::MailAccount::Providers

OAuth2 ::MailAccount::Profiles

Beim Provider kann man zum Beispiel Microsoft Azure nehmen.

Wie funktionieren die OTOBO Systemkonfigurationen?

Bei den Profiles kann man nun verschiedene Nutzer anlegen. Die Profile welche Sie für die Autorisierung bei Ihrem Active Directory nutzen.

Nun muss man einen PostMaster Mail Account erstellen, dies tut man in der Kachel PostMaster Mail Accounts. Dort muss man nun entsprechend entweder IMAP Oauth2 oder POP 3 Oauth 2 auswählen.

Dann je nachdem ob du POP3 oder IMAP verwendest, das richtige Profil auswählen. Es ist wichtig zu wissen, dass IMAP die Mails nachdem lesen, aus dem Postfach löscht. Daher empfiehlt es sich automatisch Kopien anzulegen oder die Mails an ein anderes Postfach weiterzuleiten.

Azure Active Directory

Um eine neue OAuth2-Anwendung zum Azure Active Directory hinzuzufügen, müssen Sie die folgenden Schritte ausführen:

1. Melden Sie sich beim Azure-Portal an und wählen Sie im linken Menü "Azure Active Directory" aus.
2. Klicken Sie im Menü "Azure Active Directory" auf "Anwendungen registrieren".
3. Klicken Sie auf "Neue Anwendung registrieren".
4. Geben Sie einen Namen für die Anwendung ein und wählen Sie "Web-App / API" als Anwendungstyp aus.
5. Geben Sie im Abschnitt "Unterstützte Kontodienste" eine Sign-On-URL und eine Logout-URL ein. Dies sind die URLs, die für das Anmelden und Abmelden von Benutzern verwendet werden.
6. Klicken Sie auf "Registrieren", um die Anwendung zu erstellen.
7. Klicken Sie im Abschnitt "Einstellungen" auf "Berechtigungen zuweisen".
8. Wählen Sie im Abschnitt "Berechtigungen zuweisen" die Option "Azure Active Directory" aus und klicken Sie auf "Hinzufügen".
9. Wählen Sie im Abschnitt "API-Berechtigungen" die Berechtigungen IMAP und POP3 aus.
10. Klicken Sie auf "Fertig stellen", um die Berechtigungen zuzuweisen.
11. Klicken Sie im Abschnitt "Einstellungen" auf "Zertifikate & Geheimnisse".
12. Klicken Sie auf "Neues Clientgeheimnis hinzufügen" und geben Sie eine Beschreibung und eine Gültigkeitsdauer ein.
13. Klicken Sie auf "Hinzufügen", um das Clientgeheimnis zu erstellen.

Das Clientgeheimnic und die Tenant Id/Instanzid müssen in den OTOBO Systemkonfigurationen hinzugefügt werden

Fehler Behebung

Nachdem du das Mail Protokoll eingestellt hast, kannst du nun testen ob es richtig funktioniert. Dafür musst du in der Kommunikationsprotokoll Kachel auf den Knopf "Fetch Mails" bzw. "Mails anrufen" drücken. Nun sollten alle Tickets aus dem Mailpostfach in Tickets umgewandelt werden. Bei IMAP werden diese auch aus dem Postfach gelöscht.

In dem Fall das es nicht funktioniert hat, würde ich dir empfehlen in die Konsole deines Servers zu springen und den FetchMail Befehl auszuführen. Wenn du eine Docker Umgebung hast, muss der Befehl im Container ausgeführt werden. Das ist über:

docker exec otobo_web_1 -it bash

Nun bist du in der Konsole des Docker Web Containers. Dort kannnst du über cd in den richtigen Ordner springen. Nachdem du den FetchMail Befehl ausgeführt hast, solltest entweder alles einwandfrei funktionieren. Andernfalls erscheint eine Fehlermeldung, welche dich offentlich an die Lösung leitet.

SysConfigSuchen Sie in der SysConfig nach OAuth2::MailAccount::Providers###, um die Provider zu konfigurieren. Beispielhafte Konfigurationen werden für Microsoft Azure und Google Workspace bereitgestellt. In OAuth2::MailAccount::Profiles### werden die Informationen für einzelne Profile eingestellt. Deren Namen sind frei wählbar, müssen aber eindeutig sein, der Providername muss gesetzt werden, und eine Client-ID und ein Client-Secret müssen ausgefüllt werden. In den allgemeinen Einstellungen OAuth2::Settings kann die Nonce im Status angepasst werden, die für die Kommunikation mit dem Server verwendet wird. Normalerweise sollte hier kein Handlungsbedarf bestehen.4.2 PostMaster Mailkonten. Wenn ein Mailkonto hinzugefügt oder bearbeitet wird, kann IMAPOAuth2 oder POP3OAuth2 ausgewählt werden und das entsprechende Profil muss ausgewählt werden.

Hinweis: Wenn das Feld "Profil" trotz Auswahl eines der OAuth2-Typen nicht sofort nach der Installation angezeigt wird, kann es notwendig sein, den Browser-Cache zu leeren.

‍

Funktionalität

Fetch Mail - Intervall

Wenn alles richtig eingestellt ist, sollten nun automatisch eingehende Emails in Ticktes umgewandelt werden. Standardmäßig werden die Mails alle 10 Minuten gelesen. Dies kann man in den Systemkonfigurationen ändern. In der Konfiguration *FetchMail. 

Das Intervall ändern dies ist in der Cron-Job Notation:

minute hour weekday month year.

10 Minuten Intervall:

min - h - wd - mo - y

/10    *       *    *      *

Also jedes Jahr jeden Monat jeden Tag jede Stunde, alle 10 Minuten. Wenn man die /10 durch einen * austauscht werden jede Minute die Mails abgerufen.

jede Minute * * * * *

Vorallem wenn eingehende Mails große Anhänge haben ist aber davon abzuraten.

Ticket Umwandlung

Die eingehenden Mails aus deinem Postfach werden in Tickets umgewandelt, oder zu bestehenden Tickets ergänzt. Dabei können Sie einstellen in welcher Form die Tickets umgewandelt werdenDabei kannst du die Queue und den Status  festlegen.

Um zu Vermeiden Änderungen am laufendem System durchzuführen, ist es sinnvoll ein weiteres System zu erstellen. Auf dem sogenannten Staging System, läuft dann eine weitere OTOBO Instanz. Es ist sinvoll einen Testserver zu erstellen. Wie kann man ein Staging Systemerstellen ? Das Entwickeln auf dem live system ist sehr gefährlich, weil dies dazu führen kann, dass das System abstürzt. Erst wenn man einige Änderungen durchgefürt hat und diese funktionieren, am Besten testet man diese noch gründlich, kann man den Stand des Staging Systems auf das live System übertragen.

Zusätzlich kann man auch noch eine weitere OTOBO Instanz erstellen, welche man zum Testen unterschiedlicher Funktionen nutzen kann.

OTOBO Staging System Erstellen

Um eine Test-Instanz mit dem Ticketsystem zu haben, muss man sich zuerst eine neuen Server hosten. Dabei sollte der Server möglichst Ähnliche Eigenschaften wie das Produktiv System haben. Also möglich gleich viel CPU, Speicherplatz und RAM. Damit es auch ein realistischer Test ist.

Alternativ können Sie je nachdem was für einen Hosting Anbieter haben, den Server per Kopf Druck klonen.

Achtung! Falls Sie EMails aus einem Postfach abholen müssen Sie beim Erstellen des Servers aufpassen, dass der Staging Server nicht die Mails abholt. Sonst versuchen beide Server die Emails abzuholen. Dies wird dazu führen, dass die Emails im schnelleren Server landen. Im worst-case landen manche Emails im Produktiv System und andere auf dem staging Server. Generell empfiehlt sich es daher bei IMAP das Postfach so zu konfigurieren, dass man ein weiteres Postfach hat in dem Kopien der Emails gespeichert werden.

Um den Fehler zu vermeiden können Sie vor dem Übertragen der Daten alle OTOBO Container löschen, danach alle Container aus den otobo_daemon Cntainer starten und daraufhin in den Systemkonfigurationen deen FetchMail CronJob dektivieren, danach otobo daemon starten. Dazu im folgenden mehr ...

‍

Danach muss auf dem neuen Staging Server OTOBO Installiert werden, am Besten die Docker Variante. Diese sollte die selbe OTOBO Version nutzen wie das live System. Die Installations-Schritte werden ganz normal durchgeführt werden. Gerne können Sie unser OTOBO Installationsskript ausprobieren.

OTOBO Testsystem

Es ist empfehlenswert ein Testsystem zu erstellen.

Schritt für Schritt

1. Was benötigen wir für die Installtion?

Für die OTOBO Installation benötigen wir einen Server. Haben Wir Bereits im vorherigem Schritt gehostet. Das heißt wir können jetzt mit der OTOBO Installation starten.

2. Installation von Docker, Docker Compose und Git

root> apt-get install git docker docker-compose
root> systemctl enable docker

Man braucht die Pakete um die OTOBO Docker Installation durchführen zu können.

3. Klonen des Github Repositories

Mit rel-10_1 wird die OTOBO Version 10.1 installiert.

docker_admin> cd /opt

docker_admin> git clone https://github.com/RotherOSS/otobo-docker.git --branch rel-10_1 --single-branch

docker_admin> ls otobo-docker    # README.md sollte existieren

‍

4. Erzeugen der Konfigurations .env Datei

Es bietet sich an beim Erstellen eines Staging Servers die .env Datei System vom produktiv System zu kopieren. In ubuntu kann man die Datei mit dem "scp" Befehl kopieren. In der Konfigurationsdatei .env werden die Einstellungen gespeichert. Je nachdem, ob eine SSL Verschlüsselung benötigt wird oder nicht, muss zwischen der Datei .docker_compose_env_http und .docker_compose_env_https entschieden werden. Eine SSL Verschlüsselung führt dazu ,dass sie das https Protokoll verwenden können. Im Gegensatz zum HTTP Protokoll wird bei HTTPS die gesamte Kommunikation verschlüsselt, sodass keine Nachrichten von dritten mitgelesen können. Das ist vor allem bei sensiblen Daten wichtig, wie Passwörter, Zahlungsinformationen, persönliche Daten.

docker_admin> cd /opt/otobo-docker

docker_admin> cp -p .docker_compose_env_https .env # für HTTP .docker_compose_env_http

Optional - SSL

Danach müssen Sie ein SSL Zertifikat angeben, welches signiert werden muss um gültig zu sein. Dabei gibt es unterschiedliche Anbieter bei welchen man sein Zertifikat verschlüsseln lassen kann. Zum Beispiel bei Lets Encrypt https://letsencrypt.org/.

Danach müssen Sie Die Datei mit Ihrem signierten Zertifikat auf den Server hochladen, dazu bspw. putty oder WinScp verwende(oder irgendein anderes Programm mit welchem Sie Zugriff auf die Dateien Ihres Servers haben). Nun müssen Sie in der .env Datei den Pfad zu Ihrem Zertifikat angeben.

5. Datenbank Passwort festlegen

Falls die .env Datei vom Produktiv System kopiert wurde muss das root Passwort nicht mehr geändert werden, es ist das selbe.

Ansonsten ändere das Datenbank root Passwort in der .env Datei.

OTOBO_DB_ROOT_PASSWORD=<Dein_Passwort>

Das Passwort kann frei gewählt werden. Um die .env Datei zu bearbeiten kannst du folgenden Befehl verwenden:

nano .env

Mit nano kannst du ganz simpel Dateien bearbeiten, du kannst aber natürlich ein beliebiges Tool nutzen um das Datenbank Passwort zu ändern. Das festgelegte Passwort, kann im nachhinein noch verändert werden, sollte aber logischerweise ein gutes Passwort sein. Mit diesem Datenbank Zugang kann man alle Daten des Ticketsystems löschen! Gerne können Sie sich das Passwort aufschreiben, Sie können es aber auch immer wieder anschauen in dem Sie die .env Datei öffnen.

6. HTTPS Verschlüsselung einstellen

‍

Falls du nur HTTP verwenden willst kannst du diesen Schritt überspringen!

‍

nginx erfordert für die SSL-Verschlüsselung ein Zertifikat sowie einen privaten Schlüssel.

SSL Zertifikat

Für Testzwecke und beim Entwickeln kann ein selbst signiertes Zertifikat verwendet werden. Grundsätzlich sind jedoch offizielle Zertifikate erforderlich. Mehr dazu, wie Sie ein selbst signiertes Zertifikat erstellen, erfahren Sie z. B. unter https://www.digitalocean.com/community/tutorials/how-to-create-a-self-signed-ssl-certificate-for-nginx-in-ubuntu-18-04.

nginx CA-Chain

Um in nginx eine CA-Chain zusammen mit einem Zertifikat anzugeben, muss das CA-Chain-File mit dem eigentlichen Zertifikat in eine Datei kopiert werden. Das Zertifikat und der private Schlüssel werden in einem Volume hinterlegt, um später von nginx verwendet werden zu können. Legen Sie zunächst das Volume an und kopieren Sie anschließend Zertifikat und Schlüssel hinein:

‍

docker_admin> docker volume create otobo_nginx_ssl

docker_admin> otobo_nginx_ssl_mp=$(docker volume inspect --format '{{ .Mountpoint }}' otobo_nginx_ssl)

docker_admin> echo $otobo_nginx_ssl_mp  # just a sanity check

docker_admin> cp /PathToYourSSLCert/ssl-cert.crt /PathToYourSSLCert/ssl-key.key $otobo_nginx_ssl_mp

Die Namen der kopierten Dateien müssen in die eben angelegte .env-Datei eingegeben werden. Beispiel:

OTOBO_NGINX_SSL_CERTIFICATE=/etc/nginx/ssl/ssl-cert.crt und OTOBO_NGINX_SSL_CERTIFICATE_KEY=/etc/nginx/ssl/ssl-key.key

Bitte passen Sie nur die Dateinamen an. Der Pfad /etc/nginx/ssl/ ist im Docker Image festgeschrieben.

‍

7. Starten der Docker Container

Jetzt starten wir die Docker Container mit docker-compose. An der Stelle aufpassen, wegen der Email abholung. Nachdem Sie den Befehl ausführen wird der Staging Server die Emails aus em Postfach holen.

docker_admin> docker-compose up --detach

Danch können Sie mit dem Befehl:

docker ps

alle laufenden Docker Container anschauen, es sollten Ihnen die 5(bzw. 6 bei SSL Verschlüsselung) Container angezeigt werden. Diese sind:

• otobo_web_1
• otobo_daemon_1
• otobo_db_1
• otobo_redis_1
• otobo_elastic_1
• otobo_nginx_1(optional)

Um einzelne Container zu starten, können Sie den Befehl:

docker start <container_name>

Genauso um einzelne container zu stoppen:

docker stop <container_name>

Wenn Sie alle Container stoppen möchten können Sie aus dem Ordner /opt/otobo-docker^{(ist der Standard Installations Ordner, kann je nach Konfiguration auch ein anderer sein)} den Befehl

docker-compose down

Um das System neu zu starten und damit auch alle docker container neu zu starten, ist der Befehl

reboot

sinnvoll.

8. Installation von OTOBO

Führe den OTOBO Installer aus, indem du http://{yourIPorFQDN}/otobo/installer.pl aufrufst.

Folge den Schritten im Installer. Dort kannst du einige wichtige Einstellungen setzen, wie die Email Konfiguration und Ähnliches. All diese Konfigurationen kannst du auch überspringen und dann noch danach ändern.

Wenn nachdem Datenbank Passwort gefragt wird, gebe das in der .env Datei angegebene root Passwort an. Es ist das selbe Passwort wie im Produktiv-System. Jetzt ist die OTOBO Docker Installation abgeschlossen.

‍

‍

OTOBO Docker Installation

OTOBO Docker Installationsskript

OTOBO Daten übertragen

Wenn Sie nun OTOBO erfolgreich installiert haben, müssen Sie jetzt noch den aktuellen Stand des live Systems übertragen. Dafür ist der einfachste Trick alle Daten der Docker Volumes zu übertragen. Mit folgendem Befehlen ist das möglich. Um mit dem scp Befehl Daten von einem anderen System zu kopieren, wird ein Zugang benötigt. Also zum Beispiel über ssh. Falls man noch kein Key-Pair hat muss man auf dem neuem System einen SSH Key generieren. Auf dem alten System muss der public key des neuen Systems in die Datei .ssh/authorized_keys hinzugefügt werden.

Auf dem neuem System:

ssh-keygen

‍

Welche wichtigen docker Befehle gibt es ?

Führe folgendes auf dem Neuem Server aus:

Aufpassen falls die Email Abholung eingerichtet ist, nicht den Docker Container des Daemons starten. Nachdem alle Container außer dem Daemon gestartet sind, ist die Web-Oberfläsche trotzdem erreichbar.

Folgende Systemkonfigurationen Deaktivieren:

Daemon::SchedulerCronTaskManager::Task###FetchMail

Daemon::SchedulerCronTaskManager::Task###FetchMailSSL

Daemon::SchedulerCronTaskManager::Task###MailAccountFetch

falls auch keine Mals gesendet werden sollen:

Daemon::SchedulerCronTaskManager::Task###MailQueueSend

‍

docker stop otobo_web_1

docker stop otobo_db_1

docker stop otobo_redis_1

docker stop otobo_elastic_1

docker stop otobo_daemon_1

systemctl stop docker

scp -r root@old-server.de:/var/lib/docker/volumes /var/lib/docker 

systemctl start docker

docker start otobo_web_1

docker start otobo_db_1

docker start otobo_redis_1

docker start otobo_elastic_1

docker start otobo_daemon_1

Über scp kann man alle volumes aus dem live Server auf den Staging Server übertragen. Dies sollte bereits ausreichen um den kompletten Stand zu übertragen. Man kann auch per Cronjob einstellen, dass dieses Skript in regelmäßigen Abständen ausgeführt wird. Somit man immer eine aktuelle Version zum Testen hat.

Nachdem die Volumes übertragen sind, kann es helfen das System neu zu starten, mit dem Befehl reboot .

reboot

Cache löschen

Damit die neusten Änderungen in Kraft treten kann es sinnvoll sein den Cache zu löschen. Dafür muss man einen Befehl im Terminal des Servers eingeben.

docker exec otobo_web_1 ./bin/otobo.Console.pl Maint::Cache::Delete

‍

Cronjob erstellen

Wenn man den Server täglich auf den aktuellen Stand bringen will, dann kann man dafür Cronjobs verwenden. Um einen neuen Cronjob zu erstellen muss man den Befehl:

> crontab -e

In diese Datei kann man eine neue Zeile einfügen. Die Syntax funktioniert folgendermaßen:

min hour day month weekday BEFEHL

Wenn man einen * angibt wird es jedes mal ausgeführt. Beispielsweise würde * * * * * jede Minute ausgeführt werden, * /2 * * * alle 2 Stunden, 20 10 /3 * * alle 3 Tage um 10:20.

Test Tickets entfernen

Mit Generic Agent

Nachdem man einige Dinge getestet hat, dann häufen sich möglicherweise Tickets an. Über den Generic Agent kann man diese alle auf einmal entfernen. Im Admin Bereich -> Generic Agent : kann man einen neuen Auftrag erstellen. Dabei muss man Selektions kriterien angeben, zum Beispiel alle neuen Tickets, oder alle die "Test" im Betreff stehen haben.

Der Generic Agent kann über das Admin Portal ausgewählt werden.

Danach auf "Auftrag hinzufügen" klicken:

Nun muss man einen Namen für den Auftrag einfügen, zum Beispiel "Löschen aller Tickets". Jetzt müssen wir bei Tickets selektieren eine Bedingung angeben, Ticket erstellt innerhalb des letzten Jahres

Bei Tickets-Befehle ausführen Ticket-Löschen auf Ja stellen. Danach Speichern, nun sollte in der Übersicht der neue Auftrag angezeigt werden. Um alle Tickets zu löschen auf "Diesen Auftrag ausführen" klicken.

Mit SQL Befehlen

Falls Sie aus der Kommandozeile alle Tickets löschen wollen, können Sie dies auch per SQL Anfragen erledigen.

sudo mysql --host="127.0.0.1" --user="otobo" --password="1234" -e "DELETE FROM article_search_index; DELETE FROM article_data_mime_attachment;DELETE FROM  article_data_mime_plain;DELETE FROM  article_data_mime_send_error;DELETE FROM  article_data_mime;DELETE FROM   article_data_otobo_chat;DELETE FROM  article_flag; DELETE FROM ticket_history; DELETE FROM time_accounting;DELETE FROM  article;DELETE FROM  ticket_flag;DELETE FROM  ticket;DELETE FROM ticket_state;DELETE FROM ticket_priority;DELETE FROM ticket_type;DELETE FROM ticket_lock_type;DELETE FROM ticket_state_type" otobo

‍

Systemkonfigurationen übertragen

Ein sehr einfacher Weg viele Einstellungen von einem OTOBO-System zu einem anderen zu übertragen ist das übertragen der Systemkonfigurationen.

Sehr viele Anpassungen des OTOBO Ticketsystems werden durch die Systemkonfiguration umgesetzt. Für die Systemkonfigurationen gibt es eine Import, Export Funktion. Somit ist es also sehr einfach Konfigurationen von der einen Instanz zur anderen zu übertragen.

Staging Änderungen übertragen

Wenn man nun einige Änderungen auf dem Staging System getätigt hat und man diese dann auf das live System übertragen will. Könnte man die docker volumes übertragen, damit würde man aber alle Ticket Daten auf dem Produktivsystem überschreiben. In dem Fall das man nur Systemkonfigurationen geändert hat, kann man ganz einfach die Import / Exportfunktion nutzen.

Datenbank Tabellen übertragen

Eine weitere Möglichkeit Daten von dem live System zum Staging System zu bringen, besteht darin die Daten über die Datenbank zu übertragen. Dies funktioniert beispielsweise mit den mysqldump Befehlen. Der mysqldump ist ein Backup der mysql Datenbank. Die Datei enthält alle Daten aus der Datenbank.

Beim Übertragen von Tabellen oder sogar von allen Datenbank Tabellen wird nicht alles übertragen. Sehr viele Einstellungen des Ticketsystems befindet sich in Dateien.

Per Mysql Dump alle Tickets herunterladen

Um ein Backup zu erstellen oder die OTOBO Daten auf den Staging Server zu übertragen bietet es sich an mysqldump Dateien zu erstellen.

mysqldump --host=softoft.de  --user=otobo --password=1234 --column-statistics=0 --lock-tables=0  otobo article_search_index article_data_mime_attachment article_data_mime_plain article_data_mime_send_error article_data_mime article_data_otobo_chat article_flag ticket_history time_accounting article  ticket_flag ticket_state  ticket  > /home/tickets.sql

Die Tickets werden in der Datei /home/tickets.sql gespeichert. Host user und Password aus dem Befehl müssen natürlich noch angepasst werden.

Tickets aus Datei laden

Falls man die Daten aus der MySQLDump Datei importieren will, kann man dies mit folgendem Befehl.

mysql --host="mysql_server" --user="user_name" --database="database_name" --password="user_password" < "path/to/sql/file.sql"

Daraufhin ist das Backup wieder hergestellt.

Ablauf

Auf System 1 mit Mysql Dump alle Tickets herunterladen in tickets.sql.Die Datei tickets.sql auf das System 2 hochladen. Auf System 2 Tickets aus tickets.sql laden

‍

OTOBO Support - Dienstleistung

Wir helfen Ihnen gerne bei Fragen und Problemen. Als Berater bieten wir Dienstleistungen für OTOBO an.

Unser OTOBO Support Angebot