Used Zammad installation source: docker + git tag 3.0.0
Operating system: GNU/Linux
Browser + version: -
This is not a clean 3.0.0 install, it has been upgraded from previous versions. I don’t know if it has importance. UPDATE: Tried a fresh 3.0.0 install, observed same issue.
I tried to find similar issue on community, github issues, and even commits from 3.0.0 → I did not find anything on this.
My goal is to keep track of tickets that triggered an escalation, to get monthly stats. I noticed than when a ticket is closed, its escalation variables gets removed (“update_escalation_at” & “escalation_at”).
Expected behavior:
When creating a trigger on “Escalation” + “Has changed”, I expect this trigger to fire when a ticket escalate. As a test, my trigger adds an ‘Escalation’ tag to the ticket.
Actual behavior:
The tag won’t be added when the ticket escalate.
The tag will be added if i change the state of the ticket (“New” → “Open”).
Steps to reproduce the behavior:
Create a trigger with “Escalation has changed” condition, and execute “Tags add Escalation”.
Create a ticket.
Change its state from “New” to “Open” → The “Escalation” tag is added.
Create a trigger with “Escalation has changed” condition, and execute “Tags add Escalation”.
Create a ticket.
Wait for SLA to fire escalation → Escalation notification and mail does work.
First of all: Welcome.
Please keep in mind that this is a free community, where everyone helping on here is contributing to the community for free. If you expect commercial support grade, you can get that directly from us if needed.
Now to your problem:
The “problem” is, that a escalating ticket is no “Updated action” in terms of a trigger.
What you can do to workaround your problem, is to use the scheduler and run it everytime.
Before we continue, this has a potential downside: This might let tickets slip, that are getting out of escalation within 9 minutes (in between scheduler runs)
Set a scheduler to check for the condition:
Tag contains not “isescalated”
Escalation within next (relative) 1 minutes
Action:
Set tag “isescalated”
Above can be adjusted to your needs (e.g. you could use an object instead of an tag.
By doing the above, you have a permanent information (if the agent doesn’t remove it) which you can search and filter for. Even in reporting terms.
1/ Yes, i am used to open source communities. I am not expecting commercial support, i am actually testing the app, to maybe use it internally (for 1, maybe 2 people).
2/ Thanks for the tip, im going to test this ASAP (currently writting documentation on another project, but will do it right after!)
3/ I still don’t understand why changing the state of the ticket (from new to open) triggers “Escalation has changes”, isn’t it a bug? I do understand (now that you explained me) that an escalation does not run triggers, but what about this case?
4/ Thanks for the object idea, too! We are a very very small team, so this is not an issue for us, but this is probably a better “general” implementation to do!
I’ve been checking this and understand what you’re referecing to.
After that I talked to a developer, what exactly is happening (and why).
So: This works as designed (so feature, no bug ). We agree that the naming of this field is miss leading. This condition checks if the escalation_at field of the ticket has changed or is affected (depending on your configuration).
This only affects tickets in SLA context.
Sorry for the confusion!
I already created an enhancement issue, if you want to subscribe to it:
Ok, i took time to test your proposal :
While it may not be (minute-time) perfect, this is compatible with my needs.
I changed it a bit to trigger for tickets in a 10 minutes timeframe.
It is not very important for me, to have 10min delay (too short or too late) between SLA defined time and scheduler item that trigger action.
). We agree that the naming of this field is miss leading. This condition checks if the