Delayed change of ticket state

Hi everyone :wave::


  • Used Zammad version: 3.1.x
  • Used Zammad installation source: (source, package, …): package
  • Operating system: Ubuntu 18.04.
  • Browser + version: Firefox 69.0.1
  • PostgreSQL 10.10
  • elasticsearch 5.6.16

Expected behavior:

A ticket with the state “pending reminder” reaches it’s pending time and should be reopen again.

Actual behavior:

The ticket reopens around 74 minutes late.

Here are some more specs to our zammad-system:

Delayed::Job.count 24
Overview.count 19
User.count 597
User.joins(roles: :permissions).where(roles: { active: true }, permissions: { name: 'ticket.agent', active: true }).where.not(id: 1).count 8
Ticket.count 4048


Dienstag 6. Aug 16:11
aktualisierte Ticket state von 'open' bis 'pending reminder'
aktualisierte Ticket last_owner_update_at '2019-08-06 14:10:27 UTC'
aktualisierte Ticket pending_time '2019-10-01 06:00:00 UTC'
aktualisierte Ticket Besitzer von 'xxxxx xxxx' bis '-'
erstellt Artikel

Dienstag 1. Oktober 9:14
aktualisierte Ticket state von 'pending reminder' bis 'open'
aktualisierte Ticket last_owner_update_at '2019-10-01 07:14:24 UTC'
aktualisierte Ticket pending_time '2019-10-01 06:00:00 UTC'
aktualisierte Ticket update_diff_in_min '51'
aktualisierte Ticket first_response_diff_in_min '-103'
aktualisierte Ticket update_in_min '249'
aktualisierte Ticket escalation_at '2019-10-01 13:14:28 UTC'
aktualisierte Ticket first_response_escalation_at '2019-08-06 12:01:06 UTC'
aktualisierte Ticket update_escalation_at '2019-10-01 13:14:28 UTC'
aktualisierte Ticket first_response_in_min '223'

How come this phenomenon? That it took over 1 hour to reopen the ticket.

Please note that pending reminders -by default- do not reopen!
In front of the date within the History you’ll find the culprit that changed the state (or rather caused the battery of history entries). If it’s not “-”, it was not Zammad as system.

It’s possible that a pending action or pending reminder drifts up to 15 minutes.
Reason behind that is that this Job normally only runs every 15 minutes for performance reasons.

Edit: Above history clearly looks like an agent triggered answer.

Hi Mamoulian,

i know the problem you have… I’ve been dealing with the same one.
I’m about to test a new automation… You’re welcome to test it with me.

Greetings, Daniel.

A 15 minute delay would absolutly be ok.
Here is a screenshot of the history. The state changes were made from zammad, according to the user “-”

@Mr_P: So yo build a new automation to manually force the reopening of the tickets?
That’s an interessting point of view. I will discuss this with my collegues

Yeah, thats what i tried… Here was my first result of testing:

Here is a second test:

If you want a faster response, you can certainly do the automation every 10 minutes… But it probably goes a little bit to the performance.

Why aren’t you guys using a pending action?
Like pending close, just to reopen things?

Beside that, it’s really odd that you have about 1 hour delay here.
(you just got me with 3 hours difference, but two come from UTC to GMT+1 plus Summer time)

If you had a busy system around 8am, it’s possible that Zammad couldn’t keep up with ti’s task.

Hi @MrGeneration,

the thing is, if you have to replace defective hardware for example… Then we order it and put the ticket on “pending reminder”… If the hardware has not been delivered, we have to ask where it stays… The ticket can therefore not yet be put on “pending close”.

After “pending reminder” reached the reminder time, it should not stay in pending mode… Because its not pending anymore… Thats why we want it in open state after that.

PS: I also noticed the delay.

Sadly our zammad didn’t had a high performance peek at 8am.

If I understand you correctly, you suggest to write a small cron-script, which changes the state?

If you create a pending open pending action? :x
You can choose on rails, what the “destination state” will be :slight_smile:

Just as side note. All good if it works for you!

1 Like

No, not cron-based script intended. That’s horrible in terms of maintenance.

That sounds awesome and could be the easiest solution. :star_struck:

So you mean “next_state_id” set to “2” (in my case id: 2=open)?

Sorry, I don’t get you right.
Instead of a cron-based script, what do you advise to use?

Careful here, next state_id is for the datepicker :wink:

  name: 'pending and reopen',
  state_type: Ticket::StateType.find_by(name: 'pending action'),
  ignore_escalation: true,
  next_state: Ticket::State.find_by(name: 'open'),
  created_by_id: 1,
  updated_by_id: 1,

is already what you’re aiming for, I believe. :slight_smile:

My suggestion is to use native “pending actions” as states, further information on how to add those can be found here: Working with ticket information — Zammad System Documentation documentation

1 Like

This works fine with pending action (max 12min delay atm):

Thx for this hint @MrGeneration.

Finally, a short summary for @MamoulianDelacroix how I have now set it up with us:

  • Open Rails
  • Add a date and time picker
  • Make new states available to UI
  • Translate the new state into german language
  • Deactivate the old pending status if you don’t use it like I do
  • Maybe restart the system for clean bootup
  • In Browser adjust the views in Settings → Overviews where you want to see the new status.
  • That’s it… I wish a successful result.

Yours, Daniel.


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