|
Hi Anton,
Your approach of adding the property to jira-application.properties file will work for us. Sorry I dont know which mail clients but I have gotten this feedback time and again from several people (including partners like Fujitsu), so I understand it is a real issue. Please let me know how you decide to prioritize this. Thanks, Neeraj Cool.
May I ask if it is possible to find out what e-mail clients are being used? I would like to understand the whole problem before we solve anything Cheers, Anton,
I have information on some mail clients on which this problem occurs, there may be more: 1. ALmail versions prior to 1.12 (compatible with UTF-8 from 1.13) 2. EdMax(free version) 3. Becky! 2.25.02(this is a major client in Japan and does not handle UTF-8) Please see screenshot attached. Thanks, Neeraj Hi Neeraj,
Thank you for the info. We will try to get this done for 3.8. The way it will work is that a new property will be added to jira-application.properties file. By default the property will be commented out. In this case JIRA will fall back to its normal encoding. If JIRA finds the property in jira-application.properties file, it will use whatever is specified there. In your distribution of JIRA you will need to comment in the property and set it to the required value. On the side note, may I ask why do Japanese users use "special" e-mail clients? Is the problem that standard e-mail clients (e.g. Thunderbird Cheers, It seems that it is a vicious circle that a segment of Japanese users are not upgrading their mail clients because they are concerned that others may not upgrade at the same time. So we continue to see iso-2022-jp as the defacto mail encoding format even now. Some mobile phone email clients also use it.
Fair enough.
Thanks for the update. Neeraj,
Sorry Neeraj, we couldn't squeeze this one into 3.8. Though it has been fixed for 3.8.1. Cheers, |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Resolved
Major
Please allow ability to set mail encoding separtely from html/DB enoding
Generally we would like to keep the number of configurable properties to a minimum, as every property that we add gives users something they can misconfigure.
May I ask what e-mail clients your users are using? I suspect that old e-mail clients might have other problems with JIRA's e-mails. For example, displaying HTML e-mails. Is this the case? If this is the case, I am leaning towards pushing users to upgrade their e-mail clients. This should greatly decrease the number of problems users are seeing, and improve their overall JIRA experience.
I have looked through the code and from a technical perspective the property should not be too hard to add. If we do add the property, do you mind if we simply add it to jira-application.properties file and do not allow users to change this property through the UI? The main reason for this is that we would like to minimise the number of properties users can edit and hence misconfigure.
This way in your (Japanese) build of JIRA you can modify this property.
I am tentatively scheduling this issue for JIRA 3.8. Please let us understand the problem a bit better before we make the final commitment.