sorry, I misunderstood your latest comment then. I'll watch and wait (actually for Confluence, not for JIRA).

So why do you keep escaping with hex-values instead of decimal-values ?

The next version of JIRA (v4.1.2) will NOT escape with hex-values.
It will not escape with decimal-values either - it will simply pass characters 128-255 unescaped.

If you are worried about the proposed solution, I can send you some test emails to confirm the fix works for you.

I'm a bit disappointed for your E-Mail solution: "This is normally no problem"

Actually entities like

ä

ARE a problem in Lotus Notes email clients (which this bug-report is about).

As written in http://jira.atlassian.com/browse/CONF-16221 Lotus notes would be able to
render

ã

correctly !

So why do you keep escaping with hex-values instead of decimal-values ?

Turned off the encoding of characters 128-255 in the TextUtils.htmlEncode(String) method.

This was unnecessary because:
1) The page is encoded in UTF-8

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

2) This encoding was only ever applied to select parts of any given HTML page.
If you look at the HTML source code of this very "View Issue" page right now (on v4.1.1) you can see that the Description does not include this encoding:

<p>In JIRA's HTML emails, all characters between 128 and 255 (that is, all non-ASCII) are escaped as numeric entities (eg. &amp;#xE4; for ä). This is normally no problem ...

The ä is included here verbatim, and not encoded as ä

We are exploring changing the behaviour of OSCore TextUtils.htmlencode to not escape characters 128-255.
This seems to no longer be useful now that we expect to use Unicode encoding on HTML pages.

Thank you arno.

The patch for 3.13.2 should also work for jira 3.13.1.

Hi,
We are having the same issue with lotus notes, is there a patch available for 3.13.1?
Thanks
MeM

Hi,
Thank you for this patch,
Yet one question...is this patch appliable to the standalone version of JIRA 3.13.1 ?
Regards,
Kais

thanks christian for this solution

Patch for 3.13.2

The patch has been tested using tomcat as server

Installation

• Get the ear/war distribution
• Unzip it
• Copy Email.java to atlassian-jira-enterprise-3.13.2/src/com/atlassian/jira/mail/ directory
• Call build.bat for windows or build.sh on linux systems in atlassian-jira-enterprise-3.13.2

Patch for 3.12.2

That is the same story, get a war/ear dist for 3.12.2, and use Email.java (14 kB) insteat.

It seems that it finally will be fixed in a commercial version : 3.13.x (see header of this issue). That's good news. But you will have to upgrade to that version. That's at least what I understand, but I'm not working for Atlassian, so you might want to check with them directly.

Hi,

I need to patch my JIRA version 3.12.2 for having correct html emails on our Lotus Notes clients.

Could any of you please give me the step by step instructions to install the patch? I will appreciate.

This bug needs to find a fix in a commercial version of Jira, since it doesn't give a very good feeling of the product. to our end users.

Thanks a lot.

Added brute-force Email.java patch as proposed by Christian. Unfortunatly I could not yet verify the stuff on a Notes system because my customer has not yet enabled me on the notes system

Thanks Christian for your precious help and...
Bonne fin de soirée !

New version of the fix including the <BR/> problem.

Hi !

You are right about the limitation of this patch.
I didn't notice it because we had a special convention that the summary of any issue must be in English and only the comments can be in french if desired (multi-lingual enterprise). So I hadn't come across this problem before.

There certainly is a fix, not not via this technique. Another class should be hijacked but I don't know which one and don't have the time to investigate.

Ideally, it should be the method that attached the mail body to the mail message. Or something similar.

There is also another problem with my fix : JIRA uses <BR/> for line breaks, but Lotus Notes understands only <BR>. So a enhanced my fix to include this.

Hi everbody,

I managed to compile the file in version 3.13.

In my case it resolves only one part of the problem:
The description field displays special characters correctly but all other part are still invalid (Issue title, assigne, ...).

Is there a way to fix this ?

Thanks!

Marc

PS: I'm french and we use a lot of special characters .....

Hi everybody,

Is Christian's patch still valid for JIRA 3.13 ?
The possibility to have HTML email is very important for us, and we are stuck with Lotus Notes for our email server...

