Before the commit, the _get_seen_list() function in the mass_mailing module was
not able to correctly identify all the duplicate email addresses in a given mass
mailing. This was because the function chose and used only one way to find an
email address for each record in the mailing list, even though there are many
ways to find an email address for a record.

For example, a crm.lead record might have an email address in its partner_id
field, but it might also have an email address in its email_normalized field.
This can vary from record to record.

To fix this issue, the _get_seen_list() function was updated to only look at the
email address to which emails have already been sent, rather than trying to
fetch it from the record itself. This ensures that all duplicate emails are
correctly identified and that no duplicate emails are sent in the mass mailing.

Task-3234378

closes odoo/odoo#118220

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

During this pr (https://github.com/odoo/odoo/pull/121413

), we have made a few
css changes on the din5008 format, some of them needed to be revert because they
 broke the layout.

closes odoo/odoo#134775

Task: 3495712
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>

There is code to block the UOM changing if there are done moves.

Because it searches in non-sudo mode, it does NOT currently
stop you changing the UOM if the product has moves in a different
company.

closes odoo/odoo#133895

Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>

Typo error detected on `/mrp/wizard/mrp_immediate_production_views.xml`.
It doesn't cause any issue on module installation or updates, but
it's probably gonna cause issue on view inheritance.

If you can confirm this is unintended typo I will edit commit msg.
I also detected this on version 15.0 and 16.0.

closes odoo/odoo#134070

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Before this commit, simple user could not use the novatim API since https://github.com/odoo/odoo/commit/160e8bfbf72a3e5d7cc8d8cbe7bc4f310f298baa



closes odoo/odoo#134678

Taskid: 3497580
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>

Add IEPS taxes and tax groups. Make sure the IEPS taxes are
`include_base_amount` and have a lower sequence than the IVA taxes.

Unify the names of the taxes and their labels on invoice.

Resequence the taxes to group them by nature.

task-3100679

closes odoo/odoo#133372

Signed-off-by: Laurent Smet (las) <las@odoo.com>

Before this commit:
Packages were computed using a for loop, skipping any picking without
any packages.

After this commit:
Packages are computed using a read_group, speeding up the computed
method for large pickings with hundreds of stock move lines.

opw-3461706

closes odoo/odoo#132585

Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

Backport from version 16.0 of _get_default_amls_matching_domain
To decrease the amount of account.move.lines which should be reconciled
Exclude amls of payment move lines where the account is configured
as receivable or payable

closes odoo/odoo#133690

Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

before this commit, in resume we are able to put end date less than start date
which is not possible in real life.
make change in constraint to check selected end date is greater than start date.
make changes in demo data of end date which are according to new changes.

task-3397726

closes odoo/odoo#127351

Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>

Before this commit, when `a` tag is in a td, the color of text ellipsis
(3 dots) is different than the text because the text-ellipsis is set on
the parent element, that is `td` element and the color is set on the `a`.

This commit sets the right color on td element when that element has `a`
element.

Limitation (only for td inside element with `o_portal_my_doc_table` class):
if the `td` element contains `a` tag and another element
then the color has to be set to that other html element otherwise,
the color will be the one of the a tag.

task-3251721

closes odoo/odoo#124447

Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

Reproduction:
1. Install Event, Sales, Website, Contacts
2. Login as Admin, create a new portal user 123, set the password as 123
3. Go to Contacts, find the created user, add a shipping address, leave
the name blank
4. Open another tab login as the portal user, place an order
5. At the Address step, Edit the billing address, change the name from
empty to “Test Name”, click next
5. An error is thrown cause the new name is not equal to empty value

Fix: this fix aimed the conditions we have in the previous PR: https://github.com/odoo/odoo/pull/111708
This change will allow the user to add a name for shipping address at
checkout.Without the fix, if you
change the name of a shipping address, it won’t be able to get through.
This is because of how we manage the shipping address, e.g. shipping
address is managed as child partners. For shipping address, the check
can_edit_vat is always false. See here: https://github.com/odoo/odoo/blob/14.0/addons/portal/models/res_partner.py
Another check, e.g. if shipping is being edited, is added to make sure
name/email can be changed for delivery address. For internal user, the
editing of shipping address is not blocked because of the `share` check.
But the same condition is used to ensure the consistency in case we
change how the shipping address is managed in the future.

Note: if the data is '' for name for example, the pre-process will
convert it to `False`. Thus the edge case that `'' != False` doen't
exist anymore

Related PR: https://github.com/odoo/odoo/pull/111708



opw-3126325

closes odoo/odoo#128146

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

