I consulted a colleague who knows about pHp programming and we are not 100% if this is what you mean with dump, but this is what we added in class.ticket.php after line 3195 :

$ticket->onMessage($message, ($autorespond && $alerts), $reopen); //must be called b4 sending alerts to staff.
// debug alerts by c
$log = sprintf(__('debug message: %s'), $message);
$ost->logDebug(
sprintf( __('debug autorespond: %s'), $autorespond),
$log
);
$ost->logDebug(
sprintf( __('debug alerts: %s'), $alerts),
$log
);

Which caused these two entries in the log:

By the looks of it those variables seem to carry other data than just true or false.

Thanks again!

We now inserted var_dump($alerts, $autorespond); as you wrote and ran the cron manually which gave this output:
(when the reply from user was sent from Outlook email client which does not trigger an alert to the agent as stated before)

$ sudo php ./cron.php
bool(true)
bool(false)
So it seems that alerts=true, autorespond=false.

Then we ran the cron again after sending an email reply from user from Bluemail on Android phone to the same ticket, which does trigger an alert to the agent, and in this case the output was:

Both replies (the first one using Outlook, 2nd one using Bluemail) were replies to the exact same response email sent from osTicket to the user. Only the 2nd reply using Bluemail caused the alert to be sent.
I'm really wondering if something in the email header coming from Outlook messes things up. The thing is, I have no control over what email client customers are using. Most of them do use Outlook I'm afraid.

Any ideas? Many thanks!

We have already debugged the codepieces lines 3186-3193 and our conclusion is that $vars['autorespond'] must be gotten set to false somewhere but we have no clue where and why.
We did not have this issue in the old v.1.09 osTicket so I'm wondering if there is a bug, also since I've seen many other entries in the forum complaining no alerts are getting sent out to agents for unknown reasons?

Many thanks, Hans

When I close the ticket and then have the user send a reply from outlook, the ticket even gets re-opened and reply is inserted in the ticket but no alert to agent.

After commenting out lines 3191 and 3192 osTicket is sending alerts to agents regardless if reply was sent using the Outlook email client.

elseif ($autorespond && isset($vars['autorespond']))
$autorespond = $vars['autorespond'];
In the entire code I cannot find anything that sets $vars['autorespond'] to false. Some hints about in which direction I should be searching would be appreciated, as to what mechanism sets it.

BTW I found another thread where more or less the same issue is being discussed around 2 yrs ago.
https://forum.osticket.com/d/100969-osticket-intermittently-alerts-assigned-user/38

Thanks!

More searching delivered:

which is where $vars['autorespond'] is set to NOT isset($mailinfo['passive']).

And @mailinfo['passive'] is set here:

Unfortunately I have no idea how this further works and what it means. But apparently there is something with this passive threading thingy.

Hope this rings a bell for you. I've seen a similar Forum entry that is talking about the same, I believe.

Cheers, Hans

What is the use of silently threading through received emails into a ticket, hence, accepting it because the system found a way to match it, but then not alert the agent?

I did edit the email addresses in the headers to something rubbish as to not publish our email addresses here in the forum. I think I mentioned that when I posted the headers.

In the daily operation, since we cannot fetch emails from our Office 365 email account to which our customers are replying, we have configured a redirect from that O365 account redirecting the emails to a gmail address. osTicket is fetching the emails from that gmail address with IMAP using an app password for authentication. This has worked for two years using the old osTicket 1.09. Since we updated to 1.18 it is still working but we're having these alert issues now.

During the testing, I tried replying back to our support email address on O365 as well as replying directly to the gmail address. In both cases. the replies sent from a live.nl email address. The ones sent using Outlook land in the ticket but do not cause an alert, the ones sent from Bluemail app from the same email address land in osTicket and do cause an alert.

Do you believe the issue is that the fetching happens from a different email address than the address on which the emails are actually received from the customers? Is ost1.18 behaving differently from ost1.09?

I'm also wondering: We have configured the email accounts as follows. In the account settings page, we entered the original email address which is the outgoing email address for our responses and the address to which customers reply. Basically our one and only support email address that the world knows about. However in the Remote Mailbox tab for that address we configured the Gmail box settings from where the replies are being fetched. We had it like this for the past two years and it always worked. Could it be that osT1.18 has a problem with that? Maybe I should split this and make two email account entries, one for the "outgoing" (O365 email address) and one for the "incoming" (Gmail).

Thansk for your advise! Cheers, Hans