Thanks!
Cyril

Thank you, Christian .

I will install 3.12 and try your solution.

Cheers,
Cyril

Well, I guess the thanks go to me?! And maybe I forgot to tell you that I am not from the Jira team? Anyway, it was a pleasure helping you solve this problem.

And unfortunately, this issued cannot be makred as SOLVED/FIXED because standard Jira doesn't include my fix. And maybe it will never be included. The culprit in this business is Lotus Notes anyway, not Jira. Maybe IBM could upgrade Lotus Notes to the latest HTML standards... And maybe they did already. We have not yet upgraded to version 8.0 but will soon do. I'll post my comment here when it's done.

Cheers,
Christian

Hello,

This issue is solved.
Thanks guys for your help, and thanks in advance for making this issue SOLVED / FIXED

anas.

Yes! See my comment just above yours. Check out the quick patch feature of Jira (you will find that in the standard on-line Jira doc) and apply the procedure to my file DefaultTextRenderer.java that you can download from this issue.

Hello,
Does anybody found a solution for this issue?
I'm having the same problem.
Thanks

.. about previous comment: it's the file DefaultTextRenderer.java that I have attached. With the quick patch feature of Jira you can easily compile this file and replace the original one.

Still very new to Jira and I didn't understand the previous proposed fix, so I did my own. Hope it will be helpful.

Patch for 3.12.

For anyone wanting to apply this patch to JIRA 3.11: I've attached a patched template file for JIRA 3.11. The class file provided is still valid for JIRA 3.11.

I just bought the JIRA Enterprise Server for my company, and we use Lotus Notes.

We have the problem, which is quite annoying (it prevents us from using html mail notification for task).

I tried to put your patch for version 3.7, but it doesn't work: there isn't any DefaultRenderer class anymore.

Please, can you provide any updated patch for version 3.11 ?

Thanks!
Cyril

I am un-scheduling this issue as it will be quite a significant change in JIRA and the symptoms only really seem to affect html emails in Lotus notes.

Can anyone comment here and let us know if this is a huge generator of support requests or if the issue is very troublesome for any users.

As I mentioned to fix this would be a large change in JIRA and we only really want to make this change if we will see a benefit to the users.

Thanks in advance for any comments.

I have asked for advice on the Lotus Notes forums:

http://www-10.lotus.com/ldd/nd6forum.nsf/DateAllThreadedweb/2a179d164082ceb28525728400047a76?OpenDocument

A further patch is required - make the change described in templatefix.diff to atlassian-jira/WEB-INF/classes/templates/email/html/includes/summary-topleft.vm, or copy the attached version if you're running JIRA 3.7.x

> I am beginning to think that the default behaviour of escaping the octal 200 and 377 chars is more annoying than helpful.

I agree, but I wonder if there's a class of bug we've been avoiding so far, by only sending ASCII.

If we can be sure that the encoding of the page/email is always set to UTF-8, then the HTML-escaping is redundant and should be removed. Ie. I suggest we first hardcode UTF-8 as the page encoding, and make sure UTF-8 is the hardcoded email encoding.

I am beginning to think that the default behaviour of escaping the octal 200 and 377 chars is more annoying than helpful.

I think we need to investigate changing the default behaviour of:

TextUtils.plainTextToHtml(value)

to call:

TextUtils.plainTextToHtml(value, false)

As this is in a shared component, we need to be careful, as the change will affect a lot of other products.

Need to plan how we do this.

To apply the patch, download charfix_jira37.jar and run 'jar xvf /path/to/charfix_jira37.jar' in your atlassian-jira/WEB-INF/classes (Standalone edition) or edit-webapp/WEB-INF/classes (WAR edition) directory.

Attached is a code diff and patch for JIRA 3.7.x which should fix this. It leaves these characters unescaped (there is no real reason to escape them).

The text is escaped in JIRA's DefaultTextRenderer.java class:

    public String render(String value, IssueRenderContext context)
    {
        return JiraKeyUtils.linkBugKeys(TextUtils.plainTextToHtml(value));
    }

and TextUtils.java does the escaping between octal 200 and 377.