Open Source Document Management System | OpenKM

Hello,

I looked for similar topics, but they seemed to present more complicated issues and they were also pretty old, so I was not sure which part of the discussion still applied.

Our problem is related to uploading Outlook .msg files (as documents) and subsequently trying to download them, in OKM community 6.3.0 and 6.3.4 (there are minor behavioral differences, but most of the issues apply to both).

1. While uploading a simple email to OKM we get the error/warning "com.openkm.util.MailUtils - Error in RTF to HTML conversion", however the emails seem fine (they can be previewed correctly, attachments can be downloaded from within the preview window.

2. When trying to download these simple emails, we get an .eml file that sometimes has the headers (and sometimes not even them), but has no body. I will attach one of these simple emails that cause this type of problem to the post. However, if the email is more complex (has a lot of lines/replies) it seems to download fine. There is no error in the OpenKM.log when the downloaded .eml file has an empty body.

3. The attachments that were part of the original uploaded mail (and that are visible and accessible in the preview tab) are never part of the downloaded .eml (even when the body of the mail is present).

Please let me know if I can provide more information about the configuration that could help identify the issue.

Thank you!

How did you upload the mails:
1- from UI
2- import from Outlook
3- mail account configured for importing

Thank you for the quick answer.

We uploaded the email using the "upload document" action from the OKM UI.

I have been able to reproduce point 3, but not able to reproduce point 1 and 2, if you share some samples for it we will take a look.

I have created an issue here https://github.com/openkm/document-mana ... /issues/36 you can create new ones from there. A description and samples about reproduce it are welcome.

Thank you for your support jllort, I can see the issue being tracked, which is good.

Just to make sure I understand correctly: did you try to import via the UI the email that I attached (in zipped form) to the first message (and you could download it correctly afterwards)? Or was it another test message that you generated that worked?

Description of the issue.

1- I uploaded the file from UI
2- I see file attached
3- Then I downloaded and imported again ( during the process -> export -> the attachment is lost )

If you have another issue sequence, share with us and we will test it, but please always share with some detailed description to reproduce it.

Yes I did the same process and the content of the email is also long (along with the attachment). If it wasn't like that for you then it must be some bad installation or configuration of some module that is involved in that process. Further testing revealed that if we upload a longer file then the end is truncated. I am attaching another sample .msg email as we uploaded it (and it's the same way it appears in the preview panel) and the resulting .eml file when downloading it. Any idea what module could cause that so we can check/update it?

Thank you again for your support.

Seems the .msg contains an HTML content and .eml contains the plain text. Confirm me that you have imported msg and then when you have exported the .eml the format of the content has been lost. Or the issue is about after several export and import the size of the mail is not the same ? althought you see the same content.

This is exactly what seems to be happening: "you have imported msg and then when you have exported the .eml the format of the content has been lost". It seems the end of the message is truncated in this scenario, and if the content of the .msg file is small enough then everything gets truncated. However the content is not truncated in the preview pane within the application, so the problem seems to affect strictly the .eml download.

There's a bit difference between what actually does 6.4 professional edition and 6.2 community. In the beginning when application read document, extract several pieces of mail ( to, from, content, attachments ) and save into database. Basically converting from mail object to database object. When we download the mail internally are doing reverse action, between these actions the mail some section might be lost ( I think header is lost, because we are not archiving it ). In professional version we save the entire binary mail as it comes and later when you download you are downloading the same.

That's the reason of the issue, the solution is store in the community version the binary mail data as is done in professional version. If you want to help us on it I can guide you on the changes and classes should be taken in consideration for it ( otherwise you should be patient until we find time for moving that changes in the community edition ).

Thank you very much jllort for your help, we can consider this thread closed and we will communicate the situation to our client, hopefully they will chose to upgrade to the professional version.