Oauth2 email going into wrong department

KevinTheJedi

Everyone,

This bug has been fixed:

https://github.com/osTicket/osTicket/pull/6400

You shouldn’t have to add the aliases anymore after applying the above fix. Please note this will be included in the next release.

Cheers.

Crashdown

KevinTheJedi
I've tried out this fix but it does not seem to work for us, our case may be different with the issue we are having. A helpdesk email is a member of a distribution list email. Previously when sending to that distribution list email it would take the tickets in fine to that specific email and department but after the 1.17.2 update it is still happening to where it just goes to the default helpdesk email instead.

KevinTheJedi

Crashdown

Then you probably don't have a Department set on the email it's being fetched from in the email's settings in the Admin Panel.

Cheers.

Crashdown

KevinTheJedi
Thanks for the reply. The department is already setup on the email.

Essentially how it worked before

ABCDistribution@company.com which is not setup as a helpdesk email but a distribution list email with members of member1@company.com, member2@company.com, ABCHelpdesk@company.com <-- that one is a helpdesk email.

Before update

Person1 sends email to ABCDistribution@company.com
ABCHelpdesk@company.com receives email and creates ticket with the department and help topic for ABCHelpdesk as defined in the admin settings for the email.

After the update

Person1 sends email to ABCDistribution@company.com
DefaultHelpdesk@company.com creates ticket with the department of DefaultHelpdesk

KevinTheJedi

Crashdown

That is strange, the fix I posted above should address this:

https://github.com/osTicket/osTicket/pull/6400

The pull above is supposed to merge the data and defaults pulled from the email, filters, etc. and merge them with the defaults from the email's configurations. So if it’s being changed to system default I suspect you have other settings that are changing it. Or maybe their is still a lingering bug; I can try to replicate to see.

Cheers.

KevinTheJedi

Crashdown

Coming back to this, we just had this issue in the hosted platform, I applied the patch, retested, and issue resolved. So either you didn't apply the patch correctly or something is up with your codebase.

Cheers.

Crashdown

KevinTheJedi
Thanks for the followup. I've had a little more time to test and am just using a separate testing install now so I am not messing with our Production. I've applied the patch, tried just editing the code as stated as well as just replacing the files outright with the entire files listed there in the link and neither fixed the issue. Still goes to the default department.

In doing this I've noticed the files are a bit different between the posted 1.17.2 class.mailfetch.php and api.tickets.php and the one listed in pull 6400 which is why I tested just replacing the file outright with what is posted there as well. Are there other files that we also need to modify?

Thanks

KevinTheJedi

Crashdown

Ahhh that could be a problem. Simply make only the changes needed. Restore the files to v1.17.2, apply only the needed changes (do not replace the whole file), and retest.

Cheers.

Crashdown

KevinTheJedi That was what I tried first and that did not work so then I only tried the other method of file replacement just in case but again did not work.

KevinTheJedi

Crashdown

Then I would just wait for next release. Seems you are having other issues.

Cheers.

pitrickzul

hi,

im having this issue too now, just upgraded to 17.2 and configured my oauth2 for 1 of my emails (i have 3).

email1 -default
email2
email3

if you send an email to email2, you get the reply from email1. The ticket itself is in the correct department.

i applied the merge above and it's still the same.

KevinTheJedi

pitrickzul

With the patch referenced above I am no longer experiencing the issue. So either you didn't apply the patch correctly, or there is a separate issue.

Cheers.

KevinTheJedi

pitrickzul

if you send an email to email2, you get the reply from email1.

Wait, this sounds like a completely separate issue. This issue is when the Ticket is created it goes to the default department. You said yours is in the correct department which is correct behavior. If replies are coming from email1 then you need to check your Department email settings. Go to the department and look at what you have set for the outgoing email and the autoresponder emali.

Cheers.

pitrickzul

KevinTheJedi ahhhh wow my bad.. i had to delete the email and recreate to get oauth2 going and forgot to go to the department and change the email.

Apologies!

bcombs18

Hey all,

We just upgraded our osTicket instance from 1.16 to 1.17.2 (8fbc7ee) this last weekend and are also encountering this issue. We have 3 mailboxes and 3 departments and one of our mailboxes continues to send emails to the default department. Our emails are set for the appropriate departments. Any ideas for things to try? We seem to have hit a wall on this.

Thanks in advance!

Edit: We have also applied the patch and restarted our Apache server with no change.

KevinTheJedi

bcombs18

Seems like you need additional patches. I'd wait for the next release and retest. Otherwise you can apply any pull requests from jedikev and protich on github since November 15th and after. There are some "closed" (merged) ones as well so look for those too.

Cheers.

bcombs18

KevinTheJedi We waited for the v1.17.3 release and updated last Friday afternoon. After testing, everything appeared to be working as expected with the tickets from each of our 3 emails being created in their respective departments.

Yesterday, we realized tickets were no longer being fetched from any of the emails since the access tokens were not automatically refreshing so we re-authenticated each email which resolved that issue. However, after re-authenticating, the same email from my Jan. 27 post here has its tickets is ending up in the default queue again.

Any ideas for what could have caused the issue to come back, or any ideas for places to look for issues?

Thanks for your help!

KevinTheJedi

bcombs18

No, not unless the department for the email changed or something.

Cheers.

bcombs18

KevinTheJedi I managed to figure out what was happening. Email aliases weren't being matched to the emails we have configured in our osTicket instance so they were getting sent to the default department. The solution was actually what pcjkollmorgen mentioned earlier in this thread about adding another email for the aliases and only configuring the department setting.

I know this was supposed to be fixed from the patch mentioned in this thread, and also in the 1.17.3 release, but it appears this is still an issue in our instance of osTicket.

Thanks!

KevinTheJedi

bcombs18

I’ll have to check and see.

Cheers.