PURPOSE
Simplify 'mail.tracking.value' model and code. Remove unnecessary fields and
computation. Make code easier to handle and more batch-enabled.
SPECIFICATIONS
Rename 'field' to 'field_id' on tracking model. It better indicates it is a
many2one and not a char field holding a field name for example.
Task-3345979 (Mail: Simplify tracking model)
Part-of: odoo/odoo#124182
PURPOSE
Simplify 'mail.tracking.value' model and code. Remove unnecessary fields and
computation. Make code easier to handle and more batch-enabled.
SPECIFICATIONS
SPEC 1: prepare all tracking values at same code place
Delegate all computation of tracking values into the 'create_tracking_values'
method. Curently part of it (currency field) is done in the caller. Better
split code per feature.
Method is also made private, as it is not required to expose it.
SPEC 2: cleanup tracking value formatting methods and calls
Code used to display tracking value can be simplified: remove unnecessary
wrappers, make code easier to read, avoid composition of field name but
use a mapping instead (easier to grep 'old_value_char' when it is effectively
used).
Ensure code always calls '_tracking_value_format' to ease future improvements
and have all formatting code being batch-enabled.
SPEC 3: simplify Chatter formatted value structure
'fieldType' is currently added in old and new values. As it is a field
property it can be moved higher in the formatting result to be included
only once. Also add 'fieldName', the column name, to the formatted results
as it will soon help various tool methods. Moreover it makes sense to have
the source of the tracking as the real column name, in addition to its
string and type.
Task-3345979 (Mail: Simplify tracking model)
Part-of: odoo/odoo#124182
Update (some) query counters according to runbot state.
Also make some tests deterministic when involving company name.
Task-36879 (Mail: Support MultiCompany Aliases)
closesodoo/odoo#135288
Related: odoo/enterprise#47345
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Have all mail tests be in a controlled multi-company environment by default.
Remove extra calls to '_activate_multi_company' as it is now part of the
base 'MailCommon' test class.
Task-3453577 (TestMail: Update Alias/Gateway tests for MC)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#135055
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.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@18c71edf59
Part-of: odoo/odoo#134934
As it already normalizes returned emails some manual calls to 'email_normalize'
are not necessary. Some variable names are updated to be clearer about the
email being normalized.
Parsing contact name and email is also moved into a tool function to avoid
using a partner environment just for a tool parsing method.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@f7add44c28
Part-of: odoo/odoo#134934
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS
When having multi-emails input in an email field, 'email_normalized' field is
currently 'False', as they expect the field to contain a single email. This
has several drawbacks
* searching partners or fetching information based on emails does not work as
most tool methods use 'email_normalized' which is False (see e.g.
'_message_partner_info_from_emails', '_mail_find_partner_from_emails'
or 'find_or_create');
* blacklist is not available as it is based on 'email_normalized';
* mass_mailing wrongly considers those emails as invalid and cancel their
mail and related trace, as it tries to skip sending emails to invalid
emails;
Be more defensive and use first found email in case of multi-emails field.
Other emails are ignored. It is already an improvement that does not break
flows in stable and allow more emails to be sent.
before
-> email: '"Raoul" <raoul1@raoul.fr>, raoul2@raoul.fr'
-> email_normalized: False
after
-> email: '"Raoul" <raoul1@raoul.fr>, raoul2@raoul.fr'
-> email_normalized: raoul1@raoul.fr
A side effect is that it helps finding back some partners, as indicated in
tests where less phantom partners are created. It also helps suggested
partners / emails flow in discuss.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@90218186c5
Part-of: odoo/odoo#134934
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS
Main fix in this commit: fix multiple nested formatting in 'email_formatted'
computation for <res.partner>. Other use cases are mainly left untouched as
we let users deal with their input. In summary :
* double format: if email already holds a formatted email, we should not use
it to compute email_formatted, like
name: Name / email: 'Format' <email@domain.com>
-> before '"Name" <"Name" <email@domain.com>>"
-> after '"Name" <email@domain.com>''
* multi emails: sometimes this field is used to hold several addresses
like email1@domain.com, email2@domain.com. We currently let this value
globally untouched by extracting emails and joining them, as we do not
expect email_formatted to be a list of emails. Extractin emails allows
to filter out extra text stored in email field, like
name: Name / email: text, email1@domain.com, email2@domain.com
-> before: "Name" <text, email1@domain.com, email2@domain.com>
-> after: "Name" <email1@domain.com,email2@domain.com>
* invalid email: if something is wrong, better keep it in email_formatted
than harcoding "False". Indeed this eases management and understanding
of failures at mail.mail, mail.notification and mailing.trace level. This
behavior does not change as it was already implemented like that even if
not sure it was intended;
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@9175bbd8e2
Part-of: odoo/odoo#134934
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
When using message_post, the body format must be explicitly specified.
If html is expected, a Markup object should be used.
If text is given, the content will be escaped.
Before this PR:
message_post was unaware if the content of a message was HTML or
text. This lead to multiple situation where the content was
incorrectly considered as HTML and led to display errors.
In
self.message_post(body="Hello %s!" % self.name)
if the name contained HTML, it would be evaluated.
In
self.message_post(body="Contact Raoul <raoul@caramail.be>")
the email would not be displayed as considered as unknown HTML and
discarded by the sanitizer
Now each call must explict the type of content.
Use the escape() helper to properly combine Markup and translations.
It would also be acceptable to use Markup() to wrap a static
translation but escape is better as one can not guarantee the content
of a translation.
closesodoo/odoo#111850
Related: odoo/documentation#3612
Related: odoo/enterprise#36728
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently there is no way of knowing who changed the address
of a partner. This field is of high importance and should be
tracked to be able to follow who is editing it.
As addresses are represented with a bunch of fields, tracking
them individually would result in weird-looking tracking
messages with each value stacked on top of the other.
To avoid this, we take advantage of the fact that tracking can
be used on non-stored compute fields to log any change as a
change over the full address.
The full address is derived from the contact_address field to
take advantage of the existing regional formatting of addresses.
It is however modified to replace return to lines with commas to
accomodate the formatting of tracking messages in the front-end.
task-3165293
closesodoo/odoo#114695
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Allow model to provide default values for auto creation of related res_partner
such as name, title, company_id, ...
It is used when claling 'Partner._find_or_create_from_emails()' that now
accepts custom data when creating partners based on a given email_normalized.
This allows notably to flatten a loop due to multi-company when creating
partners from emails in template management. It is now done using this email
based dict allowing to create all partners at once.
Task-3024050
Part-of: odoo/odoo#105111
Purpose is to be able to create find or create partners in batch based on a
list of emails. When sending email in batch, notably using templates, doing
sequentially a search or create for each potential email to contact is not
efficient from computation point of view. This commit introduces a new batch
method for that purpose.
If no valid email is found for a given email, it is used as it to try to
find partners with same invalid email and/or keep the value in order to
allow updating it afterwards. Notably with notifications resend it is
possible to update emails, if only a typo prevents from having a real
email for example.
Falsy emails do not create partners as those have no real interest.
Task-3034875 (Mail: Speedup and batch partners find or create with templates)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#99482
* = bus, hr_holidays, test_discuss_full
- use channel member instead of partner for typing
- use channel member instead of partner for all other return values from server
- remove temporary partner hack in livechat and keep public partner
- remove some obsolete convert data
- adapt format methods accordingly
task-2664853
closesodoo/odoo#98923
Related: odoo/enterprise#30760
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Purpose
=======
The method find_or_create of res.partner overwritten in mail does not
take into account the parameter assert_valid_email. This commit adds a
simple check and test.
Task-2799577
closesodoo/odoo#86943
X-original-commit: 7a07b365370d03e963aa7f7d9d19df7ee33e8a1c
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since https://github.com/odoo/odoo/pull/73689 all internal users are no longer
known at init. Unlike what was stated in the corresponding PR, the code of
mentions wasn't actually good enough to allow it without any drawback.
This PR fixes the issue by prioritizing internal users on the result of the RPC.
As a bonus the internal user state is immediately returned when fetching
followers, which allows mentions to be accurate even before the RPC is done.
task-2695224
closesodoo/odoo#80645
X-original-commit: 86de2f231be87b289deb85c3b20b93d890cce918
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When merging partners through the ``base.partner.merge.automatic.wizard``
wizard, messages and followers are merged. However activities are not
probably because its underlying model is "newer" then messages and followers.
This commits fixes that behavior.
Task-2641572
PR odoo#76159
Closes#71654
X-original-commit: 7e17678ec6ebbbe37b807a5d264cc5afd46bae1a
Part-of: odoo/odoo#77005
Co-authored-by: Thibault Delavallee <tde@odoo.com>
Purpose is to add some tests for newly added feature logging portal access
granting. Some code is also cleaned to avoid unnecessary computation when
groups are not modified on user model.
closesodoo/odoo#76040
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Behavior before the commit
--------------------------
find_or_create define in mail module called
super if no partner is found based on the email_normalized
super call find_or_create define in base that make
a search again on the email before the creation
This cost two search every time a new partner should be created
and the search on email is less efficient than the search on
email_normalized
after the commit
----------------
Only the search on email_normalized is done before the creation
drawback: if a module that does not depends on mail module
override find_or_create the code will not be triggered anymore
the module should depends on mail module
closesodoo/odoo#65565
X-original-commit: 49d5b3813e57f2cd91d582de9b9bb534f05d2dc3
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Rewrite code parsing name (_parse_partner_name) to make it easier to
understand. Tweak find_or_create to return directly a recordset with the
found partner / new partner instead of a name_get result.
Also inherit Partner.find_or_create() in mail in order to benefits from
email_normalized field, allowing to improve the search on matching emails
and avoid duplicates.
LINKS
Task ID 1963529
Community PR odoo/odoo#32397
Thibault Delavallée