UI state consistency issue with triggers

First of all, great work with Zammad!

I’m using Zammad 4.1.0 and ran into an issue when using triggers for my use case:

We have agents that rotate shifts and customer responses may overlap shifts but will still need attention from the next shift even if a previous shift made the initial response. To avoid tickets sitting in the queue of an agent that might be offline/off-duty, I’ve set up the following flow:

  1. Enabled auto-assign to ensure the agent that responds is the initial owner of the ticket
  2. Created a new boolean attribute for tickets called “is_closed”
  3. Created a trigger to set that boolean to true automatically when an agent closes the ticket (they’ll be instructed to close all of their open tickets before logging off)
  4. Created another trigger that checks for open tickets with the is_closed boolean set to true and automatically unassign the previous owner while resetting the is_closed boolean so that a new owner can take it on.

Expected behavior:
The UI should automatically reflect the correct status and owner information

Actual behavior:
After a ticket is closed by an agent and the customer responds again, the ticket appears in the “Unassigned and Open” section but the owner and state reflect the old values. When the page is manually refreshed, the UI state is corrected.

I’ve attached a screenshot of the inconsistent state:

That’s not how auto assignment functionality works!
Owner ship is assigned right upon opening an unassigned ticket:

In case that’s what you talked about.

Okay… why?

First things first:
Triggers only fire upon ticket updated. This means your checking trigger will only fire upon updating the ticket by e.g. any agent or customer. The following page may help you to understand the trigger scope better: Limitations — Zammad documentation

To your initial goal:
You basically want to ensure that assigned tickets are unassigned if they’re not closed allowing to have the following shift to continue working on the ticket. Zammad has a “assignment timeout” that’s group based that does exactly this job.

This page may help to understand this better:

EDIT: Problem solved, thank you very much!

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