Send notification mail to customers before ticket auto close

[AVillar]

Good afternoon everyone.

This is my first post in this community. I am writing after reading a few threads without reaching any conclusion.

This is my issue:
. I need to send email notifications to customers that have tickets "pending auto close +" a fixed time before these tickets are automatically closed.

Any help is welcome, thank you.-

PS: Sorry about my caveman english.

[root]

I see two possibilities:

#1 Use an Notification Agent and send the e-mail to the customer when the state is set (could be too late for your needs).
#2 Write your own Generic Agent and send the notification to the customer e.g. 8 hrs before the ticket will be closed.
I assume basic Perl knowledge and understanding of the API: http://dev.otrs.org/

[AVillar]

Hi root, thanks for reply.

Please, explain #2 option.

By the way, I was considering generate a new state called 'pending alert', when it reach end time, change state to 'pending auto close+' and send the email to customers.


The point is that I don't how to configure the generic agente or the new state.

Thanks in advance.-

[crythias]

What would be nice for this task, but doesn't exist in OTRS (put it in ideascale) is that you could have a pending state that chains to another pending state, and notification that is triggered on the state change.

[root]

Hi root, thanks for reply.

Please, explain #2 option.

By the way, I was considering generate a new state called 'pending alert', when it reach end time, change state to 'pending auto close+' and send the email to customers.

This is a nice approach. I like it.

The point is that I don't how to configure the generic agente or the new state.

In the directory /opt/otrs/Kernel/System/GenericAgent are some examples for GenericAgents. New states can be configured via SysConfig.

Write your GenericAgent code and configure it's usage da describe in Config/GenericAgent.pm.examples (rename it to Config/GenericAgent.pm to use it)

Good luck
Roy

[AVillar]

Danke Roy

Already created a new state called 'pending alarm'.It looks fine, but I can't understand GenericAgent's examples. This uses a lot of constant and variables that i don't know.

I think only need to change the state via generic agent to 'pending auto close+'. I need help with the creating of this task.

By the way, I don't know how to send the notification/email at the change of state. I guess the generic agent can do that, but really I'm not sure.

Thanks in advance.-

[AVillar]

By the way, I don't know how to send the notification/email at the change of state. I guess the generic agent can do that, but really I'm not sure.

This problem is already solved.

Only need to know how to change ticket status via generic agent (or any other way).

Thanks in advance.-

[AVillar]

Thanks everybody. We are almost solved the issue.

At summary, I did that:
. Created a new state called 'pending alert'. This state is from a 'pending reminder' kind.
. Created a notification email to customers. This send an email to customers when the ticket state change to 'pending auto close+'.

. Created a generic agent that can change the state from 'pending alert' to 'pending auto close+'. So far, everything is ok, but there is a problem with the generic agent ticket filter. I'm trying to use the 'pending times' options there. I have selected the second option and I was assuming it triggers within the last 10 hours of the pending time set in the ticket. But it doesn't work that way. When I change the value at the little red box, the generic agent choose all or none of the tickets with 'pending alert' state depending on the selected value. Please see the image.



Thanks in advance.-

[AVillar]

Good afternoon everybody

In this days without any answers, I did some tests:

At Sysconfig -> Core::Ticket -> Ticket::StateAfterPending, there is an option that allow set up the new state for a 'pending auto' state.
So I changed the 'Pending Alerta' status type from 'pending reminder' to 'pending auto'.
Then, added the values 'Pendiente Alerta' to 'pending auto close+'. Lamentably I can't see any results after the time pending is reached (can't change the state automatically). Attached a image to show you the change I did.

I can't understand where is the mistake i'm doing, or i'm at an otrs bug? Please help me.

Thanks in advance, good weekend everybody.

[AVillar]

¿Any idea?

[AVillar]

I fixed the problem with the info at this thread:
. viewtopic.php?f=62&t=6843

I discard the ticket::StateAfterPending option. I come back to the generic agent choice and found this thread.

Only change the - to + in Kernel/System/Ticket.pm at line 4975:
$TimeStamp -= ( $Param{TicketPendingTimeOlderMinutes} * 60 );

to this way:
$TimeStamp += ( $Param{TicketPendingTimeOlderMinutes} * 60 );

Thanks a lot crythias!!!

[crythias]

You're welcome, but I found out the reason was because the full translation should be something like:

before/after [30 minutes] {ago}, which explains why the math works the way it's coded.

Or, in more specific terms:

The pending ticket time expired before (less than) 10 hours ago
The pending ticket time expired after (more than) 10 hours ago

(it can never tell you something will expire in 10 hours by how it's currently programmed.)
What can you do about that?

Create a new pending type ... something "Pending 10 hours earlier" and set that time to when you'd like to know it's going to expire in 10 hours. Next state after that would be "soon to close" or something. Then subsequent warnings after that pending time has been reached via Generic agent, until Generic agent determines that pending time has been reached 10 hours ago then close the ticket.

Summary:

• Set a pending time before you need subsequent warnings
• Use Generic agent to test against the age of the pending time completion (before an hour ago, before 2 hours ago, before 9 hours ago)
• Use Generic agent to test for the "last" time of the warning (after 10 hours ago) and change state to closed if it's open, for instance

The only question I can't answer is if this will run multiple times on the same ticket for the same event (if you're notifying on multiple ages). To prevent that, you may want to add and change states and filter on the current state.
Filter
ticket state: 9 hours to close and pending time before 2 hours ago, set ticket state to 8 hours to close... Notification (Event) on state change.
Something like this. I can't exactly wrap my head around all the iterations.