Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge from upstream 16 20241111 01 #1028

Merged

Conversation

royle-vietnam
Copy link
Collaborator

@royle-vietnam royle-vietnam commented Nov 2, 2024

Depends

  • https://github.com/odoo/odoo/pull/186387

I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

ethanrobv and others added 30 commits October 25, 2024 08:42
…e unit calc

**Current behavior:**
Selling a kit bom product will result in inaccurate journal
entries in the stock output and expense accounts, the
amount_currency field will only reflect the price unit of the
kit's components.

**Expected behavior:**
The price unit should reflect the total cost of the components
on the BoM: e.g., if a kit product needs 4 of some component1,
the price unit should be 4 * component1.standard_price.

**Steps to reproduce:**
1. Create a kit product with 2 components, both with qty > 1

2. Assign dropshipping to the kit

3. Create a sale order and confirm -> confirm the purchase order

4. Validate the dropship transfer, invoice the sale order and
post it

5. See the 2 inaccurate journal entries, where the debit/credit
respectively only total to one instance of each component's
cost added together

**Cause of the issue:**
The price unit calculation didn't look at the bom line product
qty, only using the price unit 1 time per component.

**Fix:**
Multiply the value by the quantity of it required on its line in
the BoM.

opw-4253827

closes odoo#183916

Signed-off-by: William Henrotin (whe) <[email protected]>
This completes odoo#171784 by adding support for the same kind of rrule string, but without the `RRULE;` prefix.

Based on Real World™️ evidence.

@moduon MT-7215

closes odoo#185089

Signed-off-by: Arnaud Joset (arj) <[email protected]>
Adds default value to a few required selection fields as currently a
value is apparently set in the form (as the select field will pick the
first value) but without having the value really set in the field,
meaning that on save, the field will appear as invalid.
Also, to be able to select the "almost default" value, you'd need to
select another value then pick the first value again to properly set it
in the field and be able to save the form.

To avoid those issue, we can add a default value to those fields
corresponding to the current "default" value in the form.

closes odoo#184939

Signed-off-by: Steve Van Essche <[email protected]>
Issue:
    - When picking up a SO in POS, the discount on products
    sold with a non groupable UOM disappears.

Steps to reproduce:
    - Create a SO in the sales app.
    - Include a product that has a UOM of which the uom category
     is not grouped in POS (g for example).
    - Add a discount to the product.
    - Pick up the order in POS.
    - Notice that the discount is not applied.

Solution:
    - In `_onClickSaleOrder` I set the discount on the `splitted_line`
     before adding it to the orderline.

opw-4133659

closes odoo#185109

Signed-off-by: Vlad Stroia (vlst) <[email protected]>
When archiving an operation in a bom, currently it will unlink if from
bom lines that had it set as their `Consumed in Operation`.

However, it's not the case for byproducts, meaning that the byproducts
lines will still display the now archived operation.

closes odoo#185093

Signed-off-by: Steve Van Essche <[email protected]>
When having a tax with a specific tax as source account in the
tax mapping of a fiscal position. The mapping does not apply
if the product has a different tax from the tax of the account
and no income/expense account set.

This is because we extend `_get_product_accounts` in `datev`
and replace the default income/expense account by an account
that have the product tax.

With this fix, we replace defualt income/expense accounts only
if we find an account.

Steps:

- Have a FP with an account mapping: 8400 -> 2315
- Have a product P with a different tax from the one set on 8400
  account, and that is not set on any other account
- Create an invoice, set the FP, select the product P
-> Account on the aml is 8400 instead of 2315

opw-4075846

closes odoo#185232

Signed-off-by: Josse Colpaert (jco) <[email protected]>
this commit reverts changes introduced in odoo#183616

During reconciliation when two payment methods (cash and bank) are used simultanosly.
the change amount is incorrectly deducted from the bank payment.
An attempt to resolve this issue introduced further complications with payment amounts.
By creating a single account move, it attempted to deduct the change amount
from the cash payment, which led to inaccurate payment amounts.

