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.
Once you find where it's being set to false we can better look into this. Since I can't replicate this I need an example to go on.
Cheers.
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
Ah, yes. So "passive" means passive threading. Passive threading occurs when the system couldn't find a References header, In-Reply-To header, Message-ID header, or Message-ID in the body of the email that was generated by the helpdesk itself (ie. one that it was able to decode). However it could find one of those headers that matches an existing thread entry in the database so the system will silently thread it through. osTicket will only send alerts when one of the aforementioned headers contain a header it can decode (ie. one that was sent by the system). This is why I originally asked if they are responding to one of their previous emails vs an email sent from an Agent or an alert from the system; as this matters greatly.
But what's weird is that in your header examples above for the one that does work I don't see a header that the system would be able to decode so I'm not sure how that one is working. Are you certain you didn't modify the header examples above? Like change an email for a different one or change some of the references, etc.?
Cheers.
Well, in all my testing, replies from user were a direct reply to the last response sent by agent from osTicket and our real customers are doing so as well, yet our agents hardly get alerts about such replies.
In the scenario where they do not reply to the ticket-response, but to their original email that "generated the ticket" for each of such replies a new ticket is created because the ticket# is not in the subject line. But that is acceptable and understandable. But that is not the scenario that is causing us headaches now.
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?
In the scenario where they do not reply to the ticket-response, but to their original email that "generated the ticket" for each of such replies a new ticket is created because the ticket# is not in the subject line.
That shouldn't be the case either as it should passively thread in that case as the In-Reply-To/References headers should contain the original Message-ID that they are replying to which would be found when doing the mid lookup referenced above.
Please answer my earlier question to help me better understand your situation:
But what's weird is that in your header examples above for the one that does work I don't see a header that the system would be able to decode so I'm not sure how that one is working. Are you certain you didn't modify the header examples above? Like change an email for a different one or change some of the references, etc.?
Are you doing any forwarding or anything? Or is the address the user sends mail to the very same address that's configured in osTicket to be fetched from?
Cheers.
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
I would simply add the other email address (the fetching one) as a system email without configuring anything. This way the system can look it up and recognize it as a system email and will potentially enable the use of alerts.
And of course the latest v1.18.1 is drastically different than v1.9.x as that was released 10 whole years ago lol
Cheers.
