closes odoo/odoo#134469

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

As a good pratice, in compute method, we assign a default value before
we do the actual calculation to avoid issues like no value is assigned
for fields with required=True. For example `reservation_state`:
https://github.com/odoo/odoo/blob/7ebc8cc5771d069b32722d493dd0ae5341e54c96/addons/mrp/models/mrp_production.py#L572
However, since workorder state is depends on this field:
https://github.com/odoo/odoo/blob/7ebc8cc5771d069b32722d493dd0ae5341e54c96/addons/mrp/models/mrp_workorder.py#L158-L159


For some reason, this unexpected false value can lead to some transit
wrong state in tests (it happens when you run the test, but correct
state show when you put a breakpoint and step into each state
computation).
To solve it, we remove this default value assignment. It should be safe
since this field is not required.

closes odoo/odoo#134264

Related: odoo/enterprise#46875
Signed-off-by: Steve Van Essche <svs@odoo.com>

For the JPK and the EDI, a lot of additional informations are needed.
We provide them in community, so it's available later for EDI.

The delivery date is needed in Poland, and we compute it if
sale_stock is installed. It will be done later for all localizations,
but not in stable, so we will merge it with the other ones later.

closes odoo/odoo#115225

Related: odoo/enterprise#38166
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

Some taxes and tax report lines are needed for the export of JPK
(and EDI that will be done later)

Part-of: odoo/odoo#115225

Made the modal for add to cart to be the same when in Grid view and list
view. We achieve this by modifying the css inside
`#products_grid.o_wsale_layout_list`.

opw-3235969

closes odoo/odoo#133439

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

Before this commit, the stale document detection was imprecise and
incomplete.

The stale document could happen in different scenario:
1)  Client B save when client A is disconnected (therefore client A
    should be notified that the document is stale upon reconnection):

    - For that scenario, the code had a heuristic to detect if the
    internet connection disconnected and reconnected but was imprecise
    as the browser api is not 100% reliable on all browser and
    platforms. That made the code under-checking or over-checking with
    the server.

2)  The user has not yet focused on the element and before this
    commit, the stale document was not detected.

3) If there is a partition in the peer to peer network and a member of
   another partition that save, all other partition will not be aware
   that they are working on a stale document.

4) The stale document happen before 2 peers could be fully connected.

For any of those scenarios, if a stale document was not detected and
the user tried to save changes, only then, a popup would inform that
the version was stale. And if the user closed the tab thinking the
document would automatically save, the change would not be saved
(without warning).

This commit:
1) improve detection of stale document
To detect the document this commit add a message in the odoo bus.bus
for the channel of the record for each write. That will ensure the
message to be received as soon as a user is connected to odoo.

2) improve recovery from stale document
Before this commit, the recovery was only made from the server.

As a detection is now direct (rather than delayed by the previous
heuristic), a document could be detected stale before receiving a step
that would not make it stale. Therefore, we cannot just reset from the
server as a recovery mechanism.

To recover, this commit first tries to reset from missing steps from
all peers. If unsuccessful, it will tries to reset from a snapshot. If
unsuccessful, it will reset from the server.

3) add a mechanism for aborting requests
To prevent unexpected concurrency behavior, this commit add a mechanism
to abort requests.

4) a framework for testing the collaboration of the wysiwyg
As it could be quite tedious and error prone to manually tests
concurrency issues related to the wysiwyg, this commit add a framework
for testing the collaboration of the wysiwyg and test the detection
and recovery of stale document.

task-3217965

closes odoo/odoo#128847

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

In a subsequent commit, we need to change the content of the method
`_getNewPtp` and to patch it in tests.

To make that commit more readable by understanding which lines
changed, this commit moves the creation _getNewPtp to the Wysiwyg
prototype rather in a closure.

task-3217965

Part-of: odoo/odoo#128847

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

X-original-commit: 5eee4b32c2992253456e18855b6c777bb707c7e9
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Jinjiu Liu (jili) <jili@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#134487

X-original-commit: 7b635c00
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>

When stock is uninstalled, the sequences used in the warehouses for the
picking types are kept. However, since [1], picking types cannot be
duplicated anymore. When the module is re-installed, the picking types
are created with the same name, which is not allowed by [1].

[1]: https://github.com/odoo/odoo/commit/9034602a028fb22fbd139cf41a2f5c71d9d8d032