opw-4276421

closes odoo#185291

Signed-off-by: Vlad Stroia (vlst) <[email protected]>
Since the introduction of live chat, an arbitrary decision
to open a blank chat window when reloading/navigating away
from the page when the user didn't interract with it was
made.

However, this is disturbing, especially in the chat bot case
where the empty chat window still has the chat bot name as its
title.

Moreover, this chat bot chat window won't trigger the bot answers
if the user interract with it.

This PR removes this blank window behavior and displays the
live chat button instead.

opw-4214093

closes odoo#185313

Signed-off-by: Matthieu Stockbauer (tsm) <[email protected]>
Same issue as odoo#126323 but with CSV, TXT
and other types of files.

This basically overrides the default decoding charset of the email python
module to use utf-8 by default.  As mentioned in the PR above, utf-8 is a
superset of the ascii encoding and this should not cause other issues.

opw-4237114
opw-4245261

closes odoo#185270

X-original-commit: fd8a5e5
Signed-off-by: Julien Castiaux (juc) <[email protected]>
When model selection field is used in a form, its default value is
always one of the available values. Because of this, if the field is
required, it does not force the user to pick a value, but it provides a
possibly incorrect default value.

This commit makes an empty value available for selection if no default
value is chosen.
The behavior is also made available on custom fields, if such an empty
value had been manually created, it will be replaced by this
implementation.

Steps to reproduce:
- Install website_form_project
- Add a form in a page
- Select the "Create a Task" action
- Add the "Analytic Account" field to the form
- Make the field required

=> There was no way to have no default value by default.

opw-4268164

closes odoo#184842

Signed-off-by: Serge Bayet (seba) <[email protected]>
Versions
--------
- 16.0+

Steps
-----
1. Add one or more lines to an SO with the same tax;
2. apply a discount coupon.

Issue
-----
Tax gets mentioned in the discount line name, even though it isn't
really necesarry in this scenario.

Cause
-----
When generating the discount line description, a `tax_desc` gets added
for any tax with a name.

Solution
--------
Only add `tax_desc` if there's more than one discount line being
generated due to multiple taxes.

opw-4072437

closes odoo#183686

Signed-off-by: Valentin Chevalier <[email protected]>
Steps to reproduce:
1. Navigate to Pricelists.
2. Import a CSV or XLSX file that contains at least one product or product
   variant.
3. Duplicate the newly created pricelist.

Issue:
- When duplicating an imported pricelist, the duplicated record does not retain
  the product or product variant information.

Cause:
- If the applied_on field is not provided during the creation of the pricelist
  item, the default value of 3_global is applied.
- As a result, when duplicating the pricelist, the product_tmpl_id and
  product_id fields are set to None.

Fix:
- When the applied_on field is missing during the creation of a new pricelist
  item, set it based on the presence of the relevant fields (such as product or
  product variant).

opw-4170242

closes odoo#185100

Signed-off-by: Victor Feyens (vfe) <[email protected]>
An Odoo server error occurs when attempting to change the main partner, country, sales team (if sales is installed) or document type (if l10n_latam_invoice_document is installed) in a report from the invoice analysis.

Steps to reproduce:

1. Go to Accounting > Reporting > Management > Invoice Analysis.
2. Click on the pivot icon (on the far right).
3. Click on any amount.
4. A list of invoices should appear.
5. Click on any invoice.
6. Change the main partner or country and save.

An Odoo server error would occur

opw-4246387

closes odoo#184505

Signed-off-by: Antoine Dupuis (andu) <[email protected]>
Steps to reproduce:
- Create and confirm an invoice at 2024/10/01 with a line containeing a tax_id
- In journal items, try to "cut-off"

Issue:
You won't be able to do so because of the tax lock date

Cause:
We need the correct accounting date to find back the reference move but before the fix, a side effect was to check for tax lock date which does not make sense in this flow.
We create move line without tax_ids/tag_grid and so it does not impact the tax report:
https://github.com/odoo/odoo/blob/763d54426a1218b827f30fa0323f745c929a3d1d/addons/account/wizard/account_automatic_entry_wizard.py#L242-L271

Solution:
we set the `has_tax` to False to byapss the check. The user, if he wishes, could excatly the same flow by creating an entry "a la mano" <->  We don't need to block this flow

opw-4191527

closes odoo#185078

Signed-off-by: Antoine Dupuis (andu) <[email protected]>
When downloading a url type attachment, it will not open in a new tab
and breaks the activity of the current tab,such as rtc call and
breadcrumbs.

To reproduce the error: Project > Task > click on the url attachment >
open in the current tab, the breadcrumbs (previous filters) will be lost

This commit fixes the issue by opening the url attachment in a new tab.
And "downloading" a url does not make sense, so the download button is
replaced by an open button.

closes odoo#184264

Signed-off-by: Zelong Lin (zel) <[email protected]>
Before this commit :
`is_html_empty` considers empty icons as empty html.

After this commit:
Empty icons are considered as non empty html

Note: changed the tag_re to more performant regex

task-4060037

closes odoo#182642

Signed-off-by: Xavier Morel (xmo) <[email protected]>
Steps to reproduce:
- Install Accounting and l10n_es_edi_tbai
- Switch to a Spanish company (e.g. ES Company)
- In Accounting settings, select "Hacienda Foral de Bizkaia" as
"Tax Agency for TBAI"
- Create a vendor bill:
  * Vendor: [a Spanish vendor]
  * Invoice Lines: (These amounts are important)

      Quantity  |  Price  |  Taxes
    --------------------------------
         2      | 2896.74 |  21% G
         4      |  121.52 |  21% G

- Confirm the bill
- Sent bill to TicketBAI

Issue:
The generated xml will be rejected because "BaseImponible" value has
more than 2 decimals.

Cause:
A floating point issue during the computation of "BaseImponible" with
these specific values.

opw-3987704

closes odoo#170724

closes odoo#184885

Signed-off-by: Josse Colpaert <[email protected]>
Signed-off-by: Antoine Dupuis (andu) <[email protected]>
Steps to reproduce the issue:

1. Activate Italian Localization
2. Create a contact in any country but Italy
3. Assign VAT number starting with 'IT' (Tax ID or Identification Number)
4. Save and receive error:

>     Invalid Codice Fiscale '[VAT number]': should be like 'MRTMTT91D08F205J' for physical person and '12345670546' for businesses.

Explanation:

When `country_id` or `vat` is changing, `_l10n_it_onchange_vat` will try to create a `l10n_it_codice_fiscale` if `res.partner` respects some conditions.
Those conditions are flawed because if `country_id` is not Italy but `vat` starts with "IT", it will enter the condition.

(Kind of a hack: if `country_id` is set after a `l10n_it_codice_fiscale` has been added to `res.partner`, the first condition will not be met but the second will, and `l10n_codice_fiscale` will turn back to False.)

Fix reasoning:

We will only check conditions related to `vat` and `country_id` and always perform changes to avoid inconsistencies where `vat` is no longer correct but `l10n_it_codice_fiscale` did not change and is still valid.

opw-4261959

closes odoo#184406

Signed-off-by: Antoine Dupuis (andu) <[email protected]>
Currently it can happen that slightly changing the amount in (document)
currency (field `amount_currency`) i.e. on a tax line can lead to an
unbalanced move. (See example and "Reproduce" below.)

The issue is the syncing (function `_sync_invoice`) between
- amount in currency (document currency; field `amount_currency`) and
- balance (company currency; field `balance`).

There we update the amount in currency in case the balance is changed
and the amount in currency is not changed.
But this is problematic in case we want (in the same write) set
a different amount in currency but explicitly set the same balance
(and not just not write anything to the `balance` field).
Since we write the same balance it is not detected as a
change and we update the balance based on the amount in currency.
But this should not happen; the balance should be "protected"
from being updated (since it is the value we explicitly want).

