All tickets updated at the same time

Technical assistance
1

Infos:

  • Used Zammad version: 6.4.1
  • Used Zammad installation type: package
  • Operating system: ubuntu 22.04
  • Browser + version: firefox 133.0.3

Expected behavior:

  • for overviews I would like to be able to sort by updated at to see the newest updates

Actual behavior:

sometimes weekly, sometimes every two weeks there is some job that is running and updates all the ticket, so the overview looks like that:

grafik
grafik164×375 1.76 KB

In the log it looks like everything is sleeping during that time:

grafik
grafik1235×225 8.96 KB

Steps to reproduce the behavior:

  • I really cannot tell what has been configured to get this behaviour and I hope you have some additional ideas on where to look into this to check which job updates the tickets. I cannot find any cronjob that’s responsible for this behaviour. There is only a root crontab and no user crontab in the system.
2

I think you have an automation created?
Go to one of these tickets and click on the right top of „ticket“ and gehen „history“. Now you can See which task edited the ticket

3

Thank you, I didn’t know the possibility to check the history of a ticket. However the history shows this:

grafik
grafik674×550 35.6 KB

The last update should be 12.12.2024 10:39, however the overview shows updated at with another timestamp, but last contact with this timestamp:

grafik
grafik536×228 13.2 KB

Is there some other log where I can get the information what happens to change the updated at field?

Regards,
Andreas

4

Hey,

happy new Year!

Does somebody else has an idea where to check what changes all these tickets in combination? I would be really happy to figure this out.

Regards,
Andreas

5

This is most likely happening because of the new year in connection with configured SLAs.

Background information:
Once per day, usually at or around midnight, Zammad synchronizes its calendar. On New Year’s Day, new holidays are imported. With new holidays in the calendar, all tickets for which an SLA is configured, have to be recalculated. This is technically an update to the ticket, and is therefore shown as one on the UI.

6

Thank you for your answer. We see this behaviour since more than a half year now. So it’s not something in combination with the new year. However SLAs is a good hint. I’m not using my SLAs, so I turned that off. I’ll check if that helps.

Thank you.

7

Ah, sorry. My bad. I just saw the title, and in conjunction with the new year having just started, I assumed that it’s this known thing.

It’s still not unlikely that it’s the SLAs. One way to check this would be from the rails console with the following command:

Ticket.find(<ticket_id>).preferences

Where <ticket_id> should be replaced with the ticket-id of one of the tickets that show as updated. You can find the ticket-id by looking in the URL-bar of your browser when that ticket is openened. The number at the end (eg. the 123 in: #ticket/zoom/123) is the ticket-id.

Look for a key called "calendar_updated_at". If it corresponds with the update time that the UI is displaying for this ticket, then it’s most likely an SLA recalculation.

2 Likes
8

Indeed, it’s the calendar update:

grafik
grafik603×176 9.31 KB

15:35 UTC is my 16:35 or rounded 16:36 GMT+1, interesting. There should not be a calendar update every 1-2 weeks. I’ll wait for the next event, when that happens, or the SLA deletion turned that behaviour off.