Artikel-Timestamp = eMail-Send-Timestamp ?!

cibu · Post by **cibu** » 16 Mar 2010, 11:22

Hi Gemeinde

Wir "bouncen" viele eMails in das OTRS, um die Vorgänge dort zu protokollieren.
Manches mal entscheiden wir uns erst im Nachhinein zu diesem Schritt.

Leider erhalten alle Artikel immer den Import-Timestamp und nicht den Timestamp der importierten eMail, so daß die eMails in falscher Chronologie mit falschen Timestamps aufgelistet werden.

Hat jemand eine Idee, wo/wie OTRS zu patchen ist, daß das PostMaster Modul die neuen Artikel mit dem Send-Timestamp der importierten eMail versieht?

ciao cibu

JosVanHaag · Post by **JosVanHaag** » 25 Mar 2010, 14:54

Ich würde mal versuchen, die Mails in der .procmailrc durch geeignete Regeln umzuformatieren, bevor sie an Postmaster.pl durchgepiped werden. Mit ein wenig RegEx-Voodoo sollte sich das Problem da eigentlich lösen lassen.

cibu · Post by **cibu** » 25 Mar 2010, 16:13

Hi JosVanHaag

Entweder habe ich Dich nicht richtig verstanden, oder Du nicht mein Problem:
In den aktuellen eMails stehen alle relevanten Daten drinn:
Date: Thu, 25 Mar 2010 13:54:34 +0100
Da brauche ich mit procmailrc nix umzuformatieren.

Mein Problem ist, daß OTRS diese Informationen nicht auswertet und als Artikel-Timestamp verwendet, sondern einfach jeden Artikel mit Systemtime in die DB schreibt.

Also fehlt für den Patch:

Aktuellen Mail-Timestamp aus der Mail parsen
Anstelle von Systemtime bei der weiteren eMail-Verarbeitung verwenden

Nur mit den Details klemmt es etwas bei mir.

Gruß

cibu · Post by **cibu** » 12 Apr 2010, 11:44

Hi All

Problem gelöst!

Ergebnis: eMails werden mit dem eMail-TimeStamp in's OTRS importiert und nicht - wie default - mit CurrentTimeStamp.

Ich hab mir ein wenig den Source-Code zu Gemüte geführt und eine Lösung gefunden:

Eine Konfigurationsanpassung: Im SysConfig für 'PostmasterX-Header' das Feld 'Date' hinzufügen
Eine Source-Code-Patchung durchführen (4 Zeilen) (Version 2.4.5 & 2.4.7 getestet)

Kernel/System/Ticket/Article.pm

Code: Select all

90c90,94
<     my $IncomingTime = $Self->{TimeObject}->SystemTime();
---
>     # import eMail with Mail Timestamp instead of CurrentTime
>     my $IncomingTime = $Self->{TimeObject}->TimeStamp2SystemTime( String => $Param{OrigHeader}->{Date}) || $Self->{TimeObject}->SystemTime();
>     my $IncomingTimeStamp = $Self->{TimeObject}->SystemTime2TimeStamp(SystemTime => $IncomingTime);
>
211a216,217
>     # import eMail with Mail Timestamp instead of CurrentTime
218c224
<             . '(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, current_timestamp, ?, current_timestamp, ?)',
---
>             . '(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, current_timestamp, ?)',
225c231
<             \$IncomingTime, \$Param{UserID}, \$Param{UserID},
---
>             \$IncomingTime, \$IncomingTimeStamp, \$Param{UserID}, \$Param{UserID},

innoinst · Post by **innoinst** » 16 Apr 2010, 16:21

cibu wrote:Hi All

Problem gelöst!

Ergebnis: eMails werden mit dem eMail-TimeStamp in's OTRS importiert und nicht - wie default - mit CurrentTimeStamp.
[...]

Hallo Cibu,
ein guter Ansatz, der auch soweit funktioniert. Allerdings habe ich das Phänomen, dass die Zeit wohl (noch) nicht richtig ausgelesen wird bzw. die Zeitzone nicht korrekt verarbeitet wird.
Ich habe gerade auf unserem Testserver nach der beschriebenen Änderung verfahren und eine Testmail an diesen geschickt, die auch abgeholt und eingearbeitet wurde.

Die Mail wurde abgeholt und eingearbeitet mit "Erstellt: 16.04.2010 16:10:02 (+2)"
Der Artikel ist aber nun aus der Zukunft, er zeigt: 16.04.2010 17:59 (+2) - die Mail ist/war von 15Uhr59 (hier der Header: Date: Fri, 16 Apr 2010 15:59:57 +0200).

Hast Du noch eine Idee?

Grüße,
Wolfgang

cibu · Post by **cibu** » 19 Apr 2010, 00:14

Hallo Innoinst

Der Mail-TimeStamp wird mit einer in OTRS vorhandenen Funktion in UTC konvertiert und dann damit abgespeichert.
Ich vermute, daß nicht alle beteiligten System mit der korrekten Zeitzone eingestellt sind.
Was für Zeiten steht den in der Artikle-Tabelle in CreateDate?

