Thibault Delavallée
459c085c19
PURPOSE Be defensive when dealing with email fields, notably when having multi-emails or email field containing an already-formatted email. RATIONALE Add tests related to not standard usage of email field. Two main use cases are tested here * 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; Additional tests: tests with unicode / ascii / case / wrong formatting are also added to check the support in normalize and format methods. 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. SPECIFICATIONS Add tests related to those corner cases. Also add tests for computation of `email_formatted` field of Partner model. It currently generates wrong email values for the same corner cases (multi emails, formatted emails). Tests are also added for the computation of `email_normalized` field used notably for blacklists. It is not computed currently when being in multi email mode which prevents from any blacklist mechanism as well as make email finding harder. `_mail_find_partner_from_emails` tool method is also tested with multi email as it uses the same heuristic as normalized email field. Tests are also added for mass mailing, when having to mail documents that have a partner with formatted emails / multi-emails, or that have an email field with formatted emails / multi-emails. Also restore a test removed at odoo/odoo@afcb734908 while it should have been updated to state that email addresses containing non-ascii characters are supported. Add some tests for tools methods used in various email processing flows. Unicode tests are also added. In future commits we will try to make email usage a bit more defensive to try to lessen issues with that kind of use cases. Task-2612945 (Mail: Defensive email formatting) X-original-commit: odoo/odoo@fc8442f133 Part-of: odoo/odoo#134934
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