da bei uns die Bitte aufkam, die Ticketnr. von der Länge her in ein Format zu bringen, welches einfacher verständlich ist, haben wir im Zuge dessen auch gleich ähnliche Änderungen für Workorder und Change durchgeführt. Da es bei der Workorder# / Change# aber nicht wie bei der Ticket# die gleichen funktional einstellbaren Möglichkeiten im Frontend gibt, wurde der Quellcode minimal editiert. Da ich nirgendwo im Netz eine Erklärung oder ein ähnliches Problem fand, hier eine kleine Anleitung:
Um die Ticketnr. zu bearbeiten einfach in der Sysconfig folgende Konfiguration editieren:
>> "Ticket -> Core::Ticket"
Ticket::Hook (nach Bedarf - wir wählten nun ""Ticketnr." (Achtung, an möglicherweise notwendige Übersetzung für Fremdsprachen denken))
Ticket::HookDivider (nach Bedarf - wir wählten ":")
Ticket::SubjectFormat (nach Bedarf - wir wählten nun rechts statt links, da sich die Kunden dies wünschten)
Ticket::NumberGenerator (Umstellung auf "Datum", da der Hash-Wert viel zu lange war und die Ticketnr. unnötig aufblähte und für die Agenten
unverständlich war).
Achtung: das Datum enthält auch die SystemID. Diese findet sich unter Framework -> Core >> SystemID und sollte nur mit Bedacht
geändert werden. Findet eine Änderung statt, was im Grunde noch nicht problematisch ist, sollte man sich jedoch darüber im Klaren sein, dass dies dazu führt, dass OTRS bei der Ticketzuordnung von neuen Nachrichten alte Tickets von vor der Umstellung nicht mehr findet (da andere ID). Dies sollte man OTRS auch bei der Suche mitteilen, indem man unter >> "Ticket -> Core::Ticket" die Option Ticket::NumberGenerator::CheckSystemID den Check deaktiviert. Theoretisch kann man ihn nach einer Weile wieder aktivieren, sofern man sich mehr oder weniger sicher sein kann, dass auf alte Tickets keine Response mehr kommt. Habe ich aber noch nicht ausprobiert, dürfte aber so stimmen (ansonsten korrigiert mich bitte
)Wem jetzt beim Datum der 5stellige Counter noch zu viel ist (pro Tag 99999 Tickets ist schon ein Wort), der kann die Option: Ticket::NumberGenerator::MinCounterSize noch herunterstellen. Wir haben ihn auf 3 Stellen gesetzt. Und dass diese Option auch für den NumberGenerator "Datum" funktioniert, muss noch folgende Option auf "ja" gestellt werden: Ticket::NumberGenerator::Date::UseFormattedCounter.
Bei Changes und Workorders ist die Konfiguration:
Change Management -> Core::ITSMChange hilfreich.
Leider gibt es hier nicht die gleiche Funktionalität wie auf Ticket-Ebene. Daher war die besagte kleine Änderung im Quellcode verantwortlich:
ITSMChange::Hook (nach Bedarf - wir wählten nun ""Change" (Achtung, an möglicherweise notwendige Übersetzung für Fremdsprachen denken))
ITSMChange::NumberGenerator (Umstellung auf "Datum" synchron zu Ticketnr.)
ITSMChange::NumberGenerator::AutoIncrement::MinCounterSize (nach Bedarf, wir wählten "2")
Achtung: die vom Ticket her bekannte Funktion "Ticket::NumberGenerator::Date::UseFormattedCounter" existiert hier nicht für den Change, was bedeutet, dass der unter "ITSMChange::NumberGenerator::AutoIncrement::MinCounterSize" eingestellte Wert für die Länge des Counters bei dem "Datum" Nummerngenerator nicht gezogen wird.
Daher war folgende Quellcodeanpassung notwendig:
>> /otrs/Kernel/System/ITSMChange/Number/Date.pm
Zeile suchen mit Quellcode:
Code: Select all
$Count = sprintf "%05d", $Count;Code: Select all
#$Count = sprintf "%05d", $Count;
my $MinSize = $Self->{ConfigObject}->Get('ITSMChange::NumberGenerator::AutoIncrement::MinCounterSize') || 5;
# pad change number with leading '0' to length $MinSize (config option)
$Count = sprintf "%.*u", $MinSize, $Count;
Perfekt wäre es natürlich jetzt noch, die Beschreibung der XML für die Admin Übersicht anzupassen, doch dies habe ich derzeit noch nicht erledigt. Mal schauen, wann ich dazu komme. Sollte jemand anders schneller sein, bitte gerne ergänzen.