This can i.e. cause the balance of the receivable line to receive the wrong value
I.e. consider the following case; with currency rate = 2 (also see "Reproduce" below)

Journal Items:
- product  1: amount in currency = -1000.00 €, balance = -500.00
- product  2: amount in currency =  -200.00 €, balance = -100.00
- tax line 1: amount in currency =  -180.03 €, balance =  -90.02
- tax line 2: amount in currency =   -30.00 €, balance =  -15.00
- Receivable: amount in currency = -1410.03 €, balance =  705.02

And we modify tax line 2: amount in currency = -29.99 €.
Then first we set the correct values because we basically compute the
receivable line by summing the other lines:

Journal Items:
- product  1: amount in currency = -1000.00 €, balance = -500.00
- product  2: amount in currency =  -200.00 €, balance = -100.00
- tax line 1: amount in currency =  -180.03 €, balance =  -90.02
- tax line 2: amount in currency =   -29.99 €, balance =  -15.00
- Receivable: amount in currency = -1410.02 €, balance =  705.02

So we have set the balance to the same as before but changed the
amount in currency. So then we recompute the balance on the receivable
line from the amount in currency due to the syncing (`_sync_invoice`)

Journal Items:
- product  1: amount in currency = -1000.00 €, balance = -500.00
- product  2: amount in currency =  -200.00 €, balance = -100.00
- tax line 1: amount in currency =  -180.03 €, balance =  -90.02
- tax line 2: amount in currency =   -29.99 €, balance =  -15.00
- Receivable: amount in currency = -1410.02 €, balance =  705.01

But now the move is not balanced (the sum of the balances should be 0)
  -500.00 + -100.00 + -90.02 + -15.00 = -705.02 (and not -705.01)

After this commit we "protect" the balance and amount in currency from
being updated by `_sync_invoice` in case the surrounding `write`
sets the balance (`balance`) or amount in currency (`amount_currency`)
respectively.

Reproduce: (c.f. example above)
  1. Select company "My Company (San Francisco)"
  2. Ensure EUR currency is activated and has value 2 unit per USD
     (at the time of the invoice that will be created further below)
  3. Copy the 15% tax
  4. Create a new invoice in EUR with 2 lines
     (1) qty = 1, unit price = 1000, taxes = 15%
     (2) qty = 1, unit price = 200, taxes = 15%, 15% (Copy)
  5. There should be 2 tax lines in the "Journal Items" tab
     (1) amount in currency = -180.00 €, credit = 90.00 USD
     (2) amount in currency = -30.00 €, credit = 90.00 USD
  6. Modify tax line (1); set amount in currency to -180.03 €
     and save.
     The credit will be updated to 90.02 USD.
  7. Modify tax line (2); set amount in currency to -29.99 €
     and try to save
  8. An "Invalid Operation" error is raised:
     The move (Draft Invoice ) is not balanced.
     The total of debits equals $ 705.01 and the total of credits equals $ 705.02.

closes odoo#171705

Signed-off-by: William André (wan) <[email protected]>
…creating accrued revenue entries

Problem:
When using the generate accrued revenue entries action on a sale/purchase order where the first order line is a section or note leads to an invalid account move being created. The move contains a line with not account set.

Purpose of this PR:
To make sure only product lines are taken into account when generating these entries

How to reproduce:
1) Create and confirm a sale order where the first order line is a section or note and the next contains a product
2) Run the Accrued Revenue Entry contextual action
3) Fill the Accrual Account and Amount fields with arbitrary data and hit Create Entry
4) Error appears, a move line is generated with no account

closes odoo#183230

Signed-off-by: Olivier Colson (oco) <[email protected]>
Currently, a traceback occurs when the user deletes a module
which is having a gamification goal record.

To reproduce this issue:

