 |
For the moment there is no other solution available. MantisBT only allows a small amount of html markup. To make the code readable at all we need to convert or strip most of the html markup from the email. Sometimes this works ok, sometimes this does not work at all. Normally emails contain a plain text and a html version of the email. EmailReporting tries to find this plain text version but some mail servers do not provide this. Exchange for example needs to have this enabled in the settings for the pop and/or imap protocol on the server to deliver this in the emails when they are retrieved from the servers. Could you please provide a debug dump of the email in this issue so that i can look into improving this |
 |
I could do that, however I need to mask some of the data (content & mails) since this is an automated mail of our CRM system. No other way to test it unfortunatelly....Give me a sec File attached. Not sure it is very usable since it already pasted all the content after each other? |
|
|
I need the file that starts with "rawmsg" The parsed email is the end result and useless at this point Also mask whatever you feel is necessary, just make sure you do not mask to much as we do need some html content for testing |
|
|
there you go.... Can you plz remove the parsed att? Noticed I did not mask it correctly :( |
|
|
alright got it. Will work on it and see what i can do |
|
|
There is something strange going on as well which might have to do with the same problem. If I auto forward mails from a gmail adress to the adress that the plugin uses to pick up the issues, I get the text pasted after each other (as stated in this issue). However, when I forward the same mail manually to the pick up mail adress, it parses the mail correctly. Does it have something to do with the mail settings? |
|
|
Manually using what interface? the gmail web interface? |
|
|
It's too many different factors to be for sure but every mail server in the route the email takes could add or remove a plain text version of the email. Even the sending client could be to blame. |
|
|
I checked some more and there is a new version of simple_html_dom (the new version is 1.5 and EmailReporting is using 1.11) which currently converts html to plain text for the EmailReporting. It seems to work a little bit better, though not perfect It will be included in the final release of 0.9.0 but for now you could try it yourself Just download it here: http://sourceforge.net/projects/simplehtmldom/files/simplehtmldom/1.5/ I do need to mention that there are no tables in the email you provided to me. It's a combination of < pre > tags and < span > tags containing CSS stylesheets elements, there are no actual tables. All of it is in one big line as well making it rather unreadable. I really wonder what email client would have created this mess |
|
|
I just replaced the dom file and it surprisingly seems to have some effect. I guess it's now a matter of finding out which markup language works and which doesnt. The messy mail is probably because we tested some html ourselves and somehow the mailserver does not place the code neatly in the raw message.... As for your initial question; yes the gmail interface. So big thanks for now since we can move forward! |
 |
has anyone a workaround for this problem? |
|
|
Please provide the debug dump (the filename starts with "rawmsg_") of the email so that i can look into it |
|
|
We have changed the settings at our echange server 2010 how you described it in 0014129:0031602 and the problem is solved. |
- Anonymous
