As I did not get any feedback on my previous post (How do you handle "passive" tickets?) I am trying another approach and I would like to know whether this is even possible in zammad.
If I send an email from outside of zammad from a known sender email@example.com to firstname.lastname@example.org to a ticket [T#1234] the ticket state will always change to open. This is not a wanted behaviour. The system should see this “external” email as an agent response without changing the current state of the ticket.
Use Postmaster filter to modify the article:
from contains email@example.com > set sender to agent / system Changing the sender does not work / does not change the behaviour. ticket goes form state X to open
Use Triggers to reset the state:
Well at this point it is too late to change the article / ticket. the Ticket was already set to open and the previous state is lost…
Is this behaviour desired or do I miss something?
In my opinion a message received from firstname.lastname@example.org to an existing ticket in email@example.com should be treated as if an agent has sent the message but no changes to the state should be made (this is the behaviour if you are replying on a pending ticket via web ui…)
But if I make a date with the customer and want the ticket to remember me at that date, I have no use for the Ticket State Reset. Whatever the Customer wants to tell me about that ticket, additional informations and so on, won’t change the date we planned. If he gets another urgent problem that he wants to tell me, he can open another ticket.
The only reason to behave that way is to reset the SLA Counter when the customer answers. I think the ideal way was: Setting “Remind me at” keeps it state forever and reminds me whatever happened. But I have an option in the SLA Settings to even react on tickets that are in “remind me” state.
This way, both functions are ensured. The Ticket Reminder remains, but if the customer answers, the SLA will do its job.
@MrGeneration indeed you are right. With triggers we are able to achieve our desired behavior quite easily. Yet the initial state change persists and a notification will be generated independent of the source (internal or external)
Our use case is quite simple:
We have a monitored email like ‘firstname.lastname@example.org’.
If a customer sends an email = state change
If our ERP system sends an email with ‘email@example.com’ = no state change, since it is an internal, known sender
I do remember that this behavior was achievable in prior versions (pre 5 or 4 I guess, don’t remember anymore, but we had tested it).
@bur your described behavior would also be nice to have…