List all the records in the _ticket table and order by created date. Also, don’t have a field on any form with the variable name of “number”?
Cheers.
osTicket issues with incoming tickets
Kevin,
could the problem be that our mail server is configured to be UTC+1 but the support ticket system server is configured to be UTC+0 ?
There's no way we can change either of them, so I am curious as to why this might be causing issues...
OK - thank you for that - it should help clear the confusion that way.
The other thing I've noticed is that when auto-cron sweeps through incoming support emails, the tickets are generated with the wrong number (thus causing the issue), whereby if the incoming support emails are swept because of agent action on the web page, the tickets are generated correctly.
Would that help you in getting an aha! moment?
I'm confused...auto-cron is triggered by Agent activity so both instances would be the result of the Agents' activities. Do you mean you have a Cron Job/Scheduled Task configured and running?
Cheers.
- Edited
yes - correct, I am sorry, that's what I meant - there is a cron job configured to sweep incoming support emails as follows:
5 * * * * /usr/bin/php /home/www/support/api/cron.php
The auto-cron triggered by Agent activity works correctly.
The cron job in crontab causes the issue.
(apologies for confusing you)
When you run /usr/bin/php --version on the server does it match the version of PHP your system is running?
Cheers.
Hi Kevin,
this is the output of /usr/bin/php --version:
PHP 8.2.26 (cli) (built: Nov 25 2024 17:21:51) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.26, Copyright (c) Zend Technologies
with Zend OPcache v8.2.26, Copyright (c), by Zend Technologies
and this is what osTicket is reporting. They seem identical.
- Edited
Sure. Here you go:
an example of a ticket generated by the cron job (the BAD one)
The login location is: https://support.domain.tld/scp/tickets.php?id=19449 (NOTE THE ID HERE).
An example of a ticket generated by an auto-cron action generated by an agent working on the support site (a GOOD one)
The login URL: https://support.domain.tld/scp/tickets.php?id=19477 (note the ID here).
And the mysql data entries for the two IDs above:
Headers:
19449:
19477:
What's very confusing to me is why, even though I've gone into Ticket Settings and Options and selected a SERIAL numbering of default ticket number sequence, it still picks random numbers when using the system cron-generated email sweep. You can see above, if it's a result of any of our agents' actions, the numbering is in order (000001, 000002, etc). where as if it's because of the cron, it goes at random.
Here are the settings:
It sounds like the Tickets fetched using cron are going to a specific Help Topic that has a separate Ticket Number Sequence. Check the New Ticket Options for the Help Topic of a Ticket that was created from fetch via cron.
Cheers.
Thank you Kevin,
we'll give this a try.
Do you suggest we keep the ticket number sequence identical for all help topics then?
That’s up to you. I’m just explaining a potential reason for why the numbers are different.
With this being said it wouldn’t explain why the database shows a different number than the email. What does your email template look like? If you have multiple what do they all look like? Have you checked all of your forms to see if any field has a variable name of “number”? If so that will interfere with the real ticket number in the emails.
Cheers.
- Edited
One of our forms is this:
Will that interfere?
EDIT: You said "variable name" - no, it doesn't and none do, that I checked.
What does your email template look like? If you have multiple what do they all look like?
Like this - if I am understanding you properly... :
the issue at this time is that when a customer replies by email to an agent's answer, the cron job generates a new ticket rather than attaching the response as a new message - and the new ticket's number is incorrect (refers to old tickets but it's not added as a new message to that either).
If it's creating a new ticket then either the user is sending a new email (ie. instead of clicking Reply All they type a new email which causes the mail header references/in-reply-to is stripped/changed) or the ticket they are replying to is set to a closed status that doesn't allow reopen.
Cheers.
And no, I mean click the actual New Ticket Auto-Response template and view the actual contents.
Cheers.
KevinTheJedi
Here you go:
