d1c5c4718f842d55b29c3cccc968d415a16b082c
PURPOSE Be defensive when dealing with email fields, notably when having multi-emails or email field containing an already-formatted email. RATIONALE Two main use case of corner case usage of 'email' fields are tested in this PR and their support is improved * formatted emails: `"Full Name" <email@domain.com>` stored into the 'email' field; * multi emails: `email1@domain.com, email2@domain.com` stored into a single 'email' field; IMPLICATION Email field is generally managed as "containing a valid email". This means it is sometimes used as it in 'formataddr' as well as to perform searches or identification checks. Example of issue: partner 'Raoul' has a formatted email like "Raoul" <raoul@raoul.fr>. Using 'formataddr' in email_from leads to from: "Raoul" <"Raoul" <raoul@raoul.fr>> -> which is incorrect (but often dynamically corrected by email servers); Email field holding multi-emails are not normalized, as current normalize is done only if the field holds a single email. It means * no easy finding based on 'email_normalized', e.g. various tools like '_mail_find_partner_from_emails' or 'find_or_create' do not find partners based on this email; * no exclusion list management; * issue with formatting, like to: "Raoul" <raoul@raoul.fr,raoul.other@raoul.fr> -> which is incorrect (but often dynamically corrected by email servers); USAGE: OUTGOING EMAILS Those use cases currently generate faulty outgoing emails. This is valid for recipients ('email_cc', 'email_to') as well as author ('email_from'). For formatted emails: `email_to` is formatted again based on name and email which leads to sending emails to `"Full Name" <"Other"<email@domain.com>>`. Note that multi emails without formatting may work as it leads to email_to `"Full name" <email1@domain.com,email2@domain.com>`. Some outgoing email servers correctly send multiple emails. It depends on their fault tolerance. USAGE: FIND BASED ON EMAIL (NORMALIZED) When searching for partners (e.g. using '_mail_find_partner_from_emails' or 'find_or_create') normalized version of input is used. In case of multi emails sanitize is 'False', as normalization expects a single email in the field. Therefore no partner is found. In processes that do a "search or create" (e.g. using a template on a record) this leads to creating a new partner (or several partners in case of multi emails) each time. USAGE: OTHER FLOWS Other flows are build on top of '_mail_find_partner_from_emails' / 'create' of outgoing emails and are impacted by formatted email / multi email usage. Those include notably * mass_mailing: '_message_get_default_recipients' should be defensive to give correct values when creating mailing emails; * mass_mailing: faulty emails is based on normalize and multi-emails are considered as faulty and ignored; * after post hook: '_message_post_after_hook' tries to link messages without author (but email_from) with newly-created partners, when partners are created from chatter. It is therefore impacted by those corner cases; * marketing_automation: built on top of mass_mailing and suffers from the same issues; USAGE: UNICODE Unicode in emails should be supported. 'formataddr' and IrMailServer notably received fixes to support unicode. Some check performed on email addresses fail when unicode is involved, which leads to some emails not being sent while they could. USAGE: WRONG EMAIL FORMATTING With input 'name email@domain.com' (missing chevrons allowing to clearly spot the email part) 'getaddresses' returns ('', 'name email@domain.com) i.e. the whole input is considered as being the email. To improve the heuristic we can add a fallback by recalling 'getadresses' on the input with spaces replaced by commas when it found only an email and no name. The new email will be split into sub pairs allowing to find the real email and various name parts, allowing to make a new name / email pair. Emails should not contain spaces thus this is coherent with email formation. This fallback actually comes from a specific code done in '_parse_partner_name' of Partner model. Supporting it directly at tools level make the behavior coherent for all models. SPECIFICATIONS This PR contains first tests to cover current support of those use cases. Then we gradually improve support of multi-emails and formatted emails in various layers of mail code, from mail.mail to mass_mailing or email formatting. See individual commit for more explanation, each of them solving a specific issue / use case. Task-2612945 (Mail: Defensive email formatting) closes odoo/odoo#134934 Forward-port-of: odoo/odoo#134888 Forward-port-of: odoo/odoo#74474 Related: odoo/enterprise#47183 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
…
…
…
…
…
…
Odoo
Odoo is a suite of web based open source business apps.
The main Odoo Apps include an Open Source CRM, Website Builder, eCommerce, Warehouse Management, Project Management, Billing & Accounting, Point of Sale, Human Resources, Marketing, Manufacturing, ...
Odoo Apps can be used as stand-alone applications, but they also integrate seamlessly so you get a full-featured Open Source ERP when you install several Apps.
Getting started with Odoo
For a standard installation please follow the Setup instructions from the documentation.
To learn the software, we recommend the Odoo eLearning, or Scale-up, the business game. Developers can start with the developer tutorials
Languages
Python
49.6%
JavaScript
47.8%
SCSS
2%
CSS
0.3%
HTML
0.2%