osTicket issues with incoming tickets

KevinTheJedi

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.

lkalam

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...

KevinTheJedi

lkalam

Mailserver timezone should never have any ramifications.

Cheers.

lkalam

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?

KevinTheJedi

lkalam

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.

lkalam

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)

KevinTheJedi

lkalam

When you run /usr/bin/php --version on the server does it match the version of PHP your system is running?

Cheers.

lkalam

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.

KevinTheJedi

lkalam

Can you show me screenshots of examples of what you are talking about?

Cheers.

lkalam

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:

lkalam

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:

KevinTheJedi

lkalam

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.

lkalam

Thank you Kevin,
we'll give this a try.

Do you suggest we keep the ticket number sequence identical for all help topics then?

KevinTheJedi

lkalam

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.

lkalam

One of our forms is this:

Will that interfere?

EDIT: You said "variable name" - no, it doesn't and none do, that I checked.

KevinTheJedi

lkalam

What does your email template look like? If you have multiple what do they all look like?

lkalam

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).

KevinTheJedi

lkalam

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.

KevinTheJedi

lkalam

And no, I mean click the actual New Ticket Auto-Response template and view the actual contents.

Cheers.

lkalam

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?

lkalam

KevinTheJedi
Here you go: