Keine Nachricht bei Ticket von Customer über Login

as-networking · Post by **as-networking** » 25 Oct 2007, 17:39

Hallo,

wir (Agents) bekommen keine Nachricht, wenn ein Kunde über sein Customer Login ein Ticket erstellt.
Werden neue Tickets per Mail "eingereicht" arbeitet die Benachrichtungsfunktion einwandfrei.
Gibt es dort igrend wo ein Unterschied, zumal die Tickets in beiden Fällen sauber in die entsprechende Queue laufen.

Queue Auswahl der bevorzugten Queues. Es werden E-Mail-Benachrichtigungen über diese ausgewählten Queues versendet.
ist beim Agent in seinen persönlichen Einstellungen aktiv.

Queue AutoAntworten ist entsprechend auch alles an:

default remove (after a ticket got removed) (auto remove)
* default close (after rejected a closed ticket) (auto reject)
* default follow up (after a ticket follow up) (auto follow up)
* default close/new ticket (after closed follow up with new ticket creation) (auto reply/new ticket)
* default reply (after new ticket) (auto reply)

Hat jemand eine Idee?

OTRS 2.1.7

Gruss André

schlafwandla · Post by **schlafwandla** » 26 Oct 2007, 08:24

hallo,

ich habe das selbe Problem mit otrs::itsm 1.0.3 allerdings habe ich die Auto Antworten nicht aktiviert, sollte doch aber trotzdem funktionieren da die Benachrichtigung ja über neu erstellte Tickets informiert oder? Zumindest ist das bei Tickets die per Mail reinkommen so.

Gruß schlafwandla

schlafwandla · Post by **schlafwandla** » 21 Nov 2007, 17:19

Moin,
so habs herausgefunden ist ein bekannter Bug.
hier der Link: http://bugs.otrs.org/show_bug.cgi?id=977

gruß schlafwandla

Andre Bauer · Post by **Andre Bauer** » 21 Nov 2007, 23:36

Ist doch aber in deiner Version schon gefixt?

schlafwandla · Post by **schlafwandla** » 22 Nov 2007, 09:57

Nein leider nicht habe auch schon 2.2.4 getestet leider das selbe Problem die in dem Bug beschriebene Zeile aus InterfaceCustomer.pm ist nicht modifieziert.
Oder ändert sich das je nachdem ob ich CustomerGroup Support ein und aus schalte. Bin noch in der Testphase und probier hin und her wies am besten passt, daher könnte es sein das bei meiner Installation schon zu viel verdreht war aber ich werde das noch einmal testen.

Gruß
schlafwandla

Andre Bauer · Post by **Andre Bauer** » 22 Nov 2007, 10:39

Na wenns wirklich nicht gefixt ist solltest Du das auch in den Bug reinschreiben.

otrsadmin · Post by **otrsadmin** » 09 Jan 2008, 11:37

Bei uns tritt das Problem auch auf, allerdings nicht immer. Es ist auch sehr schwierig, dies im lfd. Produktivsystem zu reproduzieren.

Der in http://bugs.otrs.org/show_bug.cgi?id=977 beschriebene Patch ist in der zur aktuellen Version 2.2.4 gehörenden Datei InterfaceCustomer.pm (siehe http://cvs.otrs.org/viewvc.cgi/otrs/Ker ... =rel-2_2_4) nicht enthalten. Leider fehlt eine Aussage des Entwicklers, wann und wie der Bug behoben wurde.

schlafwandla: Tritt das Problem bei Dir noch auf?

Werde noch ein wenig forschen und dann ggf. den Bug wieder öffnen.

otrsadmin · Post by **otrsadmin** » 09 Jan 2008, 18:02

Der in http://bugs.otrs.org/show_bug.cgi?id=977 beschriebene Bug ist definitiv noch da.

Bug-Beschreibung:

Agenten bekommen bei Web-Anfragen keine E-Mail-Benachrichtigungen für Tickets, die in Queues eingestellt werden, deren Gruppe nicht dem Wert des Konfigurationsparameters CustomerGroupAlwaysGroups entspricht, falls CustomerGroupSupport aktiviert ist.

Begründung:

Im Kunden-Frontend Kernel/System/Web/InterfaceCustomer.pm wird die bereits in Kernel/System/Ticket.pm korrekt initialisierte Variable falsch überschrieben:

Code: Select all

$Self->{GroupObject} = Kernel::System::CustomerGroup->new(%{$Self});

Das führt dazu, dass in Kernel/System/Ticket.pm in der Methode GetSubscribedUserIDsByQueueID bei der Überprüfung für jeden Agenten, der die Queue in seinen persönlichen Queues ausgewählt hat, ob er die passenden Berechtigungen hat, auf die falsche Methode GroupMemberList zugegriffen, nämlich die aus CustomerGroup.pm.

Code: Select all

my %GroupMember = $Self->{GroupObject}->GroupMemberList(
                UserID => $_,
                Type => 'ro',
                Result => 'HASH',
            );

Diese führt zu einem falschen SQL:

SELECT g.id, g.name, gu.permission_key, gu.permission_value, gu.user_id FROM groups g, group_customer_user gu WHERE g.valid_id IN ( 1 ) AND g.id = gu.group_id AND gu.permission_value = 1 AND gu.permission_key IN ('ro', 'rw') AND gu.user_id = 'XXX';

Diese Abfrage ist immer leer, denn in der Tabelle group_customer_user stehen in der Spalte user_id die Logins der Kunden-Benutzer (BTW: ist das eigentlich gewollt oder historisch einfach so?). Daher wird nur die in CustomerGroupAlwaysGroups konfigurierte Gruppe (i.d.R. users) ausgewählt, was zum beschriebenen Verhalten führt.

Die korrekte Methode, nämlich Kernel::System::Group->GroupMemberList führt folgendes SQL aus, was korrekt ist, da die Spalte user_id in der Tabelle group_user numerische IDs der system-Benutzer (Agenten) enthält:

SELECT g.id, g.name, gu.permission_key, gu.permission_value, gu.user_id FROM groups g, group_user gu WHERE g.valid_id IN ( 1 ) AND g.id = gu.group_id AND gu.permission_value = 1 AND gu.permission_key IN ('ro', 'rw') AND gu.user_id = XXX;

Abhilfe:

Die folgende Zeile

Code: Select all

$Self->{GroupObject} = Kernel::System::CustomerGroup->new(%{$Self});

in Kernel/System/Web/InterfaceCustomer.pm auskommentieren. Der kursierende Fix, diese in

Code: Select all

$Self->{CustomerGroupObject} = Kernel::System::CustomerGroup->new(%{$Self});

zu ändern, führt zum gleichen Ergebnis, da verhindert wird, dass GroupObject falsch überschrieben wird.