Before this commit, the useragent was harcoded as an Odoo one and if it was
blacklisted by the osmfoundation policy https://operations.osmfoundation.org/policies/nominatim/


all Odoo instances were forbidden to access the service.

This parameter allows to override the user agent with a system parameter.

closes odoo/odoo#134131

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

When user access template at the time of export with deleted field.
The traceback will be generated.

To reproduce the issue(any model, here- 'account.move.line'):

- Install 'account_accountant' module
- Go to Settings > Technical > Database Structure > Fields
- Create a new field with model as 'Journal Item' and save
- Go to Accounting > Miscellaneous > Journal Items
- Select any record in list view and click on export and generate a new export
template with newly created field
- Go to 'ir.model.fields' and delete that field
- Go to 'Journal Items' and select that template while export

Error: A traceback appears: KeyError: 'tax_audit'

When a field gets deleted from 'ir.model.fields' but it does not get deleted
from export template. And selecting that template to export the records will
lead to traceback.

See -
https://github.com/odoo/odoo/blob/59669e9943158e51dcbb9ae69ad758df8f7c7976/addons/web/controllers/main.py#L1815-L1818



sentry-4331986723

closes odoo/odoo#129567

Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>

`read_group` signature is not respected: the offset integer param is filled with a list

closes odoo/odoo#134002

Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

closes odoo/odoo#73090

