For emails sent via Office 365, reply-to header could contains additional spaces
or get multiline header.
e.g.:
In-Reply-To:
<4ba8f246904b4fedb49fbab7945a7f82@AM3PR06MB433.eurprd06.prod.outl$$k.com>
The message lookup fails if header is not stripped
The previous matching rules were too fuzzy and allowed random
prefix-match or tail-match of other user's emails.
For example when looking up a partner matching 'foo@bar.com'
the system would sometimes find 'dom.foo@bar.com' instead,
or 'foo@bar.com.tw'.
Fixed by only allowing direct case-insensitive email match
of an addr-spec, or substring match of the addr-spec enclosed
in angle brackets, within a name-addr pair.
See also RFC5322, section 3.4
Also adapted related message_find_partner_from_emails() method
to factor out the partner email resolution mechanism to avoid
the same problem.
Adds corresponding regression test.
If an email contains several text/html parts inside a multipart email, the previous code was only keeping the last content part.
The Content-Type: multipart/mixed allows several independent part (RFC1341 7.2.2), so two html is technically valid.
With this patch, the two parts are concatenated. (opw 614755)
Modify append_content_to_html regex to make sure the regex keeps the content of the html instead of removing it.
e.g.: "123 <html> 456 </html> 789" used to be stripped to "123 789" while we expect "123 456 789"
This improve previous commit by making sure we
never consider the thread_id/model values in the
In-Reply-To/References header if the host name
did not match.
Also fixes the tests that were using the
6.1 compatibility mode to post in a mail group
thread instead of specifying the right
message-id.
bzr revid: odo@openerp.com-20140411142429-y0rpkzqbrsabxqsg
It now accepts <111...222..openerp-res_id-model@mydomain.com> partial matching
only if the target record has messages without message_id, aka <= 6.1 record.
Updated and added tests
bzr revid: tde@openerp.com-20131128133226-ce1qyeswi9n83q8v
Replaced some read by browse
Moved get_reply_to from mail_mail to mail_message
Hint: specifying email_from, reply_to help to enhance computation time
[REF] mail: cleaned some tests, renamed a file, moved mail_group tests into a dedicated file
bzr revid: tde@openerp.com-20130827133058-ko0g0ib0f0jihmdk
alternative mode is computed when browsing the parts, not from
the message content type.
Added tests.
Also added some notification_email_send to none to avoid sending
emails in demo/data/update.
bzr revid: tde@openerp.com-20130823120611-0n4ull3c8gvwug2u
interfering with automatic message_id creation of mail_message
[FIX] mail_thread: fixed issues with private messages through mailgateway
(wrong route checking, variable erasing)
[TEST] mail: added test for the second bug
bzr revid: tde@openerp.com-20130807142418-3h5qxdt3ekosj9x6
The parent record is the record that holds the alias. It is different
from the record updated or created using the alias. For example
projects have aliases whose parent is the given projet, and that creates
new task inside the project.
Updated alias creation and management accordingly.
This ownership concept is used to compute the 'followers' contact
settings of aliases.
bzr revid: tde@openerp.com-20130516164207-1zr0q6abw6a34ndf
Now handles private aliases (alias_contact as partners or followers).
message_route now works in 2 steps :
1/ finding all possible routes, as before
2/ checks and filtrates those routes, by finding the most
relevant message author and using it to check alias contact settings.
Also refactored the various partner finding method in one method
that checks in res.partner, for: partners, partners that are users,
partners that follow a given document.
bzr revid: tde@openerp.com-20130416132813-zcm1r5kx0dwrfeic
Before trying to find possible routes, check that the incoming email's
message_id is not already present in mail.message table.
If it is the case, return False.
Parsing of the message has been moved before routing, to avoid looking
for routes for emails we will discard.
Tests have been added and updated.
bzr revid: tde@openerp.com-20130322124809-ven2p5kxpqfjqxb5