Hallo allerseits, ich finde das unheimlich schwer zu debuggen. Momentan habe ich zwei Fälle, die mir Rätsel bereiten. Ein eigenes Modul belegt mir TicketFreeText5 nach meinen Wünschen, und nimmt als Trigger "TicketQueueUpdate|TicketOwnerUpdate" - das ist on Config.pm definiert: $Self->{'Ticket::EventModulePost'}->{'139-ModulXY'} = { 'Event' => '(TicketQueueUpdate|TicketOwnerUpdate)', 'Module' => 'Kernel::System::Ticket::Event::ModulXY' }; Es tut seinen Job und schreibt Infos in die Tickethistory, DOCH DANN KOMMT IRGENDSOEIN HINTERHÄLTIGER PROZESS DAHER, DER MIR DAS WIEDER RÜCKGÄNGIG MACHT! ;-) In der History sieht man, dass in der ersten Zeile der Wert für FreeText5 gesetzt wird, und in der zweiten gleich wieder auf den alten Wert gesetzt wird: | Misc - ModulXY.pm: FreeText5 auf "NEUER WERT" gesetzt - USER - 02.07.2012 09:55:35 | TicketFreeTextUpdate - Aktualisiert: FreeKey5=Info-Queue;FreeText5="ALTER WERT" - USER - 02.07.2012 09:55:35 Meines Erachtens muss es also ein Event geben, das auf "FreeTextUpdate" triggert und mir FreeText5 anpackt. Aber warum sollte es das geben? Von mir kann es nicht sein! Na ja, das dahinterliegende Problem ist, "wie finde ich den Schuldigen"? In Config.pm sind ein paar Eventmodule definiert, die aber nicht auf FreeTextUpdate triggern... Eventmodule und Trigger: Meiner Erfahrung nach einmal korrekt einstellen und dann die Finger davon lassen :-( Danke Micha
Hallo Michael, als erstes würde ich etwas Debugging-Code in die Ticket.pm reinpacken. In der Subroutine "TicketFreeTextSet" einfach nach dem "my ($Self, %Param)...": for ( 0 .. 1 ) { my @caller = caller($_); $Self->{LogObject}->Log( Priority => error => Message => join '::', @caller[0..2] ); } reinpacken. Dann kannst Du im Systemprotokoll verfolgen, welche Codestellen die TicketFreeTextSet aufrufen. Hier werden zwei Ebenen ausgewertet... Eventuell ist auch ein Fehler in Deinem Event-Modul. Kannst Du da etwas mehr Code zeigen? - Renée On 02.07.2012 10:14, Michael Scheer wrote:
Hallo allerseits,
ich finde das unheimlich schwer zu debuggen. Momentan habe ich zwei Fälle, die mir Rätsel bereiten.
Ein eigenes Modul belegt mir TicketFreeText5 nach meinen Wünschen, und nimmt als Trigger "TicketQueueUpdate|TicketOwnerUpdate" - das ist on Config.pm definiert:
$Self->{'Ticket::EventModulePost'}->{'139-ModulXY'} = { 'Event' => '(TicketQueueUpdate|TicketOwnerUpdate)', 'Module' => 'Kernel::System::Ticket::Event::ModulXY' };
Es tut seinen Job und schreibt Infos in die Tickethistory, DOCH DANN KOMMT IRGENDSOEIN HINTERHÄLTIGER PROZESS DAHER, DER MIR DAS WIEDER RÜCKGÄNGIG MACHT! ;-)
In der History sieht man, dass in der ersten Zeile der Wert für FreeText5 gesetzt wird, und in der zweiten gleich wieder auf den alten Wert gesetzt wird: | Misc - ModulXY.pm: FreeText5 auf "NEUER WERT" gesetzt - USER - 02.07.2012 09:55:35 | TicketFreeTextUpdate - Aktualisiert: FreeKey5=Info-Queue;FreeText5="ALTER WERT" - USER - 02.07.2012 09:55:35
Meines Erachtens muss es also ein Event geben, das auf "FreeTextUpdate" triggert und mir FreeText5 anpackt. Aber warum sollte es das geben? Von mir kann es nicht sein!
Na ja, das dahinterliegende Problem ist, "wie finde ich den Schuldigen"? In Config.pm sind ein paar Eventmodule definiert, die aber nicht auf FreeTextUpdate triggern...
Eventmodule und Trigger: Meiner Erfahrung nach einmal korrekt einstellen und dann die Finger davon lassen :-(
Danke Micha --------------------------------------------------------------------- OTRS mailing list: otrs-de - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs-de To unsubscribe: http://lists.otrs.org/mailman/listinfo/otrs-de
Renée Bäcker:
als erstes würde ich etwas Debugging-Code in die Ticket.pm reinpacken. In der Subroutine "TicketFreeTextSet" einfach nach dem "my ($Self, %Param)...":
for ( 0 .. 1 ) { my @caller = caller($_); $Self->{LogObject}->Log( Priority => error => Message => join '::', @caller[0..2] ); }
Danke für den caller, ich probiere das mal aus! Denn dass in Ticket.pm in der sub "TicketFreeTextSet" der Wert gesetzt wird, hatte ich in einem anderen Fall schon gesehen, kam aber da eben nicht weiter, weil ich nicht wusste, wie man die aufrufende Instanz findet.
Eventuell ist auch ein Fehler in Deinem Event-Modul. Kannst Du da etwas mehr Code zeigen?
Ja. Es macht aber nicht viel. - Trigger: TicketCreate und QueueUpdate. Diese funktionieren auch, der Vorgang wird korrekt in die Ticket-History geloggt. - Inhaltlich: Unter bestimmten Voraussetzungen setzt es TicketFreeText5 gleich dem Namen der aktuellen Queue. [...] # get ticket data my %Ticket = $Self->{TicketObject}->TicketGet( TicketID => $Param{Data}->{TicketID} ); if (($Ticket{TicketFreeText5} !~ /.* (Applikationen|Infrastruktur|Globale Services)::/) && ($Ticket{TicketFreeText5} ne $Ticket{Queue}) || (( $Ticket{Type} eq 'default') && ($Ticket{TicketFreeText5} ne $Ticket{Queue}))) { $Self->{TicketObject}->TicketFreeTextSet( TicketID => $Param{TicketID}, UserID => $Param{UserID}, Key => 'Info-Queue', Value => $Ticket{Queue}, Counter => 5, ); $Self->{TicketObject}->HistoryAdd( TicketID => $Param{Data}->{TicketID}, CreateUserID => $Param{UserID}, HistoryType => 'Misc', Name => 'SetInfoQueue.pm: Info-Queue (SO/RU-Info) auf ' . $Ticket{Queue} . ' gesetzt.', ); } return 1; } 1;
Renée Bäcker:
Dann kannst Du im Systemprotokoll verfolgen, welche Codestellen die TicketFreeTextSet aufrufen. Hier werden zwei Ebenen ausgewertet...
Nach dem TicketFreeTextSet im meinem Modul passiert das: 1. EventHandler.pm 241 (es bemerkt das Event TicketFreeTextSet5) 2. AgentTicketMove.pm 777 (da wird die bösartige Änderung aufgerufen): $Self->{TicketObject}->TicketFreeTextSet( TicketID => $Self->{TicketID}, Key => $GetParam{$Key}, Value => $GetParam{$Text}, Counter => $Count, UserID => $Self->{UserID}, ); Aha! Der Hase liegt weiter oben in AgentTicketMove (bei mir Zeile 129) im Pfeffer, wo die Belegungen der Variablen stattfinden. Warum? Wenn ich den Code zwischen den ### auskommentiere, verhält sich der Vorgang wie gewünscht, d.h. letzten Endes $GetParam{$Text} (mit Text=TicketFreeText5) bleibt auf dem im Vorgängermodul gesetzten Wert. Ist mir noch unklar, warum... Leider kann ich heute daran nicht mehr weitermachen, aber bin ja schon sehr weit dank Deiner Hilfe und vor allem kann man den Debug-Code immer wieder gut gebrauchen.... OTRS 3.08 hier übrigens. Danke nochmal. [AgentTicketMove.pm ~Z. 129] # get ticket free text params for my $Count ( 1 .. 16 ) { my $Key = 'TicketFreeKey' . $Count; my $Text = 'TicketFreeText' . $Count; $GetParam{$Key} = $Self->{ParamObject}->GetParam( Param => $Key ); $GetParam{$Text} = $Self->{ParamObject}->GetParam( Param => $Text ); if ( !defined $GetParam{$Key} && $Ticket{$Key} ) { $GetParam{$Key} = $Ticket{$Key}; } ##### UND ZWAR ÄNDERT ES MIR HIER $GetParam{$Text} auf den alten Wert: ################### if ( !defined $GetParam{$Text} && $Ticket{$Text} ) { $GetParam{$Text} = $Ticket{$Text}; } ############################################## } MfG Michael
Michael Scheer:
[AgentTicketMove.pm ~Z. 129] # get ticket free text params for my $Count ( 1 .. 16 ) { my $Key = 'TicketFreeKey' . $Count; my $Text = 'TicketFreeText' . $Count; $GetParam{$Key} = $Self->{ParamObject}->GetParam( Param => $Key ); $GetParam{$Text} = $Self->{ParamObject}->GetParam( Param => $Text );
Also was ich schonmal sagen kann ist, dass alle $GetParam{TicketFreeText/Key[1-16]} in der For-Schleife leer bleiben, dies ist also irgendwie faul. Mir ist auch nicht klar, warum nach einem Queuemove überhaupt alle Freetext-Felder wieder neu belegt werden müssen. Ich überlege, das Schreiben der Freetextfelder in AgentTicketMove auszukommentieren, aber kann natürlich die Tragweite nicht überblicken... erste Tests zeigen mir keine Probleme...
participants (2)
-
Michael Scheer -
Renée Bäcker