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

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

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

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

For some reason, “New” has been translated as “Nieuw” in Bulgarian, but
this is not Bulgarian, this is Dutch.

This commit replaces all occurrences of “Nieuw” with “Нов”, which is the
correct translation for “New” in Bulgarian.

closes odoo/odoo#133582

Related: odoo/enterprise#46542
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>

If you have some leads which are nearly always won or lost, you may
end with a probability which is either 0% or 100%.
These values indicate that the lead is lost or won, therefore we must
check the limit values.

opw-3413206

closes odoo/odoo#128237

Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>

This query count is failing randomly in 14.0 and 15.0

Disabling the test waiting for a proper investigation or branch eol.

runbot_error-14447

closes odoo/odoo#123056

Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>

Purpose:
The purpose of this commit is to change the current behavior of days to close
graph generating from customizable desk demo data.

Specification:
For the opportunities, the day_close field is a compute field depending upon the
date_closed field. For the customizable desk demo data, the date_closed field
pre-existed, due to that customizable desk opportunity was not won or lost but
the graph report was generated.
so, this commit fixes the current behavior for customizable desk opportunity.

Task-3278039

closes odoo/odoo#119292

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

When converting a lead to an opportunity and merging with existing
opportunities, the list view showing opportunities is very tiny.

This is caused by the field not having the correct colspan, as its label is
hidden with the "nolabel" attribute.

This commit fixes it by assigning a colpan of 2.

Task-3179173

closes odoo/odoo#119215

Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>

Steps to reproduce:

- Install crm
- Go to settings and activate leads in crm.
- Go to leads list and select any lead, now mark it as lost.

Issue:

It will ask for lost reason. But if we do it from the Leads form view,
we don't get to set any reason. I discussed with the PO and we don't
want to add the lost reason in the leads.

Solution:

Modified action of lost so it takes leads into account.

opw-3119748

closes odoo/odoo#111226

Signed-off-by: Maruan Aguerdouh Mohtar (magm) <magm@odoo.com>