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

X-original-commit: 160e8bfb
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>

Current behaviour before commit:

-When pasting copied content from editor inside
link inserts text with HTML content, in result
the pasted content seems isolated from the link.

e.g. <a href="#">te[]st</a>
	+ pasting <h1>123</h1>  <=>
	<a href="#">te<h1>123</h1>st</a>

Desired behaviour after commit:

-Now only text content is pasted which makes
pasted content as a part of the link.

e.g. <a href="#">te[]st</a>
	+ pasting <h1>123</h1>  <=>
	<a href="#">te123st</a>

closes odoo/odoo#134294

X-original-commit: db6d65a4
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

Current behavior:
  If you set a specific sale_order_item for an employee on a project, and
  create a timesheet line from the "My Timesheets" menu,
  the sale_order_item will not be the one you selected for this employee.
  This happens because when you create a timesheet line from the "My
  Timesheets" menu, the employee is not set on the timesheet line.
  To fix this we fallback on the user's employee when creating a timesheet
  line from the "My Timesheets" menu.

Steps to reproduce:
  - Make sure you'r logged in as Mitchel Admin
  - Create a service product that create project and tasks
  - Create a sale order with this product
  - Go to the project and set a sale order item for Mitchel Admin in the
    invoicing tab
  - Go to the "My Timesheets" menu and click "Add Line"
  - Select the project you created
  - The sale order item will not be autofilled with the one set on the
    invoicing tab of the project.

opw-3463849

closes odoo/odoo#133532

X-original-commit: ba0d428a
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>

Since [1], it was no longer possible to refresh the page and stay in
the backend at the same time. This was known at the time and was an
accepted downside.

However, with this commit, a compromise has been found, if the keyboard
shortcut for a refresh (CTRL-R or F5) is used while the Website Preview
is shown (mounted), then the website preview will do its best to keep
the user inside the backend.

This will make developing features for the website modules easier, as
before, every refresh would require an extra click to return to the
backend.

To note: the debug=[mode] param would also be lost
on refreshing a website page. Starting 16.4, since [2], this would make
tracebacks harder to read as for every refresh, they would no longer
point to the source, rather just the minified file. Therefore, with
this commit, we also keep the debug mode in the URL when doing a
keyboard refresh.

[1]: https://github.com/odoo/odoo/commit/1c18b79972c3b0a97197b98390e0ba9fda703585
[2]: https://github.com/odoo/odoo/commit/59f49d6a8c856a5d8ca28dcfd7840baaa1c7672f



task-3458691

closes odoo/odoo#131236

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

When a user tries to create a leave request without linking an employee
with the user and without a configured login user timezone, a traceback
will be generated.

Steps to reproduce:
- Install the "hr_holidays" module.
- Create a new user, e.g., "Test user", and login with another browser.
- Login as an admin user and go to Settings > Users & Companies.
- Search for "Test user" and set Timzone as empty.
- Go to the Time Off menu and create a leave request; after that, a traceback
will be generated.
Error: AttributeError: 'bool' object has no attribute 'upper' 

When a user tries to create a leave request without linking an employee with the
user and without a configured login user timezone, the
_get_start_or_end_from_attendance() function of the "hr.leave" object will call
at that time timzone not getting.
Code reference:
https://github.com/odoo/odoo/blob/15.0/addons/hr_holidays/models/hr_leave.py#L111



Sentry-4441512696

closes odoo/odoo#134208

X-original-commit: 2b0f9e39
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>

There was inconsistency in the translation for the words "price unit", with this
 commit all the "price unit" are translated the same.

closes odoo/odoo#134107

Task-id: 3262408
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>

This PR solve two things:
- Preview: due to the hardcoded width the preview didn't take all the page and
was push on the left.
- PDF: Weird stuff happened with the header, he was hiding information below
 the header.

Task-id: 3262408
Part-of: odoo/odoo#134107

Before this PR, when there is no shipping address, the pdf show an empty
"Shipping Address" header. By changing the colspan dynamically we can manage to
keep the layout like it was and remove the useless section.

Task-id: 3262408
Part-of: odoo/odoo#134107

Steps to reproduce:
- Set "To Check" for a bill in the Bill list view
- go back to the dashboard

Issue:
There won't be the "To Check" shortcut as it was the case in 15.0

opw-3455414

closes odoo/odoo#133296

Signed-off-by: William André (wan) <wan@odoo.com>

The name field was previously optional when adding a new instance
from the tree view, which in the absence of a name, 'false' is indicated
in the calendar view. The field is now set as mandatory.

closes odoo/odoo#132772

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

