Support

This makes no sense. The code which sends the email is triggered by a built-in event hook in the ticket object's save handler. It doesn't matter how you save a new ticket – web, email, or creating it with a CLI script.

Is it possible that the difference is that tickets received over email are handled by a CLI script which runs under a different PHP version (or at least a different PHP configuration) which might prevent emails from being sent?

I am afraid this is definitely not an issue with ATS 5.4.2 and / or Joomla 5.4.1. I just tested that exact configuration and I get the emails just fine when I send a ticket through email AND when I send a ticket through the web. This was completely expected. As I explained, the mail sending code is actually triggered by the Table object. It does not care where it's called from. That's the whole point of using the Model-View-Controller architecture in Joomla: there's a single point in the code which handles things instead of copying code all over the place and struggle to keep it up-to-date with each other.

I can also tell you it's not an issue with your mail templates. If it was missing, you'd not be getting any email regardless of how you send the ticket. Likewise, it's not a problem with your ATS configuration.

This brings us back to how you send emails and how you run mailfetch. If you are not using SMTP (e.g. using a third party plugin) it could be failing under CLI but work on the web. If you are running mailfetch under CLI there might be a configuration difference, OR there might be a third party plugin throwing an error when you try to send an email from CLI; do remember that Joomla 5 and later versions do have two plugin events which are triggered when you send an email through Joomla.

If you are using wget your issue makes a lot less sense than it made originally, and I have to note that it did not make any sense to begin with. I would also like to note that did try to reproduce your issue yesterday, but I was receiving the email just fine no matter how the ticket was submitted, and whether the mail fetch was running from CLI, or a Joomla Scheduled Task (therefore the web, the same as using wget for all practical intents and purposes since it's the Joomla application that matters in this case, not what loaded it).

At this point, I am thinking that your issue description may have been unintentionally misleading, e.g. because the people you asked had in their mind emails they received about tickets before the update was installed. So, I am going to disregard that part of your issue description and treat it as "suddenly" not receiving any email for submitted tickets.

I am also noting that based on your past tickets you did have 5.4.1 installed and working fine, so I am focusing only on the changes between 5.4.1 and 5.4.2. I am also noting that Joomla 5.4.1 introduced no changes which could affect anything, let alone email sending. The x.4 releases of every major Joomla release starting with 4.4 are extremely conservative, only addressing security issues and major bugs. They are the LTS version. Breakage can and does happen in the x.0 (guaranteed breakage), x.1, x.2, and to a lesser extent x.3 versions.

With that in mind, the only thing I can possibly think of is this change in 5.4.2:

Notify Support Staff option in ticket category is effectively ignored

Is it possible that you had misconfigured who gets emailed about new tickets, but because this setting was ignored everyone was receiving email just fine?

Do note that this is incongruent with your original issue description where you stated that tickets submitted over the web do result in emails being sent.

As for troubleshooting email sending, I have bad news for you. Since we just use Joomla's mail templates there's nothing for us to log. Joomla itself doesn't keep any email logs either. Beyond looking at your mail server logs for sent emails and your web server's error logs for any PHP errors there's nothing else you can possibly look at.

Let's talk code, since what you are saying makes no sense.

Sending a new ticket over the web

The form is submitted to ATS' ticket controller using the save task. This calls \Akeeba\Component\ATS\Site\Controller\TicketController::save().

Since \Akeeba\Component\ATS\Site\Controller\TicketController extends \Akeeba\Component\ATS\Administrator\Controller\TicketController and the Site version of the TicketController does not override the save() method we end up calling \Akeeba\Component\ATS\Administrator\Controller\TicketController::save().

This method calls the \Akeeba\Component\ATS\Administrator\Controller\PostController::post which calls \Akeeba\Component\ATS\Administrator\Controller\PostController::postSaveHook which calls \Akeeba\Component\ATS\Administrator\Mixin\ControllerNewPostTrait::postNotifiable which sends the email by doing 

(new EmailSending())->sendPostEmails($post, $ticket, $newPost);

What does this mean

As you may have spotted above, regardless of the way the new ticket is created, you always get to run the same piece of code: the \Akeeba\Component\ATS\Administrator\Mixin\ControllerNewPostTrait::postNotifiable() method.

Note: This is not a new thing! This exact code structure was introduced in 5.0.0 back in December 2021. Before that, the respective controller methods were calling a plugin event which was still running the same code whenever you submit a new ticket or reply ever since version 0.0.1 back in 2010. There was never code duplication when sending emails. Using the exact same piece of code, appearing once in the code base, is a fundamental principle of software engineering called DRY (Don't Repeat Yourself), one which I took to heart decades ago. But I digress.

You can read the code for the aforementioned method in administrator/components/com_ats/src/Mixin/ControllerNewPostTrait.php lines 135 to 177. All this method does is basically instantiate the \Akeeba\Component\ATS\Administrator\Model\EmailSending model and call its sendPostEmails() method.

As you can see in administrator/components/com_ats/src/Model/EmailSending.php this code does NOT care where it was called from, i.e. it doesn't care if the ticket is created over the web, from an email, or from custom code running in any way (plugin, module, component, frontend, backend, CLI, API, whatever). It always figures out which email template to use, applies the support staff (manager) user filtering options in the category, and uses Joomla's Mail Templates feature to send the email. Then, it sends the email to the ticket owner when necessary (new ticket, reply from someone other than the ticket owner himself).

Likewise, Joomla does not care how or where from you call its Mail Templates feature. It will try to send the mail using Joomla's configured mailer regardless. The mailer is configured from your Global Configuration which, again, is the same regardless of which Joomla application (frontend, backend, API, CLI) you are using.

As I said, sendPostEmails() first processes manager users, then sends the email to the ticket owner (if it is a new ticket or the post was created by a user other than the ticket owner). This tells me, and should also tell you, that since your ticket owner receives the email both times, this entire email sending code has executed both times, web and email ticket alike. Therefore, the problem does NOT come from our code.

Since your mailfetch runs from the web we can also eliminate any possibility that the problem may stem from differences between web and CLI. For example, if you are trying to send email through a Microsoft 365 account you need a connector plugin as Joomla's default SMTP handler can't operate with Microsoft's XOAUTH2 authentication scheme, and I know that some of these connector plugins are badly written and won't work under CLI. But you have told me this possibility is eliminated.

Moreover, I would like to remind you that I did test new ticket submission over the web and email, and even tested email fetching using different methods (CLI, web, and Joomla Scheduled Task running over the web for good measure). No problems with any of these tests. If you were using Joomla Scheduled Tasks over CLI to fetch the email I could think of a possible issue (the task notification system plugin in Joomla breaks under CLI, causing issues when running scheduled tasks under the CLI until you remove it), however unlikely it is that you are operating under these conditions. But since you told me that the client always receives the email I have to also eliminate this possibilty, as this issue would result in nobody getting an email notification.

Which is to say, what you are telling me here is an impossibility. The only explanation is that your web server or mail server drops emails for reasons unknown, or you are not using the same user and category for your web and email tests (which would bring us back to a possible configuration issue). What I can tell you is that given all the information you have provided, this issue cannot be reproduced and cannot possibly come from our code. Now that I have explained the code flow you're welcome to try debugging it yourself if you'd like. I have already spent more than five hours chasing this particular windmill and I'm unlikely to continue doing so.