1) Install sale and gamification
2) Create a new gamification challenge record
3) Create a new goal in the gamification challenge
4) Make sure the goal has the definition as `Automatic: sum on a field`
5) Select the model as `account`
6) Uninstall the invoicing module and start challenge of that gamification.

Error:- "KeyError: False"

This is because when the user deletes a module that is used in
the gamification goal, as the model value becomes `False`.

This leads to a traceback as model_id is used for the reference of obj
https://github.com/odoo/odoo/blob/d9603e93d2ab5e0b9fd1948dfd3e3bee20ede599/addons/gamification/models/gamification_goal.py#L164-L165

We can resolve this issue by adding `ondelete='cascade'`
in the field description. Where the record will be deleted
if the corresponding model is uninstalled.
sentry-4089991441

closes odoo#180307

Signed-off-by: Thibault Delavallee (tde) <[email protected]>
Update branding logo and icon in windows installer.

Task-2862802

closes odoo#185650

Signed-off-by: Christophe Monniez (moc) <[email protected]>
Payments initiated by the customer from the payment form could sometimes
lead to multiple charges if a webhook notification would arrive at the
same time as the payment request's response. This is due to the webhook
acquiring a lock in the database when updating the transaction's state,
followed by the processing of the payment request's response trying to
do the same and thus encountering a concurrent access error. The payment
request is thus retried and a new charge is created on Adyen side.

This commit fixes the issue by passing an idempotency key with the
payment request. If a payment request is inadvertently retried, Adyen
silently ignores it and returns the same response as for the initial
request. The response is processed again in Odoo and the customer is
smoothly redirected to the payment landing page.

closes odoo#184919

Signed-off-by: Antoine Vandevenne (anv) <[email protected]>
As VISA added more mandatory fields to perform payments, the holder's
name is required now for the customer to fill when paying with adyen.

opw-4085163

closes odoo#178393

Signed-off-by: Valeriya Chuprina (vchu) <[email protected]>
- Billing officers / HR officers have access to all bank accounts
- Internal users only have access to bank accounts that are not linked to an employee
- Portal/Public users have access to nothing.

closes odoo#184346

Taskid: 3101400
Signed-off-by: Florian Gilbert (flg) <[email protected]>
Currently, when the stock scheduler is run, a new cursor is created and
the result is rolled back even if all tasks succeeded. Even though tasks
themselves are not rolled back because they are run using new other
cursors, rolling it back is not correct and it makes harder to test the
scheduler feature.

The rollback was introduced in da6bd90 by mistake.

This commit makes the transaction to be rolled back only when the
current transaction actually failed.

closes odoo#175621

Signed-off-by: Tiffany Chang (tic) <[email protected]>
Issue found at commit: odoo@0e8f3d5
After the above mentioned commit when using eWaybill with
e-Invoicing the log note of ewaybill i.e.
```
E-wayBill Sent
Number -> 0
Validity -> None
```
where as in the response attachment of eWaybill, the ewaybill number
does exist

In this commit, we resolve the above issue and the correct ewaybill
number gets logged

opw-4280093

closes odoo#185680

Signed-off-by: Josse Colpaert (jco) <[email protected]>
Use normalized emails for comparison to avoid issues linked to
formatting.

Task-4281171: [mail] {email/smtp}_from normalized comparison

closes odoo#185749

Signed-off-by: Thibault Delavallee (tde) <[email protected]>
Steps to Reproduce :
1. Go to Website editor --> Drag and Drop the Image - Text snippet
2. Replace an image of size fore than 10 mb or any image that takes
time to upload.
3. Close the upload media pop-over.
4. Close the uploading media screen as well.
5. Post the buffering screening ---> Traceback occurs.

Specification:

This commit aims to resolve the issue occured while discarding the
upload process the `this.fileInput.el` becomes undefined as image upload
is discarded which resulted in traceback.

task-4255826

closes odoo#183547

