KevinTheJedi

So here is what happens...

I attempted to put the code in there, and I would never get anything in the var_dump.txt file and I would no longer get agent alerts from the ticket responses, when appending "Testing123" to the subject...

So its possible that I might not have permissions properly set up for the var_dump.txt file, or I might not have formulated the filename properly within the put_contents function, however I don't think that is where the problem lies...

I think there is something wrong with the code, and when it attempts to evaluate what is in the "IF" statement there, because no matter what I do, I cannot get the agent to receive an alert as long as the code is in there, even when I do not put the Testing123 into the subject line (which should ostensibly mean that the code within the if statement should not fire, yes??)

I have done all this testing with my home account (the one that seemingly works)... When I email the ticket from that account (without any modification to the subject line), and the extra code present, I get a message confirmation email back (saying that my reply has been noted), however the agent does not get an alert anymore...

Whenever I remove the code, I get both a message confirmation back, and the agent does get an alert...

I will include a screenshot here of what the code looks like out of class.ticket.php

So anyhow, regardless of how I formulate the string for the var_dump file, that code should never be executed if there is no "Testing123" in the subject line anyhow, yet I am still getting no agent alert when the code is present, and always I am getting an agent alert when the code is absent...

I also attempted to modify the "$ticket->getSubject()" to "$this->getSubject()" (since that seems to be used in this file), but that didn't make any difference either...

Not sure exactly what I am doing wrong here, but seemingly the presence of this code might be causing an error (??)...

I included a screenshot above, does what I have there seem okay ??

@KevinTheJedi

Sorry Kevin, I think we cross-posted there...

To be clear, the testing I was doing was on my original test ticket (the one that generated the headers I provided earlier), so I did not create a new ticket (per your most recent post)...

I was using forward-slashes for the filename there, however like I mentioned, I was not even changing the subject line at all (not putting in the "Testing123") and just the presence of that code (under those conditions) was causing the agent not to receive an alert (from my home account, which works), and would always receive an alert when the code was absent...

So I think something is wrong and that code is throwing an error (even with the code not branching into the if statement)...

Is there something else wrong??

Perhaps if I create a video of me doing all of that it might make more sense?? Should I do that??

... Would you be willing to remote in here with me? That might make this easier too (I am good with whatever)...

KevinTheJedi

Okay, now we are getting somewhere

I replied to my test ticket from my (Home) account (the one that works), and I ran the cron manually... See the output below:

C:\Users\redacted>"C:\Program Files (x86)\PHP\v7.4\php.exe" C:\inetpub\wwwroot\Helpdesk\api\cron.php
string(9) "Subject: "
string(22) "Test ticket from yahoo"
string(8) "Poster: "
NULL
string(8) "Alerts: "
bool(true)
string(13) "Autorespond: "
bool(true)

So "Poster" is null? Can that be right?

KevinTheJedi

Yep, I see that I am still running php 7.4 for my automated cron job (when we should be running 8.0)... I need to fix that in my windows scheduled task...

