A time based event trigger, bound to the Escalation Time (First Response) should save the time of the breached ticket into a custom “date” field and should also set a custom field of type “boolean” to “yes”.
Furthermore this time stamp is put into an internal note
The same should be done for the Solution Time
Actual behavior:
I haven’t found any constellation of “within before/after”, "after/before (relative), …, which would correctly calculate the escalation times and put the correct values into the custom date fields.
… but according to the documentation “time event” can be chosen for “pending times” and also “escalations”. Hence I would assume this should work as expected.
Roughly around the breach of the first response time both notes are added (expected would be the first one only, as the solution time has not been reached yet)
and the calculated time in the custom date fields is both 20:40 (where I don’t have any clue where this may come from)
Zammad stores all it’s datetime information in UTC. What Zammad does for fields (not free form text in articles!) is to convert the UTC time values to your local timezone.
Zammad does this by gettign this information from your browser.
I’m not sure if I get the scope correctly…
You’re saying that the trigger does set the datetime value in your local time instead of UTC and thus the time is off…?
Yes, I am saying the times in the red box represent the time in my timezone (CET) when triggers get executed and not the time when the ticket actually escalates in its different SLA targets like “First Response” and “Solution Time”.
The targets in the green box are the correctly calculated timestamps according to the SLA configuration of “15 minutes” First Response Time and “30 minutes” Solution Time".
But as the triggers which are supposed to run when the First Response and the Solution Time is reached get executed at the same time, the values in the red box are the same and too early.
So in my opinion the actual issue is that both triggers get executed at the same wrong time. Not 1 minute after when the First Response and Solution Time is reached (like configured within the triggers) but randomly earlier. Sometimes 10 minutes before, sometimes 12 minutes. And why both at the same time?
There are jobs that are doing these checks, for the pending reached check it runs every 15 minutes, and for the esclations check it runs every 5 minutes.
At least this should explain the same execution time. I didn’t go deeper/couldn’t follow completely in this UTC/CET problem yet.
I don’t think this explains why both triggers get executed at the same time.
I have changed the Solution Time SLA target to 1:00 h and the second trigger for the Solution-Time Breach, which uses the “Escalation at (Close Time)” time event, is still executed at the same time like the first trigger for the first response breach, which is configured using the “Escalation at (First Response Time)” time event.
I found a solution or workaround by changing the trigger condition to “within last (relative) 5 minutes”, which gets close enough to the actual breach.