Signed-off-by: Benjamin Vray (bvr) <[email protected]>
clesgow and others added 14 commits November 8, 2024 11:29
Before odoo#185966, while the `sequence_code` of the return picking type was
'IN', its sequence was always 'RET'. But since the sequence was always
overwritten with the default 'RET', it went unnoticed.
After that, it now picked the picking type `sequence_code` during update
if it was defined, which means it would end up with a 'IN' sequence as
well, creating duplicate names for pickings as two separate sequences
would overlap.

closes odoo#186462

Signed-off-by: Arnold Moyaux (arm) <[email protected]>
Versions
--------
- 16.0      (sale_product_configurator)
- 17.0      (website_sale_product_configurator)
- saas-17.2 (website_sale_product_configurator)

Steps
-----
1. Have 2 products with variants;
2. for both, add the other as optional product;
3. in eCommerce, add one to the cart;
4. select the other in the product configurator.

Issue
-----
The attributes get messed up due to first product being listed twice in
the wizard, once in the cart, and once as an option for the second
product.

Solution
--------
Front-end:
Get the IDs of the currently displayed product templates, and pass
them to the controller when fetching additional variants.

Back-end:
Before rendering the configurator template, update the cache to
remove the currently displayed products from the added product's
`optional_product_ids` field. Re-add them after rendering is done.

opw-4071002

closes odoo#185103

Signed-off-by: Valentin Chevalier <[email protected]>
… email

Add some tests using ``assertSMTPEmailsSent`` tool in order to assert
current behavior when dealing with formatted / multi emails, notably
when name contains an '@'.

Add some tests for email_formatted field of res.partner, highlighting
issue when name contains an '@'.

Task-3704658

Part-of: odoo#185793
Signed-off-by: Julien Castiaux (juc) <[email protected]>
Outgoing mail.mail are classified by email_from in order to find a
suitable outgoing mail server. This is necessary notably to compute
SMTP From, use a generic notification email from, ...

To be coherent with odoo/odoo@c3d054f in case of multi email in
email_from, better be sure to take the real email_from we are going to
use in emails.

Task-3704658

Part-of: odoo#185793
Signed-off-by: Julien Castiaux (juc) <[email protected]>
When there is an email in the name field, emails are sent twice and
thus may be counted twice in various tooling, introduce unwanted or
extra recipients, ... This happens notably due to odoo/odoo@795091c
combined to odoo#74474 which improved support of multiemails and
formatted emails in various email input.

This notably leads to better formatted email computation on partner
that generates emails like '"[email protected]" <[email protected]>'
when email is used both as name and email. When sending emails to this
partner only a single email should be sent and counted.

When name contains an '@' due to some reason and if it is not the same
as email, we might still send more than one email due to our extracting.
However this implies removing '@' in names, which has proven to be
error prone. When name contains an '@' like Bike@Home, it is considered
as holding an email. Note that even previously to odoo/odoo@795091c it
was considered as an email and is therefore an old limitation of this
function.

Task-3704658

Part-of: odoo#185793
Signed-off-by: Julien Castiaux (juc) <[email protected]>
Due to 'extract_rfc_2822', we should avoid names containing an '@' as
it creates additional emails when parsing it for smtp server. Indeed
when having recipients like '"Bike@Home" <[email protected]>' this function
returns two emails: Bike@Home and [email protected].

A fix has already been done to remove duplicates in that tool (see
previous commits). In this commit we allow to receive a pre-validated
list of emails that restricts emails found by 'extract_rfc_2822'.
When going through classic flows, we already computed emails using
'email_split' and its subtools, hence we just need the encoding
check of 'extract_rfc_2822'. Additional emails found by that tool
are ignored as we consider those are fake emails.

Task-3704658

Part-of: odoo#185793
Signed-off-by: Julien Castiaux (juc) <[email protected]>
…ails

Use cases: send an email to
 "Bike@Home" <[email protected]>  (name containing @)
 "[email protected]" <[email protected]> (result of partner name_create)

When there is an email in the name field, emails are sent twice and
thus may be counted twice in various tooling, introduce unwanted or
extra recipients, ... This happens notably due to odoo@795091c
combined to odoo#74474 which improved support of multiemails and
formatted emails in various email input.

