Nice Gerald!!
Now the Event flow got clear in my mind. I'll try to implement it and as
soon I have it well tested I'll try to post it.
Thanks again.
Daniel Santos
[email protected]
ETICE - Empresa de Tecnologia da Informação do Ceará
www.etice.ce.gov.br
+55 85 3101.6600
On 07/09/13 17:50, Gerald Young wrote:
heh. If you want "Best Practices" of OTRS development, I might not be
the best source. I come from a JFDI background. :) :)
Assuming that GenericAgent.pm is calling
Kernel/System/GenericAgent/NotifyAgentGroupOfCustomQueue.pm
It's calling TicketObject->SendAgentNotification and that's about it.
This is in Kernel/System/Ticket/Article.pm which ends in
*ArticleAgentNotification *event.
"But this happens all the time!" yeah, pretty much.
"How to test escalation response?"
it's not the event that's EscalationxxxTimexxx. That latter is
actually a Parameter attached to the result from TicketGet against the
ticket object. Basicaly, upon ArticleAgentNotification Event, you'd
check the TicketGet result's
EscalationResponseTime (unix time stamp of response
time escalation)
EscalationUpdateTime (unix time stamp of update
time escalation)
EscalationSolutionTime (unix time stamp of solution
time escalation)
versus "now" and determine if now is > than escalation and check that
other NotifyAgentGroupOfCustomQueue.pm for methods to check if it's
sent but if you're already there, you might just copy that and modify
the method of send to be jabber, then use it instead.
"What would you do?"
That last. The code to send the message only once is already made.
It's all about SendAgentNotification that's the meat of the difference
between whether to send by email or send by Jabber anyway....
"So, now what?"
Well, if I really wanted to, I'd determine if I'd plug
ArticleAgentNotification Event directly to jabber anyway. What I mean
is, the event of ArticleAgentNotification may trigger the send via
Jabber event all the time. And why not? I think that's the point of
your jabber interface anyway.
On Tue, Jul 9, 2013 at 3:51 PM, Daniel Santos
<[email protected] <mailto:[email protected]>>
wrote:
Hmm... got it!!!
For me, it's important to be in compliance with the 'best
practices' of OTRS development...
As I do not change anything in the ticket, like you said, its
better to have a Ticket Event triggered when the GenericAgent
sends the Escalation notification. I've tried it before, but I
don't know which Event should I verify for a escalation
notification sent by the Generic Agent... would it be something
like this?
...
if ( $Ticket{Event} eq "EscalationResponseTimeNotifyBefore" ) { ... }
if ( $Ticket{Event} eq "EscalationUpdateTimeNotifyBefore" ) { ... }
if ( $Ticket{Event} eq "EscalationSolutionTimeNotifyBefore" ) { ... }
?
Regards,
Daniel Santos
[email protected] <mailto:[email protected]>
ETICE - Empresa de Tecnologia da Informação do Ceará
www.etice.ce.gov.br <http://www.etice.ce.gov.br>
+55 85 3101.6600
On 07/09/13 16:30, Gerald Young wrote:
If the generic agent was able to change something (dynamic field,
state, queue) that created an event, I'd use an event.
If not, I'd add the check at the same time as the other
GenericAgent that does that.
"Which is the best?" In my opinion, in theory, the thing that
doesn't run code unnecessarily. In practice, the thing that works
for your situation.
On Tue, Jul 9, 2013 at 3:10 PM, Daniel Santos
<[email protected]
<mailto:[email protected]>> wrote:
Gerald,
I used the same approach that GenericAgent uses to send
escalated notifications, which is a cron scheduled job that
runs bin/otrs.GenericAgent.pl <http://otrs.GenericAgent.pl>
and send escalation notifications as necessary. The only
difference on my module is that, instead of sending to
e-mail, we are sending to jabber (xmpp).
In your opinion, which is the best? GenericAgent or Ticket
Event? In the meantime, which Event should I listen to if
using Ticket Event?
Daniel Santos
[email protected] <mailto:[email protected]>
ETICE - Empresa de Tecnologia da Informação do Ceará
www.etice.ce.gov.br <http://www.etice.ce.gov.br>
+55 85 3101.6600
On 07/09/13 16:01, Gerald Young wrote:
You could, but I don't understand why you want to use a
scheduled job to do a notification when a ticket is
escalated. It would appear to me you'd want that as an event
upon occurrence, not a scheduled test if criteria has been met.
If you wish to do what you propose, how you've asked is the
correct way to accomplish the goal.
On Tue, Jul 9, 2013 at 2:36 PM, Daniel Santos
<[email protected]
<mailto:[email protected]>> wrote:
Hi,
I've managed to get my module working... it was a typo
in my Needed Modules. Sorry about that.
Now I'm wondering how can I add a new Generic Agent job
in Kernel/Config/GenericAgentJabberNotification.pm and
active it without touching Kernel/Config/GenericAgent.pm.
Do I need to setup a new cron entry passing -c
"Kernel::Config::GenericAgentJabberNotification" ??
Thanks.
Daniel Santos
[email protected]
<mailto:[email protected]>
ETICE - Empresa de Tecnologia da Informação do Ceará
www.etice.ce.gov.br <http://www.etice.ce.gov.br>
+55 85 3101.6600
On 07/09/13 09:24, Daniel Santos wrote:
Hi,
I'm setting up a Generic Agent to make some
customization in my OTRS installation to send other
notifications when a ticket is escalated. But when I
try to use a Get from ConfigObject I'm always
getting a: "Message: Can't call method "Get" on an
undefined value". ConfigObject is already in the
Needed objects 'qw', but still doesn't work.
How can I get my module configuration parameters
from Config when using a Generic Agent?
Thanks.
---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage:http://otrs.org/
Archive:http://lists.otrs.org/pipermail/otrs
To unsubscribe:http://lists.otrs.org/cgi-bin/listinfo/otrs
---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage:http://otrs.org/
Archive:http://lists.otrs.org/pipermail/otrs
To unsubscribe:http://lists.otrs.org/cgi-bin/listinfo/otrs
---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
