[OTRS ITSM 3.08] Eskalationszeitpunkt initial im Jahr 1970

[shostakovich]

Hallo allerseits,

nach dem Einschalten der Eskalation (wir nutzen es Queue-basiert) wird als Eskalationszeitpunkt immer erstmal die Vergenagenheit ausgerechnet, und zwar etwa bei Beginn der Unix-Zeit. Es stellte sich heraus, dass escalation_time in der Tabelle "Ticket" erst dann korrekt berechnet wird, wenn eine manuelle Aktion passiert - in der Regel, wenn der Agent eine Notiz schreibt. Bei via Mailin eintrudelnden Tickets siehts aber erstmal schlecht aus.

Konkret. - Beispielqueue "Posteingang". Eingestellt ist Erste Reaktion:3600, Aktualisierungszeit:3600,Lösungszeit:24000

Code: Select all

SELECT escalation_time,escalation_update_time,escalation_response_time,escalation_solution_time FROM ticket where id=123456

Nach Eintrudeln des Tickets:
658800 658800 1338215699 1341333299
Nach Hinzufügen einer Notiz:
1338215699 1338216290 1338215699 1341333299

Das Problem liegt also darin, dass zunächst Unixzeitpunkt 0 + 658800 Sekunden als erster Eskalationszeitpunkt eingestellt wird. Damit wird die Eskalationsansicht wertlos...

Wer weiß mehr?

Danke
Micha

[shostakovich]

Problem ist folgendes - und gilt auch für 3.1.5:

[Kernel/System/Ticket.pm in OTRS 3.1.5]

Code: Select all

2535        return if !$Self->{DBObject}->Prepare(
2536            SQL => 'SELECT article_sender_type_id, article_type_id, create_time FROM '
2537                . 'article WHERE ticket_id = ? ORDER BY create_time ASC',
2538            Bind => [ \$Param{TicketID} ],
2539        );

Diese SQL-Abfrage gibt (aus der SQL-Box in der GUI) ein create_time wie folgt zurück: 2012-05-22 11:26:39
Allerdings hat das aus o.g. Code gewonnene $Row[2] folgenden Wert: 22.05.12
WARUM?

Später wird dann im Prinzip TimeStamp2SystemTime($Row[2]) gemacht, was dann 0 zurückgibt.

Die Lokalisierung des Tagesdatums könnte ich ja umfriemeln, allerdings fehlt hier ja die Uhrzeit völlig...