Status und Status-Typen

From OtterHub - OTRS Community Wiki
Jump to: navigation, search

Einer der oft genutzten Eigenschaften von OTRS ist es, Tickets abhänging von ihrem Status bestimmten Aktionen zuzuführen. OTRS hier sehr flexibel konfigurierbar. Der frischgebackene Admin sieht sich hier jedoch leider oft vor dem Problem, dass es eigentlich zwei Eigenschaften sind, die hier zum Tragen kommen, der Status und der Status-Typ.

Leider geht die Dokumentation der aktuellen Version 2.0.4 auf diese Unterscheidung in OTRS-Admin-Handbuch Kapitel 10) ein, dort ist die Rede von Status Name (state_name) und Status-Typ. Leider muss man sich bei der Konfiguration weitgehend selbst zusammen reimen, was man wo verwenden muss.

Ziel dieses Artikels ist es, den Unterschied zwischen Status und Typ anhand des Datenmodells sowie das Zusammenspiel beider an einem Beispiel zu erklären. Im folgenden habe ich deshalb immer ausdrücklich erwähnt, ob ich mich auf einen Status oder auf einen Typ beziehe. Dadurch wirkt der Text leider etwas holprig, aber ohne diese strenge Unterscheidung wäre er imho noch unverständlicher.

Im weiteren habe ich mich dazu entschlossen, von "Status" in der Mehrzahl als "Stati" zu reden. Das ist zwar nicht korrekt, aber in DV-Kreisen geläufig und trägt hoffentlich zu besseren Lesbarkeit bei.

Ein Blick auf das Datenmodell

right|Ausschnitt aus dem OTRS-Datenmodell

Um den Unterschied zu verdeutlichen, links ein Ausschnitt aus dem Datenmodell. Es gibt zwei relevante Tabellen:

ticket_state
In dieser Tabelle sind die Stati der Tickets wie "offen", "geschlossen", "wartet auf Erinnerung" etc. hinterlegt, wie man sie sich halt nach eigenen Vorstellungen über das Admin-Menü zurecht geschneidert hat.
ticket_state_type
Hier findet man die Status-Typen, oder kurz Typen.

Die Typen kann man übrigens über die Admin-Oberfläche nicht bearbeiten, sondern nur direkt in der Datenbank. Standardmäßig hinterlegt sind hier:

  • new
  • open
  • closed
  • pending reminder
  • pending auto
  • removed
  • merged

Um die Verwirrung vollständig zu machen, tragen einige der Stati bei einer Standardinstallation die gleiche Bezeichnung.

Zwischen den Tabellen ticket_state_type (Primärschlüssel ticket_state_type.id) und ticket_state ("Fremdschlüssel" ticket_state.type_id) besteht also eine 1:n-Beziehung. Oder anders ausgedrückt: Die Typen kann man sich als eine Art Gruppierung der Stati vorstellen. Alle Tickets eines Typen haben gewisse gemeinsame Eigenschaften. Wie OTRS mit diesen Tickets umgeht, bezieht sich, wie oben bereits erwähnt, an vielen Stellen auf den Typ und nicht auf den Status selbst.

Ein einfaches Beispiel

Über den Parameter Ticket::ViewableStateType in Core::Ticket gibt man an, welche Tickets alle in die Queues angezeigt werden. Die Voreinstellung ist:

center

Erweitert man dies nun um den Typ "closed", werden auch alle geschlossenen Tickets in der Queue angezeigt, unabhänig davon, ob deren Status nun "erfolgreich geschlossen" oder "erfolglos geschlossen" oder "geschlossen wegen fehlender Reaktion" ist. Wichtig ist, dass alle genannten Stati dem Typ "closed" angehören.

Ein praktisches Beispiel

Nach diesem zugegeben eher theoretischen Beispiel, eines aus der Praxis.

OTRS kann hat verschiedene Mechanismen, bei Tickets die aktiv werden können, die auf warten gesetzt sind. So könnenn z. B. automatisch Mails verschickt werden, die auf den Ablauf der Wartezeit hinweisen. Konfiguriert wird dies über den Parameter Ticket::PendingReminderStateType, standardmäßig ist hier nur der Typ "pending reminder" hinterlegt.

Komplizierter wird es, wenn Tickets nach Ablauf der Wartezeit einen anderen Status erhalten sollen, denn hier spielen tatsächlich Typ und Status eine Rolle. Zuerst muss man über den Parameter Ticket::PendingAutoStateType angeben, für welche Typen dies passieren soll. Dann muss man in Ticket::StateAfterPending festlegen, welche Stati sich ändern und wie der neue Status lauten soll.

Wir haben z. B. den Ticket-Status "HC in Berlin" mit Typ "pending auto" und den Status "Wartet auf Erinnerung" mit Typ "pending reminder" (da für diesen eine Erinnerungsmail verschickt wird). Beiden Stati sollen nach Ablauf der Wartezeit wieder auf den Status "open" gesetzt werden. In der SysConfig müssen dafür folgende Einstellung vorgenommen werden:

center

Also noch einmal zum Mitdenken:

  • In Ticket::PendingReminderStateType werden die Typen eingetragen, für die nach Ablauf der Wartezeit eine Erinnerungsmail verschickt werden soll.
  • In Ticket::PendingAutoStateType werden die Typen eingetragen, die nach Ablauf der Wartezeit ihren Status ändern dürfen
  • In Ticket::StateAfterPending werden die Stati eintragen, die nach Ablauf der Wartezeit geändert werden sollen, und zwar in Key der Status vor und in Inhalt der Status nach der Änderung.

Nimmt man jetzt in Ticket::PendingAutoStateType den Typ "pending reminder" raus, bleiben alle Ticktes mit Status "Wartet auf Erinnerung" unverändert, auch wenn diese in Ticket::StateAfterPending eingetragen sind.

Noch Fragen bitte?

Ja, nämlich wie erkennt man, ob in einer Konfiguration nun der Status oder Typ gefordert ist? Das ist zum Glück relativ leicht, da zumindest die Namensgebung der Parameter eingermaßen einheitlich ist. Aus Faustregel kann man sagen:

  • der Namensteil StateType bezieht sich immer auf Status-Typen
  • der Namensteil State alleine bezieht sich nur auf den Status.

Bleibt zu wünschen, dass die OTRS GmbH zum nächsten Release sich auch mal die Dokumentation vornimmt und die Unterschiede zwischen Status und Typ klarstellt. Aber wir wissen ja alle, dass Programmierer keinen Handbücher schreiben können :-)