This notably leads to better formatted email computation on partner
that generates emails like '"[email protected]" <[email protected]>'
when email is used both as name and email. When sending emails to this
partner only a single email should be sent and counted.

A fix is been done to remove duplicates in that tool, making the returned
list unique. In this PR we allow to receive a pre-validated
list of emails that restricts emails found by 'extract_rfc2822'.
When going through classic flows, we already computed emails using
'email_split' and its subtools, hence we just need the encoding
check of 'extract_rfc2822'. Additional emails found by that tool
are ignored as we consider those are fake emails.

This PR contains tests and fixes related to that issue as well as multi
and formatted emails management.

Task-3704658

closes odoo#185793

Signed-off-by: Julien Castiaux (juc) <[email protected]>
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

Part-of: odoo#186149
Signed-off-by: Thibault Delavallee (tde) <[email protected]>
Install mass-mailing and crm. Change the email address of Brandon to
`[email protected];[email protected]`. 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: [email protected] and [email protected]. 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

Part-of: odoo#186149
Signed-off-by: Thibault Delavallee (tde) <[email protected]>
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

Part-of: odoo#186149
Signed-off-by: Thibault Delavallee (tde) <[email protected]>
Install mass-mailing and crm. Change the email address of Brandon to [email protected];[email protected]. 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: [[email protected]](mailto:[email protected]) and [[email protected]](mailto:[email protected]). 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 odoo#186149

Signed-off-by: Thibault Delavallee (tde) <[email protected]>
### Contains the following commits:

odoo/o-spreadsheet@fdfa7dc0e [REL] 16.0.54 Task: 0
odoo/o-spreadsheet@a56536c81 [FIX] xlsx: convert #REF at export to xlsx Task: 4207052
odoo/o-spreadsheet@15e588325 [FIX] parser: inconsistent handling of #REF Task: 4207052

closes odoo#186763

Signed-off-by: Rémi Rahir (rar) <[email protected]>
Co-authored-by: Anthony Hendrickx (anhe) <[email protected]>
Co-authored-by: Alexis Lacroix (laa) <[email protected]>
Co-authored-by: Lucas Lefèvre (lul) <[email protected]>
Co-authored-by: Dhrutik Patel (dhrp) <[email protected]>
Co-authored-by: Adrien Minne (adrm) <[email protected]>
Co-authored-by: Mehdi Rachico (mera) <[email protected]>
Co-authored-by: Rémi Rahir (rar) <[email protected]>
Co-authored-by: Pierre Rousseau (pro) <[email protected]>
Co-authored-by: Vincent Schippefilt (vsc) <[email protected]>
@viinbot viinbot added 🚀 Queue 🚀 Building and removed 🚀 Running PR/Commit is done for everything and ready for manually test 🚀 Queue labels Nov 11, 2024
@royle-vietnam royle-vietnam changed the title Merge from upstream 16 20241102 01 Merge from upstream 16 20241111 01 Nov 11, 2024
@viinbot viinbot added 🚀 Queue 🚀 Building 🚀 Running PR/Commit is done for everything and ready for manually test and removed 🚀 Building 🚀 Queue labels Nov 11, 2024
@viinbot
Copy link

viinbot commented Nov 11, 2024

@royle-vietnam Viindoo Test Suite has passed!

@royle-vietnam royle-vietnam merged commit 9738322 into Viindoo:16.0 Nov 11, 2024
1 check passed
@royle-vietnam royle-vietnam deleted the merge_from_upstream_16_20241102_01 branch November 11, 2024 11:36
@viinbot viinbot added 🚩 Done PR/Commit is finished manually test and closed instance and removed 🚀 Running PR/Commit is done for everything and ready for manually test labels Nov 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🚩 Done PR/Commit is finished manually test and closed instance
Projects
None yet
Development

Successfully merging this pull request may close these issues.