Re: [otrs-de] OTRS 2.1.5 - Besitzeraktualisierung erzeugt 2 Notification Mails?
Hallo,
Wir haben zwar nur die 2.1.4 aber ich kann beide Probleme bestätigen. 2 Notification Mails beim Owner update und Notifications für "falsche" Benutzer.
Gruß Alex
André Bauer schrieb:
Kann das noch jemand bestätigen? Wenn ja, würde ich einen Bugreport dazu aufmachen.
Bestätigen kann ich es, aber ich hab es eher für ein missverstandenes Feature gehalten..
Im neusten OTRS habe ich auch das Problem, das Notifications für "falsche" Benutzer rausgehen, was noch im "alten" OTRS nicht so war. (Komischerweise nur in einem von zwei OTRS die ich betreue..)
Michael
Hallo.
Was ist mit den "Notifications für falsche Benutzer" genau gemeint? Das habe ich nämlich noch nicht beobachtet...
Hallo zusammen,
habe bisher immer die Funktion "Don`t allow ticket to close in the `Raw` Queue" aus den FAQ Artikeln auf unsere Hauptqueue eingesetzt. Seit meinem Update von 2.1.3 auf 2.1.4 können Tickets wieder geschlossen werden.
Gibt es eine Möglichkeit zu prüfen, ob diese ACL Passagen in der config.pm überhaupt abgearbeitet werden?
Hier nochmal der Codeauschnitt:
# ticket acl $Self->{TicketAcl}->{`ACL-Name-1`} = { # match properties Properties => { # current ticket match properties Ticket => { QueueID => [1], } }, # return possible options (white list) Possible => { # possible ticket options (white list) Ticket => { State => [`new`, `open`, `pending reminder`], }, # possible action options Action => { AgentTicketLock => 0, AgentTicketZoom => 1, AgentTicketClose => 0, AgentTicketPending => 1, AgentTicketNote => 1, AgentTicketHistory => 1, AgentTicketPriority => 1, AgentTicketFreeText => 1, AgentTicketCompose => 1, AgentTicketBounce => 1, AgentTicketForward => 1, AgentTicketPrint => 1, AgentTicketPhone => 1, AgentTicketPhoneOutbound => 1, AgentTicketCustomer => 1, AgentTicketMove => 1, AgentTicketOwner => 1, AgentTicketResponsible => 1, AgentLinkObject => 1, }, }, };
Schöne Grüße Christian Bock
Hallo Christian,
Bock, Christian schrieb:
Hallo zusammen,
habe bisher immer die Funktion "Don`t allow ticket to close in the `Raw` Queue" aus den FAQ Artikeln auf unsere Hauptqueue eingesetzt. Seit meinem Update von 2.1.3 auf 2.1.4 können Tickets wieder geschlossen werden.
Wieso es nicht fkt. kann ich Dir nicht sagen.
Gibt es eine Möglichkeit zu prüfen, ob diese ACL Passagen in der config.pm überhaupt abgearbeitet werden?
In Kernel/System/Ticket.pm kannst Du in der sub new $Self->{Debug} setzen (z.B. bis über 4) und das Modul wird sehr gesprächig (siehe OTRS-Logging). Wenn's nicht reicht empfehle ich Dir innerhalb der sub TicketAcl diverse print STDERR "was immer du willst"; und er schreibt Dir in Dein Webserver-Fehlerlog.
Hier nochmal der Codeauschnitt:
# ticket acl $Self->{TicketAcl}->{`ACL-Name-1`} = { # match properties Properties => { # current ticket match properties Ticket => {
QueueID => [1],
Probiere doch mal stattdessen
Queue => [`Raw`],
} }, # return possible options (white list) Possible => { # possible ticket options (white list) Ticket => { State => [`new`, `open`, `pending reminder`], }, # possible action options Action => { AgentTicketLock => 0, AgentTicketZoom => 1, AgentTicketClose => 0, AgentTicketPending => 1, AgentTicketNote => 1, AgentTicketHistory => 1, AgentTicketPriority => 1, AgentTicketFreeText => 1, AgentTicketCompose => 1, AgentTicketBounce => 1, AgentTicketForward => 1, AgentTicketPrint => 1, AgentTicketPhone => 1, AgentTicketPhoneOutbound => 1, AgentTicketCustomer => 1, AgentTicketMove => 1, AgentTicketOwner => 1, AgentTicketResponsible => 1, AgentLinkObject => 1, }, }, };
Schöne Grüße Christian Bock
Gruß, Alexander
In Kernel/System/Ticket.pm kannst Du in der sub new $Self->{Debug} setzen (z.B. bis über 4) und das Modul wird sehr gesprächig (siehe OTRS-Logging).
Habe ich jetzt mal gemacht. Da kommt z.B. für eines der Tickets, welche ich eigentlich laut ACL nicht schließen dürfte, weil es sich in besagte Queue befindet:
[Wed Jan 31 08:42:25 2007][Debug][Kernel::System::Ticket::Permission][1589] Got 'rw' true for TicketID '1779' through Kernel::System::Ticket::Permission::GroupCheck! [Wed Jan 31 08:42:25 2007][Debug][Kernel::System::Ticket::Permission][1589] Got 'priority' true for TicketID '1779' through Kernel::System::Ticket::Permission::GroupCheck! [Wed Jan 31 08:42:25 2007][Debug][Kernel::System::Ticket::Permission][1589] Got 'rw' true for TicketID '1779' through Kernel::System::Ticket::Permission::GroupCheck! [Wed Jan 31 08:42:25 2007][Debug][Kernel::System::Ticket::Permission][1589] Got 'close' true for TicketID '1779' through Kernel::System::Ticket::Permission::GroupCheck!
Got 'close' true for TicketID... through ... Permission::GroupCheck ?
Laut Gruppenberechtigung darf ich das Ticket schließen. Ist vielleicht Gruppenrecht vorrangig vor ACL?
Wenn's nicht reicht empfehle ich Dir innerhalb der sub TicketAcl diverse print STDERR "was immer du willst"; und er schreibt Dir in Dein Webserver-Fehlerlog.
STDERR? Gibt's hierfür eine Doku?
Danke und schöne Grüße Christian Bock
Aha... Neue Erkenntnis.
Das ist nicht seit dem Update auf 2.1.5 so, sondern seit dem Einfügen einer zweiten ACL (mit Namen "bitte-aendern").
Wir haben also erst mal die ACL, welche das Schließen in der Queue "NEU" (entspricht der Hauptqueue, wie RAW) verbietet (mit Namen "no-close-in-new"). Steht die alleine, können Tickets entsprechend nicht geschlossen werden.
Zusätzlich soll es weitere Einschränkungen geben, wenn ein Ticket eine bestimmte CustomerID hat. Hier soll nur der Kunde geändert werden können, bevor richtig mit dem Ticket gearbeitet werden kann. Sobald diese ACL aber in der config.pm drin steht, können alle Tickets in "NEU" uneingeschränkt geschlossen o.a. werden. Steht die neue ACL ("bitte-aendern") vor der ersten ACL ("no-close-in-new"), greift scheinbar nur die no-close-in-new.
Sieht so aus, als hätte ich einen Gedankenfehler.
Hier die zweite ACL:
$Self->{TicketAcl}->{`bitte-aendern`} = { Properties => { Ticket => { CustomerID => ['BITTE AENDERN'], } }, Possible => { Ticket => { State => [`new`, `open`, `pending reminder`], }, Action => { AgentTicketLock => 0, AgentTicketZoom => 1, AgentTicketClose => 0, AgentTicketMerge => 0, AgentTicketPending => 0, AgentTicketNote => 0, AgentTicketHistory => 1, AgentTicketPriority => 0, AgentTicketFreeText => 0, AgentTicketCompose => 0, AgentTicketBounce => 0, AgentTicketPrint => 0, AgentTicketForward => 0, AgentTicketPhone => 0, AgentTicketPhoneOutbound => 0, AgentTicketCustomer => 1, AgentTicketMove => 0, AgentTicketOwner => 0, AgentTicketResponsible => 0, AgentLinkObject => 0, }, }, };
Hallo,
Bock, Christian schrieb:
Aha... Neue Erkenntnis.
Das ist nicht seit dem Update auf 2.1.5 so, sondern seit dem Einfügen einer zweiten ACL (mit Namen "bitte-aendern").
Wir haben also erst mal die ACL, welche das Schließen in der Queue "NEU" (entspricht der Hauptqueue, wie RAW) verbietet (mit Namen "no-close-in-new"). Steht die alleine, können Tickets entsprechend nicht geschlossen werden.
Zusätzlich soll es weitere Einschränkungen geben, wenn ein Ticket eine bestimmte CustomerID hat. Hier soll nur der Kunde geändert werden können, bevor richtig mit dem Ticket gearbeitet werden kann. Sobald diese ACL aber in der config.pm drin steht, können alle Tickets in "NEU" uneingeschränkt geschlossen o.a. werden. Steht die neue ACL ("bitte-aendern") vor der ersten ACL ("no-close-in-new"), greift scheinbar nur die no-close-in-new.
ACLs werden alphabetisch anhand Ihres ACL-Namens abgearbeitet, wobei standardmäßig nach einem Match nicht aufgehört wird, sondern nachfolgende ACLs ebenso berücksichtigt werden.
Ggf. trifft Dein Verhalten genau den berichteten Bug http://bugs.otrs.org/show_bug.cgi?id=1583
Falls dem so ist, so ergänze bitte unbedingt diesen Bug mit Deinem Fallbeispiel.
Sieht so aus, als hätte ich einen Gedankenfehler.
Hier die zweite ACL:
$Self->{TicketAcl}->{`bitte-aendern`} = { Properties => { Ticket => { CustomerID => ['BITTE AENDERN'], } }, Possible => { Ticket => { State => [`new`, `open`, `pending reminder`], }, Action => { AgentTicketLock => 0, AgentTicketZoom => 1, AgentTicketClose => 0, AgentTicketMerge => 0, AgentTicketPending => 0, AgentTicketNote => 0, AgentTicketHistory => 1, AgentTicketPriority => 0, AgentTicketFreeText => 0, AgentTicketCompose => 0, AgentTicketBounce => 0, AgentTicketPrint => 0, AgentTicketForward => 0, AgentTicketPhone => 0, AgentTicketPhoneOutbound => 0, AgentTicketCustomer => 1, AgentTicketMove => 0, AgentTicketOwner => 0, AgentTicketResponsible => 0, AgentLinkObject => 0, }, }, };
Die ACL schaut (ungetestet) so korrekt aus.
Gruß, Alexander
Weiß jemand, ob sich hier schon was Neues getan hat? Also das nutzen von mehreren ACLs. War nicht irgendwann die Rede von Workflow über mehrere ACLs?
Grüße Christian Bock
-----Ursprüngliche Nachricht----- Von: otrs-de-bounces@otrs.org [mailto:otrs-de-bounces@otrs.org] Im Auftrag von Bock, Christian Gesendet: Mittwoch, 31. Januar 2007 10:07 An: User questions and discussions about OTRS.org in German Betreff: AW: [otrs-de] Don`t allow ticket to close in the`Raw`Queue - NeueErkenntnis
Aha... Neue Erkenntnis.
Das ist nicht seit dem Update auf 2.1.5 so, sondern seit dem Einfügen einer zweiten ACL (mit Namen "bitte-aendern").
Wir haben also erst mal die ACL, welche das Schließen in der Queue "NEU" (entspricht der Hauptqueue, wie RAW) verbietet (mit Namen "no-close-in-new"). Steht die alleine, können Tickets entsprechend nicht geschlossen werden.
Zusätzlich soll es weitere Einschränkungen geben, wenn ein Ticket eine bestimmte CustomerID hat. Hier soll nur der Kunde geändert werden können, bevor richtig mit dem Ticket gearbeitet werden kann. Sobald diese ACL aber in der config.pm drin steht, können alle Tickets in "NEU" uneingeschränkt geschlossen o.a. werden. Steht die neue ACL ("bitte-aendern") vor der ersten ACL ("no-close-in-new"), greift scheinbar nur die no-close-in-new.
Sieht so aus, als hätte ich einen Gedankenfehler.
Hier die zweite ACL:
$Self->{TicketAcl}->{`bitte-aendern`} = { Properties => { Ticket => { CustomerID => ['BITTE AENDERN'], } }, Possible => { Ticket => { State => [`new`, `open`, `pending reminder`], }, Action => { AgentTicketLock => 0, AgentTicketZoom => 1, AgentTicketClose => 0, AgentTicketMerge => 0, AgentTicketPending => 0, AgentTicketNote => 0, AgentTicketHistory => 1, AgentTicketPriority => 0, AgentTicketFreeText => 0, AgentTicketCompose => 0, AgentTicketBounce => 0, AgentTicketPrint => 0, AgentTicketForward => 0, AgentTicketPhone => 0, AgentTicketPhoneOutbound => 0, AgentTicketCustomer => 1, AgentTicketMove => 0, AgentTicketOwner => 0, AgentTicketResponsible => 0, AgentLinkObject => 0, }, }, };
OTRS Mailingliste: otrs-de - Webpage: http://otrs.org/ Archiv: http://lists.otrs.org/pipermail/otrs-de/ Listenabo verwalten: http://lists.otrs.org/cgi-bin/listinfo/otrs-de/ Support oder Consulting fuer Ihr OTRS System? =http://www.otrs.com/
Hallo,
Bock, Christian schrieb:
In Kernel/System/Ticket.pm kannst Du in der sub new $Self->{Debug} setzen (z.B. bis über 4) und das Modul wird sehr gesprächig (siehe OTRS-Logging).
Habe ich jetzt mal gemacht. Da kommt z.B. für eines der Tickets, welche ich eigentlich laut ACL nicht schließen dürfte, weil es sich in besagte Queue befindet:
[Wed Jan 31 08:42:25 2007][Debug][Kernel::System::Ticket::Permission][1589] Got 'rw' true for TicketID '1779' through Kernel::System::Ticket::Permission::GroupCheck! [Wed Jan 31 08:42:25 2007][Debug][Kernel::System::Ticket::Permission][1589] Got 'priority' true for TicketID '1779' through Kernel::System::Ticket::Permission::GroupCheck! [Wed Jan 31 08:42:25 2007][Debug][Kernel::System::Ticket::Permission][1589] Got 'rw' true for TicketID '1779' through Kernel::System::Ticket::Permission::GroupCheck! [Wed Jan 31 08:42:25 2007][Debug][Kernel::System::Ticket::Permission][1589] Got 'close' true for TicketID '1779' through Kernel::System::Ticket::Permission::GroupCheck!
Beim obigen Logging werden keine ACL-Loggings mit angezeigt, diese müssten nach den Permission-Modulen (hier GroupCheck) eigentlich kommen, jedoch wird nur geloggt falls eine ACL zutrifft (dieses Verhalten kannst Du dem Source-Code entnehmen).
Got 'close' true for TicketID... through ... Permission::GroupCheck ?
Laut Gruppenberechtigung darf ich das Ticket schließen. Ist vielleicht Gruppenrecht vorrangig vor ACL?
Nein, ACLs werden nach den Permission-Modulen ausgewertet.
Wenn's nicht reicht empfehle ich Dir innerhalb der sub TicketAcl diverse print STDERR "was immer du willst"; und er schreibt Dir in Dein Webserver-Fehlerlog.
STDERR? Gibt's hierfür eine Doku?
Es handelt sich um Standard-Perl - hat also nichts mit OTRS zu tun.
Danke und schöne Grüße Christian Bock
Gruß, Alexander
participants (4)
-
Alexander Kravets
-
Alexander Scholler
-
André Bauer
-
Bock, Christian