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.
Situation:
If I send an email from outside of zammad from a known sender support@acme.com to support@acme.com 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.
Solutions tried:
Use Postmaster filter to modify the article:
from contains support@acme.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 support@acme.com to an existing ticket in support@acme.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…)
will the ticket again go from In Progress to Open with if support@acme.com sends an email to support@acme.com?
will the agent receive an notification if support@acme.com sends an email to support@acme.com?
Addition 2: No matter what you set in Postmaster Filter an externally sent email always triggers a ticket update / change and therefore a notification. even though the sender = receiver.
this behaviour is odd: even articles modified by the postmaster filter to sender = agent and visibility = internal trigger a state change / notification etc.
In my understanding an article marked as sender = agent should not trigger anything as the agent him/herself did “create” the article.
The only way you can overcome this default behavior is by using tons of triggers and possibly either tags or a custom select field that you can hide from your agents.
Keep in mind that this endangers your agents to missing follow ups and is one of the reasons Zammad behaves the way it does.
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 ‘orders@acme.com’.
If a customer sends an email = state change
If our ERP system sends an email with ‘orders@acme.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…