[otrs] Ticket Event Triggers

[Jason Salaz]

I'm trying to add a few Ticket Notification Events, specifically, one that will notify our entire support team of a new ticket creation, as well as when a customer follows up on an already created ticket.
We're using OTRS 2.4.7

I created a notification on "TicketCreate", and a notification (with a different body text) on "TicketCustomerUpdate". But now, new tickets from customers result in two e-mails for a single event. I'm assuming this is because the logic works out that a "Customer" "Updated" a ticket, by creating it, which is patently false.

Is this considered expected behavior? A bug? Or something else entirely?

My current solution is to set the "TicketCreate" notification to invalid (or delete it), which I don't like, because occasionally an Agent will create a ticket on behalf of a customer, but that will result in no notifications going out as a result. Is there a middle ground I'm missing?
---------------------------------------------------------------------
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

NEW! ENTERPRISE SUBSCRIPTION - Get more information NOW!
http://www.otrs.com/en/support/enterprise-subscription/

[Nils Leideck - ITSM]

Hi,

On 10.06.2010, at 20:51, Jason Salaz wrote:

I'm trying to add a few Ticket Notification Events, specifically, one that will notify our entire support team of a new ticket creation, as well as when a customer follows up on an already created ticket.
We're using OTRS 2.4.7

I created a notification on "TicketCreate", and a notification (with a different body text) on "TicketCustomerUpdate". But now, new tickets from customers result in two e-mails for a single event. I'm assuming this is because the logic works out that a "Customer" "Updated" a ticket, by creating it, which is patently false.

Is this considered expected behavior? A bug? Or something else entirely?

My current solution is to set the "TicketCreate" notification to invalid (or delete it), which I don't like, because occasionally an Agent will create a ticket on behalf of a customer, but that will result in no notifications going out as a result. Is there a middle ground I'm missing?

Please be so kind and open a bug report for this behavior on http://bugs.otrs.com 

For the meantime I think you should be fine with selecting ticket states as well as a kind of restriction.

If there is a new Ticket the state will be “new", otherwise it should be something different.

Freundliche Grüße / Kind regards

Nils Leideck

-- 
Nils Leideck
Senior Consultant

nils.l...@leidex.net
nils.l...@otrs.com

http://webint.cryptonode.de / a Fractal project

[Jason Salaz]

Please be so kind and open a bug report for this behavior on http://bugs.otrs.com 

Doing so right now.

For the meantime I think you should be fine with selecting ticket states as well as a kind of restriction.

If there is a new Ticket the state will be “new", otherwise it should be something different.

I didn't even think about adding those. And that is a very acceptable compromise in the meantime. I've set the TicketCreate notification to also include State: New, and the TicketCustomerUpdate to also include every state EXCEPT new.

Thanks much, Nils.

[Jason Salaz]

Actually, before I hit submit on the bug, it appears I hit another stumbling block.

I'm trying to understand exactly what these events correspond too, because I'm having inconsistent results given my expectations.

I created a test ticket after modifying our notification settings as I mentioned previously, and then followed up on the ticket before taking ownership of it. The intention being that our entire group should have gotten an e-mail noting that the customer followed up on the open ticket.

So I have Event: TicketCustomerUpdate, State: closed successful, closed unsuccessful, merged, open, pending close+, pending close-, pending reminder, and removed.
The Recipient is still "Agent (All with write permissions)".

But, I'm not receiving notification of any of the followups. I started to assume it may have been a race condition with changing the State from new to open the first time, so I followed up a second time after it was "open". This didn't work, subsequent customer followups are not generating notifications.

I changed the event to "ArticleFreeTextUpdate" just out of curiosity, still nothing.

At this point, I'm completely lost as to what exactly is driving the Event (and why it's not occurring for me). And yes, not notification events are still set to valid.

[Nils Leideck - ITSM]

Hi,

On 10.06.2010, at 22:19, Jason Salaz wrote:

So I have Event:  TicketCustomerUpdate, State: closed successful, closed unsuccessful, merged, open, pending close+, pending close-, pending reminder, and removed.
The Recipient is still "Agent (All with write permissions)".

But, I'm not receiving notification of any of the followups. I started to assume it may have been a race condition with changing the State from new to open the first time, so I followed up a second time after it was "open". This didn't work, subsequent customer followups are not generating notifications.

TicketCustomerUpdate means updating the customer details on the ticket, it is NOT a follow up sent by a customer ;-)

[Jason Salaz]

On Jun 10, 2010, at 2:56 PM, Nils Leideck - ITSM wrote:

> TicketCustomerUpdate means updating the customer details on the ticket, it is NOT a follow up sent by a customer ;-)

I guess that explains the original issue, since the customer "updated" the details, in creating the ticket. I assume also that "FreeText" is the FreeText fields, of which I have none, so those events (both Ticket and Article) are also irrelevant to me.

The two questions that come out of this then are;
(1) Is there no Event suitable for when a customer responds to a ticket that already exists?

(2) Is there documentation on these Events somewhere? The only existence of "Event" in the Documentation is Events for Auto Answers (not relevant to the issue), and Section 5.8 (Notifications) is very scarce.