Ich hab alles unter Windows auf der lokalen Maschine testetet. Nun läuft es auf unserem Linux-System produktiv - und erfolgreich

ciao

innoinst · Post by **innoinst** » 19 Apr 2010, 13:30

cibu wrote:Hallo Innoinst

Der Mail-TimeStamp wird mit einer in OTRS vorhandenen Funktion in UTC konvertiert und dann damit abgespeichert.
Ich vermute, daß nicht alle beteiligten System mit der korrekten Zeitzone eingestellt sind.

Das Ticketsystem läuft auf UTC-Zeit. OTRS hat davon auch Kenntnis durch die Einstellung

Code: Select all

$ENV{TZ}="UTC";

in der Config.pm

Was für Zeiten steht den in der Artikle-Tabelle in CreateDate?

Du meinst die Spalte "create_time" in der Tabelle "article"? Da steht "2010-04-16 15:59:57.0" (was eben falsch ist, da der Date Header der Mail "Fri, 16 Apr 2010 15:59:57 +0200" ausweist.)

Mir scheint, dass die Umwandlung in UTC an dieser Stelle nicht funktioniert.

Grüße,
Wolfgang

cibu · Post by **cibu** » 19 Apr 2010, 18:06

Hi Innoinst

Du hast Recht!
Ich hab mir noch mal die Sourcen angesehen und festgestellt, daß die Zeitzonen-Korrektur nach UTC auskommentiert, während die Korrektur nach Localtime aktiv ist.
Bitte spiel mal hier rum und vermelde das Ergebnis:
Kernel\System\Time.pm:275-284

ciao

innoinst · Post by **innoinst** » 20 Apr 2010, 14:10

Hallo Cibu,
ich schau es mir an. Vielleicht kann sich ja auch jemand von OTRS dazu äußern, warum die UTC-Korrektur auskommentiert ist.

Grüße,
Wolfgang

innoinst · Post by **innoinst** » 29 Apr 2010, 16:46

innoinst wrote:ich schau es mir an.

Nehme ich von Dir, Cibu, gefundenen Auskommentierung aus Time.pm raus, wird der Artikel! tatsächlich mit der Mail-Erstellungszeit angelegt.
Das Ticket selber erhält als Zeitstempel die Systemzeit, was positiv ist, da das ganze SLA-Management auf der Ticket- und nicht der Artikelzeit aufsetzt.

Bleibt nun immer noch die Frage an die OTRS-Verantwortlichen offen, warum diese Zeilen auskommentiert sind?
Nochmal zur Erinnerung: OTRS weiß, dass das System auf UTC-Zeit läuft

Grüße,
Wolfgang

cibu · Post by **cibu** » 29 Apr 2010, 21:45

Vielen Dank für Deine Verifikation. Ich werde die Änderung bei mir auch noch testen, auch wenn es bei mir aktuell auch ohne wie erwartet funktioniert - warum auch immer.

Ich hab mir auch schon mal die Möglichkeit angesehen, daß das Ticket mit dem eMail-Timestamp anstatt Systemtime angelegt wird - betrifft ja nur Neu-Tickets. Leider geht das nicht so einfach, weil in den entsprechenden Routinen der eMail-Timestamp nicht so einfach abzugreifen ist und es mir zu aufwendig war, den eMail-Timestamp durch den Funktionsstack durchzuschleusen. Darum habe auch ich mich dazu entschieden, die Ticket-Time als "Alter im System" zu verwenden, ungeachtet dessen, welchen Timestamp die enthaltenen eMails haben.

ciao

innoinst · Post by **innoinst** » 03 May 2010, 13:42

cibu wrote:Ich hab mir auch schon mal die Möglichkeit angesehen, daß das Ticket mit dem eMail-Timestamp anstatt Systemtime angelegt wird - betrifft ja nur Neu-Tickets. [...]

Das würde ich nicht machen, da am Ticket das gesamte SLA-Management (incl. Lösungszeiten, Kalendern mit Servicezeiten, Feiertagen etc.) hängt.
Und dabei ist (zumindest bei uns) entscheidend, wann das Ticket erzeugt wurde und nicht wann die e-mail (vom Kunden) erzeugt oder versandt wurde.

Grüße,
Wolfgang

Sascha79 · Post by **Sascha79** » 22 Mar 2015, 13:39

Ist schon etwas älter, der Thread - daher die Frage:
Gibts inzwischen eine Möglichkeit, die article.create_time (also der Zeitstempel eines Artikels, der im AgentFrontend angezeigt wird) aus der Box heraus auf das Datum der zugrundeliegenden E-Mail zu setzen?
Habe leider nichts entsprechendes gefunden (ein Workaround auf DB-Ebene gibts wohl noch).
Im Moment ist meine Article.pm gepatched - ist natürlich nicht der ideale Zustand.

Danke für Antworten.

Grüße,
Sascha

Znuny Open Source Ticketsystem