[ADD] New module incoming_mail_embedded_picture_reader

[JonathanNEMRY]

This PR add a new module that allows to read mail having embedded picture into its body.
Take care that this is currently only possible with odoo/odoo#10435 (wait for merge)

[hbrunn]

you should fix https://travis-ci.org/OCA/server-tools/jobs/102102216#L467

[hbrunn]

any reason not to do this on the client side rather than messing with an email's content?

[JonathanNEMRY]

Hi @hbrunn

• What's this missing tag 'images'? I don't see it into https://github.com/OCA/maintainer-tools/blob/master/template/module/__openerp__.py
• any reason not to do this on the client side rather than messing with an email's content?.
  With the website you have the possiblity to add embedded picture too. But Actually what Odoo does: a attachment link. I simply re-introduce the same behavior. Keeping a cid:id from a multi-part content has no sense as it is not understandable for Odoo. Moreover, the inverse process when sending email involves the transformation of the url attachment into a correct cid:id + content-id so if you want to forward a received mail with embedded picture, this conversion is required into the body ans then we have two separate and clean process.

[hbrunn]

images: The third heading here: https://www.odoo.com/apps/upload - I personally think we could do without it, but as this test is introduced, we should adhere to it
Let's see if we're on the same page here. 'Embedded images' could be understood two ways: Either an img tag with a data uri (should be supported already) or multipart messages (https://tools.ietf.org/html/rfc2110#page-13) - you mean the latter, right?

I have huge reservations against parsing and rewriting each message's HTML. The sending part is another issue, that should be handled by the mailing wizard. The model mail.message should be a stupid container, I think.

Why doesn't it work for you to iterate over all img tags (actually, you should support everything that can be embedded according to the RFC anyways) at display time, check if the src attribute is one of the messages' attachment content-id or content-location headers (those will have to be saved on the attachment in the lines of your patch)?

As for the patch itself: I'd be pretty surprised if it was merged to upstream, and we can't accept modules that don't work with an unpatched core. Did you experiment with overriding _message_extract_payload, remove the parts you're interested in, and only pass the remaining ones to super?

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.