Post user reply from an email response to ticket thread

need4swede

Hi osTicket'ers,

I believe this function is part of osTicket, but I wonder if I may have done something wrong.

Current Set-Up

Users are currently able to create tickets via email.
User accounts also get created after an initial ticket submission.
We also have a form that users can fill out to submit their tickets.
When an agent replies to a ticket thread, the user receives an email with the posted message.
When a user responds to a ticket thread, the appropriate agents receive an email with the posted message.

All of this works great.

What I Need Set-Up

Currently, instead of replying to the ticket thread directly, if the user decides to reply to the email alert/notification they received, their reply does not get added to the ticket thread. Instead their reply just goes through as a regular email response and we see it in our inbox. We don't have an issue of a new ticket being created or any other errors like that. Is this how it's suppose to be handled? Would be nice if the user's email response could be added to the ticket body.

Thank you.

Additional Information

To create a ticket, users send an email to: itsupport@domain.com
Alerts and notifications to users are sent from: itsupport@domain.com (same as above)
Alerts and notifications to agents are sent from: itsupport@domain.com (same as above)

When a user gets a notification that an agent replied to a ticket, they receive an email from the above address. If they reply to that email (the notification), their reply can be seen from the inbox and gets received - but osTicket doesn't add their response to the ticket body. The only way for the user to update the ticket thread is to post their response to the thread directly. Hopefully that makes sense!

Thank you!

KevinTheJedi

@need4swede

Sounds like something isn't setup right. Are the Users's replies going to the same address and inbox tickets are being created from? It sounds like it's going to an address or inbox that's not being fetched.

Cheers.

need4swede

KevinTheJedi

KevinTheJedi Are the Users's replies going to the same address and inbox tickets are being created from?

Yes.

When a ticket is created, the user gets an email from: itsupport@domain.com
All communication is handled via that same email, including:

Create ticket via email
Alerts sent to users
Alerts sent to agents

But when a user replies to one of those alerts, the ticket thread doesn't get updated. I do, however, see their reply from the inbox (itsupport@domain.com)

Screenshots

KevinTheJedi

need4swede

So do the user replies open new tickets or don’t get touched at all?

Cheers.

need4swede

KevinTheJedi

They don't - in fact, nothing happens in osTicket when a user replies to an email. We simply just receive the email in the inbox. If a user composes a new email and sends it to that address, it generates a new ticket and that functionality seems to be working just fine - but again, not when replying to an existing ticket. If a user replies to a ticket alert email, nothing registers in osTicket and we simply receive their email response in our mailbox.

I hope that makes sense!

KevinTheJedi

need4swede

That is extremely weird. I don’t think I’ve ever heard of that happening. There is no selective fetching, it should process everything in the inbox configured.

You don’t see any errors in your logs (general server logs, webserver error logs, PHP error logs, MySQL/MariaDB error logs, osTicket System Logs, Browser Console logs, etc.)? What about on the mailserver side?

Cheers.

need4swede

KevinTheJedi

ntozier

No warnings or errors showing up on the logs via osTicket. Checked on the server side - got no errors there, either.
You know, I think I might have a suspicion on what's going on here. I'm wondering if it's a mail forwarding rule causing this issue.

I'm going to reference a simulated scenario that somewhat resembles our setup to describe it.

Our Setup:

Let's say we have three agents:

We also have an IT Support email account (0365):

IT Support - itsupport@domain.com

We also have an email group in O365, comprised of all three agents:

IT (Main) - it@domain.com

Messages from itsupport@domain.com get forwarded to it@domain.com - but copies are kept in the original inbox. The parent group (it@domain) is just an email group, and has messages from other accounts forwarded to it. The messages themselves all remain within their respective inboxes and don't actually get moved.

I thought maybe this was causing the issue - so I disabled the forwarding rule, and rebooted everything (including the server - for good measure)

Nope, no changes! Was really hoping that would be it. Thought maybe O365 was messing up the forwarding somehow, but it doesn't seem to be the case. Disabling all rules didn't fix anything - we just stopped receiving the forwards to that parent group, obviously.

Any clues as to where to start? It's bizarre, because I can compose a new email and send it to the itsupport@domain.com address and it generates a new ticket just fine. And if anyone (user or agent) replies to the ticket via the system, the appropriate parties get alerts of the replies.

The only thing that doesn't seem to work is having replies automatically appended to the ticket threads. Everything else seems to work.

ntozier

The only time I have seen something like this happen is when there was an email with seriously borked headers in the mail box. And I haven't seen it in many years....

KevinTheJedi

need4swede

I guess you can do some var_dump statements in the mail fetcher class to see if it’s picking them up:

https://github.com/osTicket/osTicket/blob/develop/include/class.mailfetch.php#L954

If they are being picked up then you can move to the following to see if they are at least hitting createTicket():

https://github.com/osTicket/osTicket/blob/develop/include/class.mailfetch.php#L696

Cheers.

Stufo76

Same issue here. If a user replies to the email he has already sent, the new email is queued to the ticket already open by previous email, and the ticket is eventually put in the "not answered" status, if it was "answered" before, but no alert mail is sent.