Delayed change of ticket state

[MamoulianDelacroix]

Hi everyone :

Infos:

• 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

Ticket-history:

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.

[MrGeneration]

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.

[Mr_P]

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.

[MamoulianDelacroix]

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 “-”

[MamoulianDelacroix]

@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

[Mr_P]

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.

[MrGeneration]

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

https://docs.zammad.org/en/latest/console/working-on-tickets.html#pending-action

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.

[Mr_P]

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.

[MamoulianDelacroix]

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?

[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”.

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

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

[MrGeneration]

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

[Mr_P]

You can choose on rails, what the “destination state” will be

That sounds awesome and could be the easiest solution.

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

[MamoulianDelacroix]

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

[MrGeneration]

That sounds awesome and could be the easiest solution.

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

Careful here, next state_id is for the datepicker

 Ticket::State.create_or_update(
  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.

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

My suggestion is to use native “pending actions” as states, further information on how to add those can be found here: https://docs.zammad.org/en/latest/console/working-on-tickets.html#pending-action

[Mr_P]

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

zammad run rails c

• Add new state like @MrGeneration has described

Ticket::State.create_or_update( 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, )

• Add a date and time picker

attribute = ObjectManager::Attribute.get(
  object: 'Ticket',
  name: 'pending_time',
)
attribute.data_option[:required_if][:state_id] = Ticket::State.by_category(:pending).pluck(:id)
attribute.data_option[:shown_if][:state_id] = Ticket::State.by_category(:pending).pluck(:id)
attribute.save!

• Make new states available to UI

attribute = ObjectManager::Attribute.get(
  object: 'Ticket',
  name: 'state_id',
)
attribute.data_option[:filter] = Ticket::State.by_category(:viewable).pluck(:id)
attribute.screens[:create_middle]['ticket.agent'][:filter] = Ticket::State.by_category(:viewable_agent_new).pluck(:id)
attribute.screens[:create_middle]['ticket.customer'][:filter] = Ticket::State.by_category(:viewable_customer_new).pluck(:id)
attribute.screens[:edit]['ticket.agent'][:filter] = Ticket::State.by_category(:viewable_agent_new).pluck(:id)
attribute.screens[:edit]['ticket.customer'][:filter] = Ticket::State.by_category(:viewable_customer_edit).pluck(:id)
attribute.save!

• Translate the new state into german language

Translation.create_if_not_exists( :locale => 'de-de', :source => "pending and reopen", :target => "warten auf Erinnerung", format: 'string', created_by_id: 1, updated_by_id: 1 )

• Deactivate the old pending status if you don’t use it like I do

Ticket::State.create_or_update(name: 'pending reminder', active: false, )

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