Say a customer already has a ticket, but responds from a different e-mail address, or sends a separate e-mail altogether. In both cases, these will end up as separate tickets. Is there an easy way to manually move these messages back into the ticket I know they belong to?

I have checked the message options, and it does let me create a new ticket out of it, but not move it into an existing ticket.

The closest conversation that I could find is https://forum.osticket.com/d/93794-message-on-customer-behalf, but there isn't any working solution.

Is it a matter of a simple DB query that I'm missing, or is this a planned feature somewhere down the road? Please let me know what do you think.

One more heads up: had to change this line to decode the Reply-To name, otherwise it showed Base64-encoded gibberish.

$header['reply-to-name'] = mb_decode_mimeheader($replyto[0]->personal);

(Source)

Hi everyone,

Having the same issue on v1.12.5-88, but with the same setup: sending via Amazon SES to our mailbox hosted with Yandex.Mail for Domains. (Sending from a verified domain/email address is an Amazon SES requirement, so our only option is to include the sender info in the Reply-To header.)

Almost 6 years later, the issue is still not resolved, and this is the most helpful and relevant Google search result, so @ntozier, please don't "kill the zombie thread", at least not until the bug is fixed in the core code. (Here's the only commit to class.mailfetch.php relevant to Reply-To since 2015 that I found.) The purpose of this post is to confirm the issue still exists and is not resolved, bring the attention to it, add information on how to reproduce it, and restore the formatting of the proposed solution.

I confirmed the filter itself works and is in fact being triggered by adding an extra action - in my case, it was "Attach Canned Response". So this is definitely not the incorrect filter rules issue.

Many thanks to @zox for doing most of the research, and coming back with a solution. The forum software must have been migrated, and the code formatting was lost, but I have found it in the Web Archive.

Here's how to reproduce: insert this code right after $raw_header = $this->getHeader($mid);.

// Dirty hack to workaround PHP bug in imap_headerinfo()
$replytowa=imap_rfc822_parse_headers($raw_header);
// Require the logging facility
global $ost;
$ost->logDebug('debugging reply_to', json_encode([
    '$replytowa' => $replytowa->reply_to,
    '$headerinfo' => $headerinfo->reply_to,
]));

Check the logs at /scp/logs.php to see both Reply-To values. Implementing the change proposed above (hot?)fixes the issue: use $replytowa instead of $headerinfo here.

Lastly, peter

It was my opinion that's the issue -- but perhaps you know better than I, how the system actually works

To be fair, that looks unnecessarily rude, and the guy was actually right, after all. And the further irony is, it seems matching on @ wasn't even his idea.

Either way, thanks for the great software!

I know ntozier won't appreciate me bringing up a "zombie" thread, but it comes up on Google search regardless of whether it's old or not – as long as it's relevant, which to me it was.

Here's what fixed it for me:

• Go to https://example.com/scp/staff.php
• In the list, click the name of the agent who can't act on a ticket
• Once on the agent editing page, go to the Access tab
• Make sure the agent has access to the problematic ticket's department; if multiple departments are required – add them all under Extended Access

The problem happened when I created a new sub-department under my main department and moved my tickets into that new sub-department. It turns out that by default existing users, including the admins, won't have access to any new departments, and furthermore, when tickets that they currently have access to are moved, they actually lose their permissions.

My osTicket version is v1.12.5-88