osTicket not sending alert to Agent when user replies using Outlook.
You can also go here and dump the $autorespond and $alerts variables to see if either is false.
Cheers.
There is not in the case of my test. Both replies are replies to the same response from the agent. BUT: The first reply from the user was using Outlook and did not trigger an alert, while the second reply was 12 minutes later from Bluemail and it DID trigger an alert.
Thanks!!!
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!
- Edited
Apparently your changes are not correct as it’s logging the message and not the needed variables. By dump I meant a simple var_dump($alerts, $autorespond);. Then run the cron command manually via the server’s CLI so you can see the output.
Cheers.
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!
Yea, so now you need to track the $autorespond variable back to where it's being set to false. Then you will know what the cause is; likely the headers or something. If it's not something you can control then you would need to modify the codebase to your liking.
Cheers.
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
- Edited
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
- Edited
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.