However when running with php 8.0 I get the same thing (doesn't matter)...

C:\>"C:\Program Files (x86)\PHP\v8.0\php.exe" C:\inetpub\wwwroot\Helpdesk\api\cron.php
string(9) "Subject: "
string(22) "Test ticket from yahoo"
string(8) "Poster: "
NULL
string(8) "Alerts: "
bool(true)
string(13) "Autorespond: "
bool(true)

KevinTheJedi

Also, when I send a reply in from my yahoo account, I get no output from running the cron job from the command prompt... Nothing at all.. And I get no agent alert or confirmation response back to yahoo..

... Yet the reply does seem to process into the ticket ... I can see it there in the portal ...

So it looks like this code is never hit, when I reply from my yahoo account (but is hit when I reply from my home account)... And it looks like the email is being processed for the ticket ...

Is that helpful??

... Again, I appreciate this so much, thank you!

Oye, it seems I must have hit some kind of posting limit, and now my most recent posts are "awaiting approval"....

Anyhow, hopefully you will be able to see my posts...

And to be clear, when I did get the output back, when I posted from my home account, I did get the agent alert and the message confirmation... So that did work...

I got no output when replying from the yahoo mail user, and did not get the agent alert or the message confirmation...

KevinTheJedi

Okay,

So I have done a lot of digging into the postMessage function, and after many var_dumps and emails going back and forth, I discovered that the issue boils down to the $vars being passed into the function with $vars['autorespond'] set to true on some emails replies coming in, and $vars['autorespond'] set to false on others…

I can prove this because at the very top of the function I put this line:

var_dump('VarsAutoRespondAtTop:', isset($vars['autorespond']) ? $vars['autorespond'] : 'Autorespond var not set');

and when running the cron job manually at a command prompt, I would get true or false depending on where the email reply was coming from… (vars[‘autorespond’] was always set, I would never get “var not set” from that)…

… Now earlier, I mentioned that the yahoo mails coming in were not showing anything in the output… Somehow, when I was working with it later in the night, the yahoo mails WERE showing output… I think what might have been happening is that even though I turned off the chron job (or the Windows scheduled task), the helpdesk was still seeing activity from the other member in our support group. Because of that, I think emails were still being fetched (because of the activity?), and it was (I guess) perfectly correlated with when I was testing yahoo mail and when I was testing my home mail … At least that is what I think was going on because when I was testing this off-hours I was getting responses from the var_dumps each time I sent in an email…

One other thing about the home mail…. I have several portals for that email, I can use my Thunderbird email client, or I can use the email client on my cell phone, or the zoho web mail portal for my account… So when I reply to a helpdesk email from the Thunderbird client or my email client off my cell phone, I would get agent alerts every time… When I reply to a helpdesk email from the zoho web mail portal, I would not get an agent reply every time…. So, even from the same email account, just the email client I am using does seem to make a difference… I must have tested this at least 10 times from each client, replying to the same exact agent response email, and I get the same results every time… And, of course, email responses generating from the yahoo web mail client, or the gmail web mail client, never result in an agent alert in any of the tests…

Anyhow, I spent a while testing var_dumps for everything, in and around the area of code we were testing before, and I found that after this code is run:

        $reopen = $autorespond; // Do not reopen bounces
        if ($autorespond && $message->isBounceOrAutoReply())
            $autorespond = $reopen= false;
        elseif ($autorespond && isset($vars['autorespond']))
            $autorespond = $vars['autorespond'];

The $autorespond would show true or false depending on the email source… Then I narrowed it down to the $vars['autorespond']; , and from there I noticed that the function was just being passed the vars set that way right in the vars parameter to the function… (the IsBounceOrAutoReply would always return “False” in all my tests, so that is not the issue here)..

Anyhow, clearly there is something going on with emails depending on the source and client being used to make the replies… I don’t know if this can be found in the headers, or somewhere else, and from here I am not sure where to go…

The good news here, I think, is that I can finally narrow the issue down to some very specific circumstances… Before it all seemed kind of random and we would sometimes get alerts and sometimes not, and this drove us crazy… Now I can reliably reproduce the issue and I get the same results every time I take certain actions.. Also, I think I know (at least in a general sense) where in the PHP code this issue lies, even though I have no idea what to check for next or how to fix it…

This is a lot more than I knew just yesterday…

So what do you think??

If you would like, I can send you headers again, except this time from the same email account (just from different portals), as we are getting different results depending on the portal… Would that be helpful??

@KevinTheJedi

Hello Kevin,

.. Or for anyone else that comes across this ...

So what I did was I commented out some of the code in /include/class.ticket.php so it would ignore the value in $vars['autorespond']... So my code there looks like this:

        $reopen = $autorespond; // Do not reopen bounces
        if ($autorespond && $message->isBounceOrAutoReply())
            $autorespond = $reopen= false;
        //elseif ($autorespond && isset($vars['autorespond']))
        //    $autorespond = $vars['autorespond'];

And did some more testing, and indeed now I am getting agent alerts from ticket replies from all of my accounts (yahoo, gmail, personal email via all portals, etc..).... Hopefully this will translate into alerts for all of our other helpdesk replies as well (I don't see why it shouldn't)...

So removing that check does help the issue... Although this really isn't a fix, its more like I am just masking the symptoms here and creating more risk and side effects... I'm guessing that probably puts me at a higher risk of an auto-respond infinite loop of ping-ponging emails... We have had that happen to us before, a few times, with Spiceworks... It was not pretty...

How much of a risk is it really?? It seems there are other catches in the code for that sort of thing...

Anyhow, I hope all is well.. I also hope that those headers I provided are at least somewhat helpful (are they?), and I would be happy to provide more if that would help..

Thanks much ....
...

So, put another way, would the following be a legitimate fix for OSTicket, in class.thread , line 465:

From:

        $vars = array(
            'mid' =>    $mailinfo['mid'],
            'header' => $mailinfo['header'],
            'poster' => $mailinfo['name'],
            'origin' => 'Email',
            'source' => 'Email',
            'ip' =>     '',
            'reply_to' => $entry,
            'recipients' => $mailinfo['recipients'],
            'thread_entry_recipients' => $mailinfo['thread_entry_recipients'],
            'to-email-id' => $mailinfo['to-email-id'],
            'autorespond' => !isset($mailinfo['passive']),
        );

To:

        $vars = array(
            'mid' =>    $mailinfo['mid'],
            'header' => $mailinfo['header'],
            'poster' => $mailinfo['name'],
            'origin' => 'Email',
            'source' => 'Email',
            'ip' =>     '',
            'reply_to' => $entry,
            'recipients' => $mailinfo['recipients'],
            'thread_entry_recipients' => $mailinfo['thread_entry_recipients'],
            'to-email-id' => $mailinfo['to-email-id'],
            'autorespond' => ((!isset($mailinfo['passive']))  || (isset($mailinfo['passive']) && ($mailinfo['passive']))) ,
        );

So doing that seems to fix the problem (and the 2-line comment-out workaround is no longer needed)....

So what we are doing is checking if "passive" is set. IF not set, then set autorespond to true, and if it is actually set, then set autorespond to the true/false value of "passive"...

However is this a legitimate fix to OSTicket to solve this problem, and should be submitted to the source code repository?? Or does this break your intended purpose for the "passive" / "autorespond" flag ??

Seems reasonable to me, however I don't know what the real intention of "passive" here is...

... Anyhow, if this is legitimate, can we use that fix for future versions ?

@KevinTheJedi

Okay, so if that is the case, then really the fix belongs somewhere here:

class.thread.php -> lookupByEmailHeaders -> Line 1490

        // Passive threading - listen mode
        if (count($possibles)
                && ($entry = ThreadEntry::objects()
                    ->filter(array('email_info__mid__in' => array_map(
                        function ($a) { return "<$a>"; },
                    $possibles)))
                    ->first()
                )
         ) {
            $mailinfo['passive'] = true;
            return $entry;
        }

... Because incoming emails that are evaluated sometimes hit this logic when lookupByEmailHeaders is called, but lookupByEmailHeaders is not called on every email...

When lookupByEmailHeaders is not called, then passive is not set, and so we don't have a problem (autorespond will evaluate to true).

When lookupByEmailHeaders is called, then passive is set here (seemingly every time, at least every time I have tested web based email clients so far), and the agent alerts do not go out.

... So I am trying to evaluate what is happening with that conditional logic there, and I think that is where I get a little stuck (I just cannot follow what it is doing there) ....

So what if I did a variable dump of $possibles, and $entry, and $mailinfo right before the return $entry, for web-based emails that fall into this conditional, and submitted that, would that be enough to figure out what is happening here for these emails??

Emails that work (do trigger an agent alert) never fall into this code because lookupByEmailHeaders is never called to begin with (and so passive is never set)... Is that a problem too??

... Thanks much