It is faster to check first if the emails are empty than to look them up
inside the optout/done lists. But frankly this commit is only here to
simplify the diff with the next commit.

Task-3927361

X-original-commit: d38aeef
Part-of: #186799
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>

Install mass-mailing and crm. Change the email address of Brandon to
`a@example.com;b@example.com`. In the list view of crm, add the select
all leads and change their customer to Brandon (the customer column is
not displayed by default, just make it visible). Create a new mass-
mailing with the recipient list as "Lead/Opportunity". Start the
campaign. Brandon receives as many emails as there are leads but he
shall only receive one.

The system has a known limitation when it comes to filtering duplicates:
it skips all records that have multiple recipients. In this case Brandon
has two: a@example.com and b@example.com. The de-duplication mechanism
was skipped for every lead he was the customer of and each time a new
email was sent, spamming him.

In this work we make it possible to also process records with multiple
recipients. It is a best-effort and will still let some duplicates
through. Nonetheless it solves the current problem with minimal changes.

Note: `any([])` and `any([''])` are both False while `all([])` is True,
hence we now check for empty list / empty email first otherwise an empty
list would be considered to be opt-out instead of empty.

Task-3927361

X-original-commit: 66b9b43
Part-of: #186799
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>

The `_get_done_emails` and `_get_optout_emails` are returning normalized
emails, hence we should compare the normalized email address of the
recipient against those lists.

Enforced the normalization, email normalisation is fast and idempotent,
there is no problem (nor functional-wise, nor performance-wise) to
re-normalize those emails.

Task-3927361

X-original-commit: 0819a81
Part-of: #186799
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>

Install mass-mailing and crm. Change the email address of Brandon to a@example.com;b@example.com. In the list view of crm, add the select all leads and change their customer to Brandon (the customer column is not displayed by default, just make it visible). Create a new mass-mailing with the recipient list as "Lead/Opportunity". Start the campaign. Brandon receives as many emails as there are leads but he shall only receive one.

The system has a known limitation when it comes to filtering duplicates: it skips all records that have multiple recipients. In this case Brandon has two: [a@example.com](mailto:a@example.com) and [b@example.com](mailto:b@example.com). The de-duplication mechanism was skipped for every lead he was the customer of and each time a new email was sent, spamming him.

In this work we make it possible to also process records with multiple recipients. It is a best-effort and will still let some duplicates through. Nonetheless it solves the current problem with minimal changes.

Note: any([]) and any(['']) are both False while all([]) is True, hence we now check for empty list / empty email first otherwise an empty list would be considered to be opt-out instead of empty.

Task-3927361

closes #186799

Forward-port-of: #186149
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>

Install mass-mailing and crm. Change the email address of Brandon to a@example.com;b@example.com. In the list view of crm, add the select all leads and change their customer to Brandon (the customer column is not displayed by default, just make it visible). Create a new mass-mailing with the recipient list as "Lead/Opportunity". Start the campaign. Brandon receives as many emails as there are leads but he shall only receive one.

The system has a known limitation when it comes to filtering duplicates: it skips all records that have multiple recipients. In this case Brandon has two: [a@example.com](mailto:a@example.com) and [b@example.com](mailto:b@example.com). The de-duplication mechanism was skipped for every lead he was the customer of and each time a new email was sent, spamming him.

In this work we make it possible to also process records with multiple recipients. It is a best-effort and will still let some duplicates through. Nonetheless it solves the current problem with minimal changes.

Note: any([]) and any(['']) are both False while all([]) is True, hence we now check for empty list / empty email first otherwise an empty list would be considered to be opt-out instead of empty.

Task-3927361

closes #188449

Forward-port-of: #186799
Forward-port-of: #186149
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Install mass-mailing and crm. Change the email address of Brandon to a@example.com;b@example.com. In the list view of crm, add the select all leads and change their customer to Brandon (the customer column is not displayed by default, just make it visible). Create a new mass-mailing with the recipient list as "Lead/Opportunity". Start the campaign. Brandon receives as many emails as there are leads but he shall only receive one.

The system has a known limitation when it comes to filtering duplicates: it skips all records that have multiple recipients. In this case Brandon has two: [a@example.com](mailto:a@example.com) and [b@example.com](mailto:b@example.com). The de-duplication mechanism was skipped for every lead he was the customer of and each time a new email was sent, spamming him.

In this work we make it possible to also process records with multiple recipients. It is a best-effort and will still let some duplicates through. Nonetheless it solves the current problem with minimal changes.

Note: any([]) and any(['']) are both False while all([]) is True, hence we now check for empty list / empty email first otherwise an empty list would be considered to be opt-out instead of empty.

Task-3927361

closes #188426

Forward-port-of: #186799
Forward-port-of: #186149
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Install mass-mailing and crm. Change the email address of Brandon to a@example.com;b@example.com. In the list view of crm, add the select all leads and change their customer to Brandon (the customer column is not displayed by default, just make it visible). Create a new mass-mailing with the recipient list as "Lead/Opportunity". Start the campaign. Brandon receives as many emails as there are leads but he shall only receive one.

The system has a known limitation when it comes to filtering duplicates: it skips all records that have multiple recipients. In this case Brandon has two: [a@example.com](mailto:a@example.com) and [b@example.com](mailto:b@example.com). The de-duplication mechanism was skipped for every lead he was the customer of and each time a new email was sent, spamming him.

In this work we make it possible to also process records with multiple recipients. It is a best-effort and will still let some duplicates through. Nonetheless it solves the current problem with minimal changes.

Note: any([]) and any(['']) are both False while all([]) is True, hence we now check for empty list / empty email first otherwise an empty list would be considered to be opt-out instead of empty.

Task-3927361

closes #188469

Forward-port-of: #186799
Forward-port-of: #186149
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>

Not sure why odoo#186799 used a super complicated lookup and matching with
inconsistent types just to find the recipient for the subtest, or why
it was replaced by something straightforward in odoo#189071 but that was
never backported.

In 3.13 this triggers a warning from the ORM, not sure why not
before (can't see anything in the changelog, but it might be from a
side-effect e.g. `locals()` ordering changed and now a non-empty dict
is tested before we find our target recipient, or since
`BaseModel.__eq__` ignores falsy objects maybe a dict which was falsy
in previous versions isn't anymore).

Not sure why #186799 used a super complicated lookup and matching with
inconsistent types just to find the recipient for the subtest, or why
it was replaced by something straightforward in #189071 but that was
never backported.

In 3.13 this triggers a warning from the ORM, not sure why not
before (can't see anything in the changelog, but it might be from a
side-effect e.g. `locals()` ordering changed and now a non-empty dict
is tested before we find our target recipient, or since
`BaseModel.__eq__` ignores falsy objects maybe a dict which was falsy
in previous versions isn't anymore).

Part-of: #219270
Related: odoo/enterprise#90352
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>