Have a list view with a many2many field, and an onchange on a
field in the list that returns a command 5 (CLEAR, or DELETE_ALL
in the js terminology). Before this commit, the command 5 was
mapped to a list of commands 2 (DELETE), i.e. all records in the
many2many relation were deleted when the record was saved. We
instead want those records to be removed from the relation, i.e.
the command 5 should be mapped to a list of command 3 (UNLINK, or
FORGET in the js terminology).

Note that this only impacts list and kanban views, as the form
view still used the BasicModel.

Issue reported here https://github.com/odoo/odoo/commit/48ef812a635f70571b395f82ffdb2969ce99da9e#r126483773



closes odoo/odoo#134318

Signed-off-by: Francois Georis (fge) <fge@odoo.com>

Issue:
When uploading a large custom module via studio for importing, Chrome
crashes with an internal SIGKILL and Firefox manages to load, but is
really sluggish.

Steps to reproduce:
- Install Studio
- In the Apps Dashboard > Customizations > Import
- Upload a large custom module (50 MiB)
- Chrome crashes, while on Firefox the page is sluggish

Cause:
In the module `base_import_module`, the `module_file` doesn't have a
corresponding `filename`, therefor the name used to be displayed in
the wizard is the content of the binary file in base64 encoding...
For a module that is of a large size, this is a *gigantic* string
that crashes Chrome and slows down the DOM on Firefox.

Fix:
Truncate the maximum filename that is displayed in the template to
the max length necessary to encode in base64 (0xFF) 255 bytes, as
255 bytes is the maximum filename size on Linux/Windows/MacOS.

Affected versions:
16.0 up to master

Reference:
opw-3491998

closes odoo/odoo#134165

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

Steps to reproduce:
-------------------
- go to Appraisal app;
- click on Activity button;
- schedule an activity if there is none;

Issue:
------
A traceback occurs.

Solution:
---------
Add luxon library to context.

Note:
-----
Backport of commit:
e602a555

opw-3488028

closes odoo/odoo#134101

Signed-off-by: Florent Dardenne (dafl) <dafl@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#134188

Forward-port-of: odoo/odoo#134143
Forward-port-of: odoo/odoo#74474
Related: odoo/enterprise#46828
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)

X-original-commit: odoo/odoo@8694ff1e2ebcf79b0f3f9e26984df9388203b687
Part-of: odoo/odoo#134188

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@b2f3f0f3e13cef993541bcd093e61ffbb6a8c92e
Part-of: odoo/odoo#134188

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)

X-original-commit: odoo/odoo@a70327daaf3b88af887f657c222222e7baec29c1
Part-of: odoo/odoo#134188

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)

X-original-commit: odoo/odoo@516ccbc9e716b887cbf712c72af37fd2a3c7dbe9
Part-of: odoo/odoo#134188

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)

X-original-commit: odoo/odoo@62f28f1b898ff9f37bb74345a814e83b37386181
Part-of: odoo/odoo#134188

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)

X-original-commit: odoo/odoo@b8458b092089245c5123f272e4b772beb9b387ed
Part-of: odoo/odoo#134188

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)

X-original-commit: odoo/odoo@bafc060f639539475abf06221ab590637e6fb8dc
Part-of: odoo/odoo#134188

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)

X-original-commit: odoo/odoo@441746d0119b72125b0338f5cfb97db0b10c399c
Part-of: odoo/odoo#134188

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)

X-original-commit: odoo/odoo@9ef715fb994564af9e933ba31933a09eca97c24f
Part-of: odoo/odoo#134188

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)

X-original-commit: odoo/odoo@0058013c86231fc608f1324bc03586e3764760fe
Part-of: odoo/odoo#134188

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@853bb98b81bcc6376c7f468391643306aea25d99
Part-of: odoo/odoo#134188

When having several possible emails to contact the first one is saved on the
trace model. Indeed a trace is normally linked to a unique recipient but
in case of multi-emails in an email field, several emails are available.

This commit ensure computation keeps the original mail_to when making emails
adresses uniques before sending mails and creating traces.

Followup of odoo/odoo@213d5d396c811d8e07ce928c0d31a7f47756a644

Task-2612945 (Mail: Defensive email formatting)

X-original-commit: odoo/odoo@1ef74dc6a730b4bc2936bf0abf02f96fdd97cf8e
Part-of: odoo/odoo#134188

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)

X-original-commit: odoo/odoo@340c362798b1cdb2ddb171de385bca45677724af
Part-of: odoo/odoo#134188

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@afcb7349083c669dbda18b9b1955eabbe14ea675 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@6e0b1a318447ffef3857c9fd5c975108a1c3944e
Part-of: odoo/odoo#134188