opw-3484352

closes odoo/odoo#134032

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

The problem was that if you have multiple stripe payment providers in
different companies, it may cause issues in getting the stripe payment
provider. That was because of using sudo in
calling `_get_stripe_payment_provider`.

The solution is to filter the result based on the company.

opw-3473577

closes odoo/odoo#133578

Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>

When calling track_prepare, an important part of the logic is getting
description in fields_get. We actually don't need the description,
fields_get is mainly use here to check for groups, but the dictionnary
is immediately transformed to a set making values irrelevant.

The same optimisation is done in _message_track, usefull to avoid an
additionnal query in test_recurring_order_creation_perf, because of a
value not in cache.

closes odoo/odoo#132950

Related: odoo/enterprise#46997
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>

This PR fixes the display of remaining days that wasn't correctly displayed when an allocation
had no time limit.
task-3414291

closes odoo/odoo#127553

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

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

closes odoo/odoo#134403

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

To reproduce
============
- login as Mitchell Admin
- change the email of a portal user, ex: Joel Willis, to the same email
as Mitchell Admin. Do this through the Contacts App
- always connected as Mitchell Admin, create a sale order and send it by
email to client, in chatter the sender will be Joel Willis

Problem
=======
when setting the author, `_mail_find_partner_from_emails` is called, when searching
for users with the given eamil, two results are found and the first one
is taken as author

Solution
========
give the priority to the current user when it matches the given conditions

opw-3455520

closes odoo/odoo#134389

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

Set Default UoM on Timesheet Settings page: Hours
Set [Employee] Timesheet Cost (HR Settings tab): 65.00/hour
Create a product [TEST] as follows:
- Product type: service
- Invoicing Policy: Based on Timesheets
- Create on Order: Project & Task
- Unit of Measure: Days
- Purchase UoM: Days
- Sales Price: 1.00
- Cost: 0.00
Create a sales order
Add an order line with product [TEST], quantity 1
Confirm. Project and task will be created
On the task add a 1 hour timesheet entry for [Employee]
Save and go back to the SO

Issue: SO line cost is incorrectly computed.

opw-3378688

closes odoo/odoo#134380

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

This commit makes the clear button of the toolbar always visible
even if no style is applied.

Since the display is controlled by the css, we removed the concerned
style.

Task-3459819

closes odoo/odoo#134098

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

Before this commit when you copy a chatbot script, the triggering answer are mixing.

- Create a chatbot
- Create a line A - question ligne with one response 1
- Create a line B - type text
- Create a line C - type text
- Save
- Invert line B and C
- on ligne C add response 1 in triggering answer
- Save
- Copy the script
--> Issue the response 1 in triggering answer is now in line B

closes odoo/odoo#133924

Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

Before this commit:
- There is a bug in odoo enterprise.
project.project form view > invoicing notebook > services created using create and edit
should be configured by default with an 'invoicing policy' set to 'based on timesheets'.
Technically, while we're using 'default_service_policy' with the right value, we're
getting a different value in the form.

After this commit:
- The bug is fixed.

closes odoo/odoo#134423

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

Before this commit, the push to talk key was not correctly
captured. Indeed, Alt/Control/Shift/Meta was condifered
twice when present, resulting in an incorrect HotKey registration.

Steps to reproduce:
- Go a discuss channel
- Access the call setting menu
- Try to set your push to talk key to "Ctrl + Alt"
- The HotKey is incorrect ("Ctrl + Alt + Alt").

task-3058665

closes odoo/odoo#134422

X-original-commit: 04683033190acc55ee338217367e31494b070bcc
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

task-3429069

closes odoo/odoo#128731

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

Remove old code that was useful when the form view had 2 modes (edit/readonly)

TASK ID: 3272520

closes odoo/odoo#133426

Signed-off-by: Florent Dardenne (dafl) <dafl@odoo.com>

This error occurs when recurrence_id has no records when the user tries to
delete the sync calendar which has recurrent events.

Error: 'Expected singleton: calendar.recurrence()'

See-
https://github.com/odoo/odoo/blob/15.0/addons/calendar/models/calendar_event.py#L715



sentry-4367276387

closes odoo/odoo#134407

X-original-commit: 6ba4a671
Signed-off-by: Arnaud Joset (arj) <arj@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#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