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.
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:
KevinTheJedi
I understood what you meant and I ran this test myself with a ticket I sent to support@ by my own test email account. It works properly if I send it and it gets inserted to the ticket system as a result of an Auto-Cron (agent action on the web site) but it gets the bad message number if the cron.php system picks it up and inserts it as a result of crontab action (set to run every 5 minutes automatically on the linux box).
what is different between Auto-Cron and the /usr/bin/php /home/www/support/api/cron.php ran by crontab?
What is Auto-Cron executing instead and why does that work OK?
There should be virtually no difference which is what's super odd here; or maybe you aren't explaining the issue well or I'm just not understanding you correctly. Anyways, the only difference would be either location of files (like maybe you have multiple installs or something) or maybe the user executing the scripts. So the web-based auto-cron should be executing as the webserver/php-fpm user and the cron would be executing as whatever user you created the cron under or the user you set for the cron specifically (which from your example you don't have one explicitly set).
Auto Cron Execution:
Cron Execution:
LocalApiController::call()new LocalCronApiController('cli')->run()Cron::run()self::MailFetcher()Cron::MailFetcher())As you can see, in the end they both call Cron::MailFetcher() so there is no difference here code-wise.
Cheers.
Thank you for all your assistance, Kevin.
We figured it out - it was another cron instance that was also pulling tickets, causing this to crap out. It was VERY confusing and did not appear in the logs anywhere.