Add 'id' in partner ordering, to be sure searching on duplicated partners is
deterministic.

In mail, use standard ordering when searching on users to be deterministic.
As ordering on users is based on name then login which is unique, this is a
safe ordering and can be used as it.

Task-2612945 (Mail: Defensive email formatting)

X-original-commit: odoo/odoo@24f3c99ab83d38b30c96f391af96cd6999fbba82
Part-of: odoo/odoo#134188

MailTemplate model has a 'partner_to' field is dynamically rendered to contain
partners being recipients. After rendering it should hold a comma-separated
list of partner IDs.

However as we are unsure it was correctly written better be defensive. We now
check that we can effectively transform items to IDs using 'isdigit()'.

Task-2612945 (Mail: Defensive email formatting)

X-original-commit: odoo/odoo@f96834b402214a8f51900d26c5845703b81c7501
Part-of: odoo/odoo#134188

Steps to reproduce:
- set a tax lock date
- create a new move
- set the accounting date prior to the tax lock date
- set an invoice_line with a tax

Issue:
The banner teeling you information about the tax lock date won't appear unless the move is created.

opw-3370727

closes odoo/odoo#134259

Signed-off-by: William André (wan) <wan@odoo.com>

When sending an bill to sii services, the registration
date is set as today, instead of the accounting date.
This is because the registration date is automatically
set to today when sending the bill.

With this commit, we add registration_date field
to teh account_move view in other infos tab, to allow
the user to manually set it.

Steps:

- Install l10n_es_edi_sii
- Set a tax agency in Accounting > Configuration > Settings
- Create a bill, with date and accounting date in the past
- Confirm and send to sii services
-> In the file, 'FechaRegContable' is set to today

opw-3478079

closes odoo/odoo#134173

Signed-off-by: Josse Colpaert <jco@odoo.com>

When having a payment terms with several lines,
the payment term lines are not displayed when
printing the invoice if this one has been
partially paid.

opw-3482256

closes odoo/odoo#133934

Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>

When having an attachment to the qr-bill report,
an error is raised when printing the report:
"the report's template does not contains the
 attributes 'data-oe-model' and 'data-oe-id' on
the div with 'article' classname."

Steps:

- With a Swiss company
- Activate QR code on customer invoices
- Go to Settings>Technical>Reports and select QR-bill
- In Advanced Properties tab, set an attachment
- Create an invoice for a swiss customer, confirm
  and print the QR-bill
-> Error

We this commit, we simply add oe-data-model and
oe-data-id to the div with the article class
in the template, as indicated in the error message.

opw-3480179

closes odoo/odoo#133703

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

Before this commit, when the browser was offline and when an attempt
to make a RTCPeerConnection was made, a traceback was raised by
firefox:

> InvalidStateError: Can't create RTCPeerConnections when the network is
> down

This commit prevents the creation of the RTCPeerConnection when the
browser is offline.

task-3186872

closes odoo/odoo#134207

X-original-commit: 8f9a3e1e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

Before, when instatating the interfaces if there was an error inside
Odoo could stop. This PR prevents that and simply avoids instantiating
the interface which causes the error.

closes odoo/odoo#133872

X-original-commit: e8f700f7
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>

For mysterious or logical reasons, the test classes inherit
the test tags from each other.  This means that the TBai external
test will have the post_install_l10n tag inherited and are currently
run when staging.  It should not block our staging when they are
down, ... by accident.

https://runbot.odoo.com/runbot/build/50405024



closes odoo/odoo#134168

Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

Issue:
------
The `date` field of the `hr.attendance.overtime` model
records is not the date of the related leave.

Cause:
------
We use: `fields.Date.today()` instead of the leave field `date_from`.

Solution:
---------
Use `date_from` field of `leave`.

opw-3433480

closes odoo/odoo#134099

X-original-commit: b82a3383
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>

Steps to reproduce:
- Create a PO (fifo automated product)
- Recieve product
- Create the bill and add the landed cost product to it
- Create the landed cost before posting the bill
- Post the bill

Bug:
when creating the landed costs if the bill is already posted
the created amls are reconciled otherwise they aren't

Fix:
reconcile the landed costs amls after posting the bill

opw-3377088

closes odoo/odoo#134170

X-original-commit: 07666e46b658dd9c55abfcd2d94f1c033ac9c04f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>

from the last commit (https://github.com/odoo/odoo/pull/133986

)
 we not allow pi user to execute timesyncd script

This fix allow pi user to execute timesyncd script at the boot

closes odoo/odoo#134145

Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>