Merge from upstream 16 20241111 01 #1028
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…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]>
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
added
🚀 Queue
🚀 Building
and removed
🚀 Running
royle-vietnam
changed the title
viinbot
added
🚀 Queue
🚀 Building
🚀 Running
|
@royle-vietnam Viindoo Test Suite has passed! |
viinbot
added
🚩 Done
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Depends
https://github.com/odoo/odoo/pull/186387I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr