Non-English Encoding At Email Logs

[SimWhite]

There is a problem at email logs with email contains non-english encoding.

Path: /admin/tools/logs/email/
OS: Debian
Blesta: 3.1.1
PHP: 5.4.4
MySQL: 5.5.35
Screenshot: http://dl.dropbox.com/u/2332741/Screenshots/tgys8qwk27lz.png

And another one problem with emails. When system generate email for client it use subject like "Update to Ticket #2873028 -91d8-", when client replied for this email, system can't find ticket number and send to client email "Support Request Failed", but if client delete "-91d8-" from email subject when replying everything is going well. How to fix it?

[Tyson]

Please provide more information as described in How to Report a Bug. What are the steps to duplicate this issue? Does it only occur with emails sent from the Support Manager? Does this only occur with the body text, or with the subject/html as well? Does this also occur in the client mail log?

 

As for the other issue, the ticket hash code is required to reply to a ticket via email. If it does not match, a bounce is sent because the reply could not be added. A bounce may also be sent if the support department does not allow tickets from non-clients, and the person sending the email is not a client. If you remove the hash code altogether, a new ticket will be created instead.

 

If you want to allow replies by non-clients, then update the support department and uncheck "Allow only clients to open or reply to tickets".

[SimWhite]

What are the steps to duplicate this issue? Does it only occur with emails sent from the Support Manager? Does this only occur with the body text, or with the subject/html as well? Does this also occur in the client mail log?

I have not checked the other emails yet. Message body and subject are normal, incorrectly displayed only at logs section.

Steps to reproduce:

1. Create a support request from /client/plugin/support_manager/client_tickets/add/1 in Russian for example. (bottom line at screenshot, everything is OK)

2. Write a response to the user via /admin/plugin/support_manager/admin_tickets/reply/1/ in Russian. (top line at screenshot, non-readable)

3. Results https://dl.dropboxusercontent.com/u/2332741/Screenshots/1u1K332S6e335O.png

 

As for the other issue, the ticket hash code is required to reply to a ticket via email. If it does not match, a bounce is sent because the reply could not be added. A bounce may also be sent if the support department does not allow tickets from non-clients, and the person sending the email is not a client. If you remove the hash code altogether, a new ticket will be created instead.

I understand how it works and understand settings. I mean if message contains full subject like "Update to Ticket #2873028 -91d8-" system does not recognized it, but if subject contains only ticket number like "Update to Ticket #2873028" everything is going well. I don't understand, but today it is working fine. Hmmm.. I'm using different email client today. Yesterday I use Airmail for testing, today I use Roundcube webmail.

I remembered that the same problem was when I wrote a request to Eric. Letters come with answers "Support Request Failed" and I also used AirMail.

[Tyson]

Thanks for the steps to duplicate. I've replicated and resolved the issue in CORE-1070 for v3.1.2.

 

If you want to pre-patch this fix yourself, then

 

Update /app/views/admin/default/admin_tools_logemail.pdt (line 40):

    if (strlen($summary) > 40)
        $summary = substr($summary, 0, 40) . "...";
?>
<td><?php $this->Html->_($summary);?></td>

to:

$truncate = (strlen($summary) > 40);
$summary = substr($summary, 0, 40) . ($truncate ? "..." : "");
?>
<td><?php echo $summary;?></td>

If you can replicate the other issue you mentioned, feel free to create another bug report thread.

[Tyson]

You may actually continue to exprience this issue if a multi-byte character is where the string splits. Similarly, if this occurs on the support ticket listing page, the ticket listing may fail to load via AJAX (after 30 seconds of viewing the page), leaving the ticket listing blank. We're aware of that and will likely have a fix for the release after v3.1.2.