[StephanS]

Hi,
I`m using PM 3.2 on a CentOS (stack 205) manual installation and I have the following problem:
While importing users from AD or creating users manually they may have "special characters" in their name like "ü" or "ä" etc.

I use the SMTP(PHP-Mailer) Function to send Mails from Processmaker. Everything is working fine except one thing:
While any HTML-Content of the templates is displayed correct also with special characters, the "sender name" can`t work with those special characters and a non standard-symbol is displayed instead. Although the database itself stores the special characters correctly.

This happens also, when configuring the Email-Server at Processmaker and use special characters in the field "Sender Name".
If I use "mailx" or "mail" from the linux-server console addressing the same smtp-server everything looks fine: I guess the server itself is set up correct.
I`ve nothing found at the wiki or the forum. Only one similar old bug (v2.0.35 http://bugs.processmaker.com/view.php?id=4542 )
Can anyone point me to the right direction, which setting I have to change to get special characters working with "Sender Name".

Thanks in advance,
Stephan

[amosbatto]

ProcessMaker stores everything in the UTF-8 character set, including email addresses. I assume that your email clients are trying to see the names of the email senders/receivers in some other character set, such as ISO-8859-1 (which is the most common for Windows software in Germany). You have to figure out which character set your email client is using. Then you can use iconv() and PMFSendMessage() in a trigger to send out the email. For example, to convert from UTF-8 to ISO-8859-1:

Code: Select all

$to = iconv("UTF-8", "ISO-8859-1", "Úgür Läger <uger_lager@example.com>");  
PMFSendMessage(@@APPLICATION, "admin@example.com", $to, ...);

[StephanS]

Hi Amos,
thank you for the hint for the trigger.
But we have this problem outside the use of triggers, meaning with the Task-Option to send notifications.

You can reproduce the problem by the following two ways:
1. Task-Notofocation
Right-Click on a Task --> Prpoerties --> Notifications --> check "after routing notify next assigned user(s)
EMail From Format : Assigned User
If you start a case and the assigned user of the leaving task which sends out the notification has special characters, those characters are not translated to the phpmailer correctly.

2. Email-Servers-Setup
Also, if you set up the Mailserver in ProcessMaker - Settings Tab you can put special characters in the fields "SENDER NAME" and send out a Test-Mail.
This will also not work correctly.



What we`ve found out, that inside the email-clients (Windows-Workstation with Outlook 2013, Android-Mailclients as AquaMail, ...) the two fields
- From
- Reply-To
have the prefix for quoted printable UTF-8 ( ?UTF-8?Q? = which expects 4 digit hex ) but the content is coded with ISO-8859-x (2 digit hex)
For surprise, other header fileds (To, Subject) have correctly UTF-8-content (4digit).

If we check the Outlook-properties of the mail, it represents the "ü" from User "Herr Müller" as follows:

Return-Path: Herr.Mueller@mydomain.de
To: =?UTF-8?Q?Herr_M=C3=BCller?= <Herr.Mueller@mydomain.de>
From: =?UTF-8?Q?Herr_M=FCller?= <Herr.Mueller@mydomain.de>

You can see the difference? Both prefixes are UTF-8 but the content in "FROM" is ISO-8859-x (2digit for ü "=FC" instead "=C3=BC" which UTF-8 will expect). Therefore our clients cant show the content correctly.
By the way: mailsoftware on iPhones seems to recognize this and reencode it correctly. Apple may have integrated a failover for such, because it is the only Client, which shows the special characters in FROM correctly.

Now my conlusion:
Possibly at any point the field "Sender Name / From" is encoded ISO-8859-x and not UTF-8 while it was given to the program phphmailer, or this is a phpmailer-issue itself, which I dont believe. Where can I find the point that ProcessMaker prepares the variables and give it to phpmailer ?
Finally, we don`t want to rename all our users with special characters in future.

[amosbatto]

Stephan,
I haven't tried it, but it looks like to me that you can edit the code of the spoolRun::setData() function defined in processmaker/workflow/engine/classes/class.spool.php.
I think that should be called in all situations when sending out an email. If it isn't, then you can modify the code in the AppMessage::quickSave2() function in processmaker/workflow/engine/classes/model/AppMessage.php, which is lower-level code to write to the APP_MESSAGE table in the database.

[StephanS]

Hello Amos,

thank you. This was absolutely correct.
As I mentioned, the database stores everything correct. So the responsible file is

/opt/processmaker/workflow/engine/classes/class.spool.php

in line 459 the "from_name" will be utf8_decoded . It is the only entry which is decoded in class.spool.php. All other entries are transfered as they come from the database.
I assume this was set in the past for older PM-versions, because I do not see any reason for decoding an UTF8-database entry to send it with an UTF8-charset of phpmailer. May be phpmailer did not use utf8 in the past....

Anyway. My solution is to remove the "decode-call" as follows:
In /opt/processmaker/workflow/engine/classes/class.spool.php search and remove "utf8_decode". Line 459 changes from

before

Code: Select all

                        $oPHPMailer->SetFrom($this->fileData['from_email'], utf8_decode($this->fileData['from_name']));

after

Code: Select all

                        $oPHPMailer->SetFrom($this->fileData['from_email'], ($this->fileData['from_name']));

Should this be reported as a bug or another way to PM-developers ?
If it is not changed by ProcessMaker, we have to implement this workaround after each update...
Thanks again for pointing into the right direction.

[amosbatto]

This looks like a bug to me, because the code explicitly tells the email client that it is sending UTF-8, but then it sets the sender's name in the ISO-8859-1 character set. Maybe there were poorly designed email clients in the past that couldn't handle UFT-8.

I have filed a bug report about it: http://bugs.processmaker.com/view.php?id=22944

[StephanS]

Thank you very much Amos,
I was not shure to file a bug.