closes odoo/odoo#134086

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Commit 72a17baf force the PO `date_order` to be >= at ` today() to
ensure the select_seller method take the right seller price. This
introduces an error in the MPS module that may need to create PO in the
past.

Instead, this commit patch the call to `_select_seller` to take at least
`today()`

closes odoo/odoo#133759

Opw: 3167094
Related: odoo/enterprise#46623
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

I missed a critical issue in #133708: various users had discovered
they could already fix description issues by adding an XML declaration
to their document which is very cool (though technically not really
valid).

What is a lot less cool is that lxml gets *extremely* unhappy when
asked to parse *strings* with an encoding declaration, raising a
ValueError, so the purported fix breaks on any module which does that,
which seems to include a lot of OCA modules.

Gate the encoding guessing by bailing if the document has an XML
declaration, in which case we just assume the author knows what
they're doing and we leave them alone. For extra safety, check the
encoding declaration in ascii and utf16. Could also have checked for
BOMs, but lxml seems to not care about them overly much (in fact it
seems to prefer them decoded which is odd).

closes odoo/odoo#133918

Reported-by: @rezak400
X-original-commit: 51d37560
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

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#74474

Related: odoo/enterprise#41828
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Formatted emails using our own formataddr contains quotes to correctly
separate name from emails, like'"Name" <email@domain.com'. However
JS parse function does not correctly handle quotes, assuming everything
being left of opening chevron is the name.

Task-2612945 (Mail: Defensive email formatting)

Part-of: odoo/odoo#74474

It seems the commented test make PLS test crash. Not sure why as tests unit
tests should not be dependent but PLS is a complicated matter, flushing
stuff could have an impact on DB state notably.

Until we figure out what happens test that makes the PLS tests crash is
commented. Crashing assert in PLS is improved to better know which one
is crashing.

Task-2612945 (Mail: Defensive email formatting)

Part-of: odoo/odoo#74474

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)

Part-of: odoo/odoo#74474

PURPOSE

Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.

SPECIFICATIONS

As of rfc5322 section 3.4.1 local-part is case-sensitive. However most main
providers do consider the local-part as case insensitive. With the introduction
of smtp-utf8 within odoo, this assumption is certain to fall short for
international emails. We now consider that

  * if local part is ascii: normalize still 'lower' ;
  * else: use as it, SMTP-UF8 is made for non-ascii local parts;

Concerning domain part of the address, as of v14 international domain (IDNA)
are handled fine. The domain is always lowercase, lowering it is fine as it
is probably an error. With the introduction of IDNA, there is an encoding
that allow non-ascii characters to be encoded to ascii ones, using 'idna.encode'.

Also remove usage of 'email_re' in mailing email check. It is too restrictive
compared to real formatting we support (or try to). Valid outgoing emails
were directly canceled, notably when containing unicode.

Task-2612945 (Mail: Defensive email formatting)

Part-of: odoo/odoo#74474

PURPOSE

Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.

SPECIFICATIONS: MAIL COMPOSER IN MAILING

When using the composer with a mailing, it currently skips recipients whose
email is a multi-email due to the strict usage of 'email_normalize'.

We can improve multi-email support by effectively checking for the first
email found, using the "less strict" mode of normalize. It means more emails
are detected as valid, and therefore sent.

Due to lower support of multi-emails when sending emails, this even allows
to send multiple emails as all emails are mailed.

SPECIFICATIONS: DEFAULT RECIPIENTS

Mailings are generally done using default recipients, aka using a model method
that returns the people to mail: customers ('partner_id'), customer emails
('email_from'), specific implementation, ...

This is implementation using '_message_get_default_recipients' that returns
'partner_ids', 'email_to' and 'email_cc' that are then used in the mail
composer to generate final recipients.

In this commit we better handle the content of email fields to avoid issues
with multi-emails. For that purpose we correctly split the content of those
fields. We now have several 'email_to' for records having multi-emails instead
of a single badly-formatted 'email_to'.

Task-2612945 (Mail: Defensive email formatting)

Part-of: odoo/odoo#74474

PURPOSE

Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.

SPECIFICATIONS

Post-message hook is used in various apps to link records to a newly created
created partner. This is the case notably when used with a template as it
creates partner on the fly based on emails to always handle partners.

We now check either the complete 'email', either the normalized version of
it to avoid comparison issues with multi emails and formatted emails. As
'email_normalized' now supports multi-emails by storing the first found one
it helps finding the partner.

Task-2612945 (Mail: Defensive email formatting)

Part-of: odoo/odoo#74474

PURPOSE

Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.

SPECIFICATIONS

Tool method '_mail_find_partner_from_emails' that searches for partners based
on email is improved to support multi-emails input. Instead of skipping
multi-email (current behavior of 'email_normalize') we now consider first
found email in the input.

It is used notably to match incoming email / partners or suggest recipients
in Chatter.

Task-2612945 (Mail: Defensive email formatting)

Part-of: odoo/odoo#74474

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.

Task-2612945 (Mail: Defensive email formatting)

Part-of: odoo/odoo#74474

PURPOSE

Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.

SPECIFICATIONS

When building the final 'from' of outgoing emails using 'formataddr' we
have issues if email contains multi emails or formatted email. Having a
wrongly formatted email in 'email_from' leads to issues as it is badly
recognized by email providers, could be considered as being phishing and
also breaks reply_to mechanism.

Main fix of this commit is to extract emails and rebuild the 'email_from'
based on found emails. 'from' of sent emails is now the first found email
in 'email_from' field of related <mail.mail> record like

  -> before: email_from: '"Raoul" <raoul@raoul.fr>, raoul2@raoul.fr'
  -> after: email_from: '"Raoul" <raoul@raoul.fr>' and raoul2 is ignored

Task-2612945 (Mail: Defensive email formatting)

Part-of: odoo/odoo#74474

PURPOSE

Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.

SPECIFICATIONS

When possible, use 'email_formatted' field on partner, instead of calling
'format_addr'. That way management of corner case input (multi emails and
double encapsulation) is managed by the computed field itself.

When 'format_addr' has to be used, ensure email part is normalized to avoid
formatting issues.

Also use tools to extract emails instead of 'email_re' regex when possible.
That way all code extracting and managing emails go through the same stack.

Task-2612945 (Mail: Defensive email formatting)

Part-of: odoo/odoo#74474

PURPOSE

Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.

SPECIFICATIONS

When building the final 'email_to' of outgoing emails using 'formataddr' we
have issues if email contains multi emails or formatted email. Main fix of
this commit is to extract emails and rebuild the 'email_to' list based on
found emails.

E.g. partner Raoul - email: "Raoul" <raoul@raoul.fr>
 -> before: to: "Raoul" <"Raoul" <raoul@raoul.fr>> (double format)
 -> after: to: "Raoul" <raoul@raoul.fr>

E.g. partner Raoul - email: raoul1@raoul.fr, raoul2@raoul.fr
 -> before: to: "Raoul" <raoul1@raoul.fr, raoul2@raoul.fr>
    single email with multiple emails, depends on server fault tolerance)
 -> after: to: "Raoul" <raoul1@raoul.fr>, "Raoul" <raoul2@raoul.fr>
    multi emails

Fix that computation by using all normalized emails found in 'email' fields
and rebuilding a formatted email based on name + those emails. We do not
use `email_formatted` as it is not really multi-enabled. We prefer a local
defensive approach to be as tolerant as possible with respect to user inputs.

Task-2612945 (Mail: Defensive email formatting)

Part-of: odoo/odoo#74474

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)

Part-of: odoo/odoo#74474

This method is still not really tested, except its override of 'mail.thread.cc'.
So better have a test, especially in CRM that has some specific overrides.
Formatted email and multi-email input are tested, to check their current
support. Next commits will try to improve that, notably avoid formatting
issues.

Task-2612945 (Mail: Defensive email formatting)

Part-of: odoo/odoo#74474