Hi, Vielleicht eher eine Frage für OTRS-dev, aber ich versuche es erst einmal hier: Ich bin gerade dabei, die Anpassungen, die ich an unserem OTRS-System vorgenommen habe, auf OTRS 2.3.1 zu übertragen. Aktuell verzweifle ich etwas an der Handhabung der Eskalationen: in 2.2 gab es eine Funktion namens TicketEscalationStartUpdate(), mit der man den Beginn der Eskalationszeit zurücksetzen konnte. Das habe ich dafür genutzt, um Eskalationen nach dem Verschieben eines Tickets neu zu starten. Wenn also ein Ticket 2 Wochen nach Erstellung in die Queue xy mit einer Aktualisierungszeit von 6 Stunden verschoben wurde, fingen diese 6 Stunden Eskalationszeit ab dem Zeitpunkt des Verschiebens an zu laufen. In OTRS 2.3.1 ist es defaultmässig so, dass die Eskalationszeiten nach einem Queuewechsel auf Grundlage der Erstellungszeit des Tickets berechnet werden. Leider existiert die Funktion TicketEscalationStartUpdate() in 2.3.1 nicht mehr. In der Ticket.pm ist sie zwar noch zu finden, aber auskommentiert. Hat jemand eine Ahnung, wie ich OTRS nun dazu bewegen kann, die Eskalationszeit zurückzusetzen? Die Möglichkeit muss es ja weiterhin geben - wenn ein Ticket geschlossen und wieder neu geöffnet wird, wird sie auch neu gesetzt. Ich werde allerdings aus dem Code nicht schlau und http://dev.otrs.org bringt mich auch nicht wirklich weiter. Gruß, Laura
Hi Laura, On Di, Aug 05 2008, Laura Ohrndorf wrote:
Ich bin gerade dabei, die Anpassungen, die ich an unserem OTRS-System vorgenommen habe, auf OTRS 2.3.1 zu übertragen.
Aktuell verzweifle ich etwas an der Handhabung der Eskalationen: in 2.2 gab es eine Funktion namens TicketEscalationStartUpdate(), mit der man den Beginn der Eskalationszeit zurücksetzen konnte. Das habe ich dafür genutzt, um Eskalationen nach dem Verschieben eines Tickets neu zu starten.
Die Funktion gibt es in 2.3 in der Tat nicht mehr. In der Datenbank wird nun nicht mehr das Startdatum für die Eskalation abgelegt, sondern das nächste Eskalationsdatum. Es bringt auch nichts diesen Wert direkt in der Datenbank zu verändern, weil er bei der nächsten Ticketaktion wieder neu berechnet und geschrieben wird. Die einzige Möglichkeit den Eskalationsmechanismus zu beeinflussen besteht nun im Ändern der Eskalationszeiten auf Queueebene oder durch Zuweisung eines anderen SLAs. Letzteres ist in Deinem Fall vielleicht die beste Lösung, daß ließe sich auch durch ein move Event triggern. Viele Grüße Henning -- Henning Oschwald ((otrs)) :: OTRS AG :: Norsk-Data-Straße 1 :: 61352 Bad Homburg Fon: +49 (0) 9421 56818 0 :: Fax: +49 (0) 9421 56818 18 http://www.otrs.com/ :: Communication with success! Geschäftssitz: Bad Homburg Amtsgericht Bad Homburg, HRB 10751 Steuernummer: 003 240 97505 Aufsichtsratsvorsitzender: Burchard Steinbild Vorstandsvorsitzender: André Mindermann
Hi, Danke erstmal für die Antwort. Ich habe noch eine kleine Frage - vielleicht kann mir ja jemand von der Liste weiterhelfen bzw. meine Theorie bestätigen.... Und zwar habe ich mich jetzt einmal etwas genauer mit den Eskalationen in 2.3.2 beschäftigt. Sehe ich das richtig, dass der einzige Trigger für den Neustart der Aktualisierungszeit (also quasi für den Neustart des Countdowns) eine Antwort (sei es nun als E-Mail oder als Anruf) an den Kunden ist? Eine Änderung des SLAs bewirkt ja lediglich eine Änderung des Eskalationszeit. Um es mal beispielhaft zu erklären: ich erstelle ein Ticket um 15 Uhr mit einem SLA, der eine Aktualisierungszeit von 10 Minuten hat, sie läuft also um 15:10 Uhr ab. Wenn ich nun den SLA auf einen Wert mit einer Aktualisierungszeit mit 30 Minuten ändere, würde das Ticket um 15:30 Uhr eskalieren - unabhängig davon, wann ich den SLA ändere. Ist das so korrekt? Für meine Zwecke wünschenswert wäre es, wenn ich, um mal wieder bei dem Beispiel zu bleiben, den SLA um 15:15 auf den 30-Minuten-Wert ändere und das Ticket dann um 15:45 Uhr eskalieren würde, da die Änderungs-Zeit als Startzeitpunkt für die Eskalation genutzt wird. Gibt es da irgendeine Möglichkeit? Gruß, Laura Am 15.08.2008 um 12:26 schrieb Henning Oschwald:
Hi Laura,
On Di, Aug 05 2008, Laura Ohrndorf wrote:
Ich bin gerade dabei, die Anpassungen, die ich an unserem OTRS-System vorgenommen habe, auf OTRS 2.3.1 zu übertragen.
Aktuell verzweifle ich etwas an der Handhabung der Eskalationen: in 2.2 gab es eine Funktion namens TicketEscalationStartUpdate(), mit der man den Beginn der Eskalationszeit zurücksetzen konnte. Das habe ich dafür genutzt, um Eskalationen nach dem Verschieben eines Tickets neu zu starten.
Die Funktion gibt es in 2.3 in der Tat nicht mehr. In der Datenbank wird nun nicht mehr das Startdatum für die Eskalation abgelegt, sondern das nächste Eskalationsdatum. Es bringt auch nichts diesen Wert direkt in der Datenbank zu verändern, weil er bei der nächsten Ticketaktion wieder neu berechnet und geschrieben wird. Die einzige Möglichkeit den Eskalationsmechanismus zu beeinflussen besteht nun im Ändern der Eskalationszeiten auf Queueebene oder durch Zuweisung eines anderen SLAs. Letzteres ist in Deinem Fall vielleicht die beste Lösung, daß ließe sich auch durch ein move Event triggern.
Viele Grüße
Henning
-- Henning Oschwald ((otrs)) :: OTRS AG :: Norsk-Data-Straße 1 :: 61352 Bad Homburg Fon: +49 (0) 9421 56818 0 :: Fax: +49 (0) 9421 56818 18 http://www.otrs.com/ :: Communication with success!
Geschäftssitz: Bad Homburg Amtsgericht Bad Homburg, HRB 10751 Steuernummer: 003 240 97505
Aufsichtsratsvorsitzender: Burchard Steinbild Vorstandsvorsitzender: André Mindermann _______________________________________________ OTRS-de Mailingliste: otrs-de - Webpage: http://otrs.org/ Archiv: http://lists.otrs.org/pipermail/otrs-de/ Listenabo verwalten: http://lists.otrs.org/cgi-bin/listinfo/otrs-de/ Support oder Consulting fuer Ihr OTRS System? => http://www.otrs.com/
participants (2)
-
Henning Oschwald -
Laura Ohrndorf