OTRS erlaubt es Ihnen, die Ticket-Status zu verändern oder neue Status hinzuzufügen. Hierbei gibt es zwei wichtige Optionen: den Namen des Status und Typ des Status.
Die standardmäßig voreingestellten Status lauten: 'neu', 'offen', 'erfolgreich geschlossen', 'erfolglos geschlossen', 'merged', 'entfernt', 'warten auf erfolgreich schließen', 'warten auf erfolglos schließen' und 'warten zur Erinnerung'.
Tickets sind normalerweise nur in diesem Status, wenn sie von eingehenden E-Mails neu erzeugt werden.
Nachdem die Wartezeit abgelaufen ist, erhält der Ticketbesitzer eine E-Mail zu dem Ticket. Wenn es nicht gesperrt ist, wird die Erinnerung an alle Agenten der Queue verschickt. Erinnerungs-Benachrichtigungen werden nur innerhalb der Arbeitszeiten versendet, und werden alle 24 Stunden wiederholt, bis der Status des Tickets vom Agenten verändert wird. Die Zeit, die dieses Ticket in diesem Status verbringt, wird dennoch bei der Berechnung der Eskalationszeiten einbezogen.
Wenn die Wartezeit abgelaufen ist, wird das Ticket auf "erfolglos geschlossen" gesetzt. Die Zeit, die dieses Ticket in diesem Status verbringt, wird dennoch bei der Berechnung der Eskalationszeiten einbezogen.
Wenn die Wartezeit abgelaufen ist, wird das Ticket auf "erfolgreich geschlossen" gesetzt. Die Zeit, die dieses Ticket in diesem Status verbringt, wird dennoch bei der Berechnung der Eskalationszeiten einbezogen.
Endstatus für Tickets, die erfolgreich gelöst werden konnten. Je nach Konfiguration kann es unmöglich sein, geschlossene Tickets wieder zu eröffnen.
Jeder Status besteht aus einem Namen ("state-name") und einem Typen ("state-type"). Klicken Sie auf den Link Status im Administrationsbereich und benutzen Sie den Knopf "Status hinzufügen", um einen neuen Status anzulegen. Der Name ist frei wählbar und kann über das Admin-Interface von OTRS angepasst werden, die Statustypen müssen direkt in der Datenbank geändert werden. Letzteres wird jedoch nicht empfohlen und kann zu unerwarteten Ergebnissen führen. Z. B. hängen die Berechnung der Eskalationszeiten und auch die Funktion zum automatischen Entsperren von Tickets von bestimmten Statustypen ab.
Im Admin-Interface können Sie innerhalb der Einstellungen für "Status" neue
Status für die vorhandenen Statustypen hinzufügen oder ändern. Beachten Sie,
dass Sie bei Änderungen am Status "neu - new" auch die entsprechenden
Änderungen in der KonfigurationsdateiKernel/Config.pm
bzw. mit Hilfe des grafischen Konfigurations-Front-End vornehmen
müssen. Folgende Änderungen müssen für einen geänderten "neu"-Status
vorgenommen werden:
[...]
# PostmasterDefaultState
# (The default state of new tickets.) [default: new]
$Self->{PostmasterDefaultState} = 'new';
# CustomerDefaultState
# (default state of new customer tickets)
$Self->{CustomerDefaultState} = 'new';
[...]
Skript: Anpassung der Einstellungen von Kernel/Config.pm.
Möchten Sie einen neuen Statustyp hinzufügen, müssen Sie zuerst die ticket_status-type-Tabelle in der OTRS Datenbank mit Hilfe eines entsprechenden Datenbankclient anpassen.
linux:~# mysql -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 23 to server version: 5.0.16-Debian_1-log
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql> use otrs;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> insert into ticket_state_type (name,comments) values ('own','Own
state type');
Query OK, 1 row affected (0.00 sec)
mysql> quit
Bye
linux:~#
Skript: Anpassung der Statustypen.
Nun können Sie den neuen Statustyp verwenden. Nachdem ein Status mit diesem Statustyp verknüpft wurde, muss auch die OTRS-Konfiguration angepasst werden, damit der neue Status korrekt verwendet werden kann. Passen Sie die Folgenden Optionen in der SysConfig an:
Ticket -> Frontend::Agent::Ticket::ViewPhoneNew > AgentTicketPhone###StateDefault - um den vorgegebenen nächsten Status für neue Telefon-Tickets zu definieren.
Ticket -> Frontend::Agent::Ticket::ViewPhoneNew > AgentTicketPhone###StateType - um die verfügbaren nächsten Status für neue Telefon-Tickets zu definieren.
Ticket -> Frontend::Agent::Ticket::ViewEmailNew > AgentTicketEmail###StateDefault - um den standardmäßigen 'Nächsten Status des Tickets' für E-Mailtickets zu definieren.
Ticket -> Frontend::Agent::Ticket::ViewEmailNew > AgentTicketEmail###StateType - um die verfügbaren 'Nächsten Status' für neue E-Mailtickets zu definieren.
Ticket -> Frontend::Agent::Ticket::ViewPhoneOutbound > AgentTicketPhoneOutbound###State - um den standardmäßigen 'Nächsten Status des Tickets' für neue Artikel in Telefontickets zu definieren.
Ticket -> Frontend::Agent::Ticket::ViewPhoneOutbound > AgentTicketPhoneOutbound###StateType - um die verfügbaren 'Nächsten Status' für neue Artikel in Telefontickets zu definieren.
Ticket -> Frontend::Agent::Ticket::ViewMove > AgentTicketMove###State - um den Standard-Status für Tickets zu definieren, wenn ein Ticket verschoben wird.
Ticket -> Frontend::Agent::Ticket::ViewMove > AgentTicketMove###StateType - um die verfügbaren nächsten Status eines Tickets zu definieren, wenn ein Ticket verschoben wird.
Ticket -> Frontend::Agent::Ticket::ViewBounce > StateDefault - um den Standard-Status für Tickets zu definieren, wenn ein Ticket weitergeleitet wird.
Ticket -> Frontend::Agent::Ticket::ViewBounce > StateType - um die verfügbaren nächsten Status eines Tickets zu definieren, wenn ein Ticket weitergeleitet wird.
Ticket -> Frontend::Agent::Ticket::ViewBulk > StateDefault - um den Standard-Status für Tickets zu definieren, wenn eine Sammelaktion durchgeführt wird.
Ticket -> Frontend::Agent::Ticket::ViewBulk > StateType - um die verfügbaren nächsten Status eines Tickets zu definieren, wenn eine Sammelaktion durchgeführt wird.
Ticket -> Frontend::Agent::Ticket::ViewClose > StateDefault - um den Standard-Status für Tickets zu definieren, wenn ein Ticket geschlossen werden soll.
Ticket -> Frontend::Agent::Ticket::ViewClose > StateType - um die verfügbaren nächsten Status eines Tickets zu definieren, wenn ein Ticket geschlosen werden soll.
Ticket -> Frontend::Agent::Ticket::ViewCompose > StateDefault - um den Standard-Status für Tickets zu definieren, wenn auf ein Ticket geantwortet (AgentTicketCompose) werden soll.
Ticket -> Frontend::Agent::Ticket::ViewCompose > StateType - um die verfügbaren nächsten Status eines Tickets zu definieren, wenn auf ein Ticket gewantwortet (AgentTicketCompose) werden soll.
Ticket -> Frontend::Agent::Ticket::ViewForward > StateDefault - um den Standard-Status für Tickets zu definieren, wenn ein Ticket weitergeleitet werden soll.
Ticket -> Frontend::Agent::Ticket::ViewForward > StateType - um die verfügbaren nächsten Status eines Tickets zu definieren, wenn ein Ticket weitergeleitet werden soll.
Ticket -> Frontend::Agent::Ticket::ViewForward > StateDefault - um den Standard-Status für Tickets in der Oberfläche 'Freie Felder' zu definieren,
Ticket -> Frontend::Agent::Ticket::ViewForward > StateType - um die verfügbaren nächsten Status eines Tickets in der Oberfläche 'Freie Felder' zu definieren.
Ticket -> Core::PostMaster > PostmasterDefaultState - um den Status von Tickets zu definieren, die aus E-Mails erstellt wurden.
Ticket -> Core::PostMaster > PostmasterFollowUpState - um den Status von Tickets festzulegen, nachdem ein Follow-Up eingegangen ist.
Ticket -> Core::PostMaster > PostmasterFollowUpStateClosed - um den Status von bereits geschlossenen Tickets festzulegen, nachdem ein Follow-Up eingegangen ist.
Ticket -> Core::Ticket > ViewableStateType - um die Statustypen festzulegen, die in verschiedenen Bereichen des Systems angezeigt werden, z. B. in der Queue-Ansicht.
Ticket -> Core::Ticket > UnlockStateType - um die verfügbaren Statustypen für entsperrte Tickets zu definieren.
Ticket -> Core::Ticket > PendingReminderStateType - um den Statustyp für Erinnerungstickets festzulegen.
Ticket -> Core::Ticket > PendingAutoStateType - um den Statustyp für Tickets mit "Warten Auto" festzulegen.
Ticket -> Core::Ticket > StateAfterPending - um den Status zu definieren, auf welchen Tickets, deren "Warten Auto"-Timer des eingestellten Status abgelaufen ist, gesetzt werden.
OTRS enthält 5 vordefinierte Ticketprioritäten, die mit dem "Prioritäten"-Modul im Administrationsbereich verwaltet werden können. Wenn Sie eine angepasste Prioritätenliste erstellen, bedenken Sie bitte, dass diese in der Prioritätsauswahl-Liste alphabetisch sortiert dargestellt werden. In der Queue-Ansicht ordnet OTRS die Prioritäten nach internen Datenbank-IDs.
Anmerkung
In OTRS können Prioritäten deaktiviert, aber nicht gelöscht werden. Wenn Sie eine Priorität deaktivieren wollen, setzen Sie den Wert für "Gültig" auf "ungültig" oder "ungültig-temporär".
Wichtig
Wenn eine Priorität hinzugefügt oder geändert wurde, müssen Sie ggf. einige Werte in der SysConfig anpassen:
Ticket:Core::Postmaster::PostmasterDefaultPriority - definiert die Standard-Priorität für alle eingehenden E-Mails.
Ticket:Frontend::Agent:Ticket::ViewPhoneNew:Priority - definiert die Standard-Priorität in der Oberfläche 'Neues Telefonticket' für Agenten.
Ticket:Frontend::Agent:Ticket::ViewEmailNew:Priority - definiert die Standard-Priorität in der Oberfläche 'Neues E-Mailticket' für Agenten.
Ticket:Frontend::Customer:Ticket::ViewNew:PriorityDefault - definiert die Standard-Priorität in der Oberfläche 'Neues Ticket' im Kunden-Interface.
Seit OTRS 2.1 kann zusätzlich zum Besitzer ein Verantwortlicher für das Ticket festgelegt werden. Zudem können alle Aktivitäten rund um das Ticket auch von jemand anderem als dem Besitzer beobachtet werden. Diese beiden Funktionalitäten sind mit den TicketResponsible- und dem TicketWatcher-Funktionen implementiert, und erleichtern das Zuweisen von Aufgaben und die Arbeit in hierarchischen Teamstrukturen.
Die Funktion "Verantwortlicher" eines Tickets macht es möglich, das Ticket einem anderen als dem aktuellen Besitzer zur Bearbeitung zu übergeben. Ein Benutzer, der ein Ticket gesperrt hat, kann es einem anderen Agenten, der nicht der Ticketbesitzer ist, zur Beantwortung übergeben. Nach der Bearbeitung kann der erste Benutzer die Ticketverantwortung vom zweiten wieder entfernen.
Mit dem Konfigurationsparameter Ticket::Responsible kann die Funktion TicketResponsible aktiviert werden. Dadurch werden 3 neue Icons in ihrer Toolbar erscheinen.
Die Ticketverantwortung kann übergeben werden, indem das Ticket aufgerufen und die Funktion "Verantwortlicher" in der Aktionsleiste genutzt wird.
Abb.: Verantwortlichen eines Tickets ändern.
Nach dem Klick auf "Verantwortlicher" öffnet sich ein Popup-Fenster, in dem die Änderung durchgeführt werden kann. Damit kann auch dem neuen verantwortlichen Benutzer eine Nachricht geschickt werden.
Abb.: Popup-Dialog zum Ändern des Ticket-Verantwortlichen.
Die Liste aller Tickets, für die ein Benutzer verantwortlich ist, kann durch die Ansicht "Verantwortliche Tickets" eingesehen werden. Diese kann über 3 Icons in der Toolbar aufgerufen werden, sobald das TicketResponsible-Feature aktiviert wird.
Sollen innerhalb des Ticket-Systems lediglich bestimmte Tickets z. B. von einem Abteilungsleiter beobachtet und nicht selbst bearbeitet werden, so kann dies seit OTRS 2.1 mit Hilfe des TicketWatcher-Features realisiert werden.
Das TicketWatcher-Feature kann mit Hilfe des Konfigurations-Parameters Ticket::Watcher aktiviert werden. Weiterhin können über Ticket::WatcherGroup eine oder mehrere Benutzergruppen festgelegt werden, die die Erlaubnis haben sollen Tickets zu beobachten.
Um ein Ticket zu beobachten, muss der Inhalt des Tickets aufgerufen und im Menü für die verschiedenen Aktionen für das Ticket der "Beobachten"-Schalter betätigt werden.
Abb.: Ticket beobachten.
Die Beobachtung eines Tickets wird aufgehoben, indem in der Inhaltsanzeige eines Tickets im Menü für die möglichen Aktionen der "Nicht beobachten"-Schalter gedrückt wird.
Abb.: Ticket nicht mehr beobachten.
Die Liste aller zur Beobachtung ausgewählten Tickets wird über die Ansicht "Beobachtete Tickets" erreicht. Diese kann über 3 Icons in der Toolbar aufgerufen werden, sobald das TicketWatcher-Feature aktiviert wird.
Abb.: Ansicht "Beobachtete Tickets".