Time event triggers based on breached escalation times

Hello hello,

  • Used Zammad version: 6.1
  • Used Zammad installation type: package
  • Operating system: Debian Bookworm
  • Browser + version: N/A

Expected behavior:

  • 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.
  • I cam across Trigger at time before pending datetime which describes a similar thing,
  • … 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.

Steps to reproduce the behavior:

  • I have created this for first response

and this for the Solution Time

  • 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)

Does anybody have an idea where my mistake may be?

Cheers, Schweigi

I made some progress:

  • The time in the red “incorrectly calculated” box seems to be the time, when the trigger added the articles in CET
  • I don’t know where the trigger knows about CET as the host system and Zammad is running in UTC
  • I am still unsure why both triggers run at the same and wrong time.

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?

I think I wrote this already on one other topic.

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.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.