Cerberus 4 "Available Tickets" count

[DavideGu]

Hello,

yes, I know Version 4.0 Stable (Build 809) is 15 years old, but I'll try to ask however, in the hope someone remembers how to fix a problem I already had once in 2009, but there was a different forum at that time and I can no more retrieve the solution.

I have Cerb4 installed on a remote Linux server and some days ago, I was replying to a ticket when the server suddenly restarted.
Since then I noticed that the "Available" bucket in Cerberus (in the left frame of Cerb4) was counting 1 ticket more than what was really available (so, for example, it counted 4 opened tickets while just 3 were listed in the Inbox)

When it happened in 2009 I remember I performed some manual commands in the MySQL DB, but I don't remember what I did exactly now (my fault, I should have written it down).

Is there someone here, as old as me, but with a better memory? :)

Thanks,
Davide

[Hildy]

With access to the helpdesk and the db, it'd probably be pretty easy to track down...

You'll want to do some SELECTing in the db to locate the odd ticket, using the same sort of filters as you're using in the GUI (e.g. group, status, etc). Once you've pinned it down, you can check the properties for maybe an invalid group_id/bucket_id.

[DavideGu]

Dear Hildy,
thank you very much for your kind reply, and for putting me in the right direction.
I'll try to play with it in the next few days and hopefully, something will return to my mind when doing it :)
Thanks again!
Davide

[jstanden]

Hi @DavideGu!

That's some impressive uptime on Cerb 4.0. 😅

Like Hildy, I suspect the server restarted when the database was creating a ticket. Since this code is from 15 years ago, it's much more likely you're using MyISAM tables in MySQL.

I don't have the 4.x database schema in front of me, but we do have a vestige. The query would be something like:

SELECT * FROM ticket WHERE team_id = 0 \G

If you can connect to the MySQL shell or use phpMyAdmin, run the above query to check.

If you find a ticket without a proper group, you can either mark it deleted (since it likely retried) or change its group to something valid.

UPDATE ticket SET team_id = 123 WHERE team_id = 0;

Where 123 is a valid ID from:

SELECT id, name FROM team ORDER by name;

It also wouldn't hurt to run myisamchk after an unexpected reboot to make sure you don't have any database table corruption.

Modern versions of Cerb fix orphaned data like this automatically. It's less common with MySQL/InnoDB, and wouldn't be an issue w/ transactions that auto-rollback if interrupted before they complete.

[DavideGu]

Hi Jeff,

thank you very much for your detailed reply.
I thought I marked this question as solved because I solved the problem the same day with the help of Hildy.

What I did exactly was:

SELECT * FROM 'ticket' where team_id=123 and is_closed=0;

and then

UPDATE 'ticket' SET 'is_deleted' = '1' WHERE 'ticket'.'id' = 123456;

I have now written down the procedure, should it happen again in another 15 years 😉

And, yes, I really love Cerb 4.0! ❤️

Thank you again!
Davide