Aktualisierungs- und Lösungsz läuft bei geschl. Ticket weite

Schojo · Post by **Schojo** » 07 Aug 2007, 16:47

Wenn ich ein Ticket erfolgreich schliesse, laufen die Aktualisierungszeit und die Lösungszeit weiter runter, bis ins negative...warum tun sie das? Ich habe das Ticket doch bereits erfolgreich geschlossen, und zwar innerhalb der Geschäftszeit...

Was ist da bloss los?

jojo · Post by **jojo** » 07 Aug 2007, 19:25

- OTRS Version? (Upgegradet?)
- Beriebssystem
- Statustyp des ausgewählten Status?

Was sagt die Historie des Tickets?

jlamm · Post by **jlamm** » 08 Aug 2007, 13:55

Hallo jojo:

OTRS Version? (Upgegradet?)
2.2.1 Erstinstallation

- Beriebssystem
Ubuntu Server 6.10
- Statustyp des ausgewählten Status?
?? Ticket wurde erfolgreich geschlossen

Was sagt die Historie des Tickets?

NewTicket Neues Ticket [2007080710000076] erstellt (Q=Technik;P=3 normal;S=open). - jlamm (Jens Lamm) 07.08.2007 13:14:38
EmailAgent E-Mail an Kunden versandt. x jlamm (Jens Lamm) 07.08.2007 13:14:38
Misc Reset of escalation time. - jlamm (Jens Lamm) 07.08.2007 13:14:38
Misc Reset of unlock time. - jlamm (Jens Lamm) 07.08.2007 13:14:38
Lock Ticket gesperrt. - jlamm (Jens Lamm) 07.08.2007 13:14:38
AddNote Notiz hinzugefügt (Close) x jlamm (Jens Lamm) 07.08.2007 13:17:12
StateUpdate Alt: "open" Neu: "closed successful" - jlamm (Jens Lamm) 07.08.2007 13:17:12
Unlock Ticketsperre aufgehoben. - jlamm (Jens Lamm) 07.08.2007 13:17:12

Ist nur ein Beispiel.
Seitdem die benutzte Queue Eskalationszeiten besitzt, läuft die Zeit einfach weiter, oblwohl alle Tickets geschlossen wurden. Über die Suchfuntion sieht man alle alten Tickets, die ständig "altern", was bei Tickets ohne Eskaltionszeiten nicht der Fall ist.

Die Diskussion darüber, ob ein Ticket gesperrt ist oder nicht, ist für Eskalationszwecke uninteressant. Es sollte immer eskalieren. Gesperrt bedeutet: der MA macht was dran. Deshalb muss es trotzdem eskalieren können, wenn der MA eine Schnarchnase ist und über die Lösungszeit hinauskommt (als Beispiel).

Das einzige, was funktioniert WÄHREND der Bearbeitung ist, dass die Reaktionszeit bei der ersten Bearbeitung "eingefroren" wird und das die Aktualisierungszeit nach einer Aktion wieder auf den eingestellten Wert zurückgesetzt wird.

....

jojo · Post by **jojo** » 08 Aug 2007, 14:00

Ich würde erstmal zu einem Upgrade auf die Version 2.2.2 raten...

Bitte danach unbedingt dieses Script ausführen: http://cvs.otrs.org/viewvc.cgi/*checkou ... vision=1.2

Das Alter eines Tickets läuft jedenfalls immer weiter... Die Eskalationszeiten sollten das jedenfalls nicht machen...

jlamm · Post by **jlamm** » 08 Aug 2007, 14:30

gut, das macht morgen der Azubi, dann schaun wir mal

Danke

Jens

Schojo · Post by **Schojo** » 09 Aug 2007, 08:59

jawohl chef!

Schojo · Post by **Schojo** » 08 Oct 2007, 08:12

*bump*

Das Problem besteht erneut, bzw. fast

Nach einer Neuinstallation von OTRS 2.2.2 auf einem anderen System (ubuntu Server 6.06 LTS) laufen die Zeiten ebenfalls immer weiter.
Das Script ist in diesem Falle nutzlos, da es bei der 2.2.2 Installation sowieso mitgeliefert wird ( otrs/scripts/DBUpdate-to-2.2.2.sql )

Erfolgreich geschlossene Tickets haben keine SLA Zeiten mehr, soweit so gut. Wird ein Ticket allerdings auf "warten zur Erinnerung" gesetzt, läuft die Zeit weiter runter...was Sie natürlich nicht sollte. Beispiel: Kunde ABC benötigt Teil XYZ, welches aber erst nächste Woche Mittwoch geliefert wird. Man antwortet (=> reagiert) und setzt das Ticket auf "warten zur Erinnerung" weil man zur Zeit eh nichts tun kann. Somit sollte die Zeit doch stoppen, oder sehe ich da irgendwas falsch?

Schojo · Post by **Schojo** » 09 Oct 2007, 15:00

nach dem Update auf v2.2.3 funktioniert es nun wunderbar

Schojo · Post by **Schojo** » 15 Oct 2007, 13:09

nicht ganz...

Wenn man ein Telefonticket erstellt und dieses mit SLAs belegt, läuft die Reaktionszeit weiter...auch wenn man reagiert hat.

Weiss da jemand was? Ist das schon ein bekannter Bug vielleicht?