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.