Odoo Changelog — 2024-11-28

Thursday, November 28, 2024

37 changes · saas-17.4

Bug Fixes(3)

Resolved issues and error corrections

[FIX] mrp: restore the previous chatter behavious in BoM's

Coresaas-17.4mrp

Documents added in a Bill of Materials chatter are no longer incorrectly copied to related products or other Bills of Materials. This restores the previous behavior so attachments stay with the intended BoM, reducing confusion when products have multiple BoMs.

Original PR description

In 85bf63d028ffff3dd7eeda186cc32f9ae7d09a60, the BoM chatter behavious was modified to add the document added there on the product/product template of the BoM.

This is not correct as if a product has multiple BoM's, it'll add it to all BoM's and on the product.

opw-?

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

#bill of materials#attachments#chatter

[FIX] website: fix website_form_editor tour

PR #188556

Coresaas-17.4website

This update corrects an automated website form editor test by removing an unintended extra setting. It helps keep quality checks reliable without changing the website experience for users.

Original PR description

With this PR [1], unfortunately an extra parameter `isCheck` was introduced in the tour. This commit removes that unusual parameter.

[1]: https://github.com/odoo/odoo/pull/168474

runbot-107873


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

#website#testing#form editor

[FIX] social_linkedin: correct parsing of post statistics response

PR #72491

Enterprisesaas-17.4social_linkedin

This fix restores accurate fetching of engagement data for LinkedIn posts in Social Marketing. Users can now see like information on LinkedIn stream posts as expected, improving visibility into campaign performance.

Original PR description

Reproduce
---

- -i social
- Social Marketing -> Add Stream
- Add post -> give it a like on linkedin
- BUG: Like information not fetched

opw-4190850

#linkedin#social marketing#post statistics

Other(34)

Miscellaneous changes

[FW][FIX] account_peppol: Fix bad write override in case of multiple records

PR #189072

Coresaas-17.4account_peppol

When the write is called with multiple companies (like the test TestAccountComposerPerformance), the values are updated with the values of the very first company. This will write a new peppol_endpoint on all companies. However, in this test, the very first company is a BE one but another is FR. Then, this write makes an inconsistency between the original FR EAS and the new BE endpoint. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of:

Original PR description

When the write is called with multiple companies (like the test TestAccountComposerPerformance), the values are updated with the values of the very first company. This will write a new peppol_endpoint on all companies. However, in this test, the very first company is a BE one but another is FR. Then, this write makes an inconsistency between the original FR EAS and the new BE endpoint.

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

Forward-Port-Of: odoo/odoo#188985

In 85bf63d028ffff3dd7eeda186cc32f9ae7d09a60, the BoM chatter behavious was modified to add the document added there on the product/product template of the BoM. This is not correct as if a product has multiple BoM's, it'll add it to all BoM's and on the product. opw-? -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

With this PR [1], unfortunately an extra parameter `isCheck` was introduced in the tour. This commit removes that unusual parameter. [1]: https://github.com/odoo/odoo/pull/168474 runbot-107873 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Currently, an error occurs when splitting a backorder of MO's. Step to produce: - Install the 'mrp' module. - Enable work orders in the settings. - Create a BOM for a product P with an operation: - OP1: Assembly line 1, duration 10 minutes. - Create and confirm an MO for 5 units of P. - Add a Work Center and Operation in the work order line. - Set a producing quantity of 2. - Validate the MO and create a backorder. - Open a backorder of MO, Select a backorder that is in a confirmed state. - Click on the 'Action' button to split a backorder into two productions. See Traceback: ``` TypeError: argument of type 'NoneType' is not iterable File "odoo/http.py", line 2363, in __call__ response = request._serve_db() File "odoo/http.py", line 1891, in _serve_db return self._transactioning( File "odoo/http.py", line 1954, in _transactioning return service_model.retrying(func, env=self.env) File "odoo/service/model.py", line 137, in retrying result = func() File "odoo/http.py", line 1921, in _serve_ir_http response = self.dispatcher.dispatch(rule.endpoint, args) File "odoo/http.py", line 2168, in dispatch result = self.request.registry['ir.http']._dispatch(endpoint) File "odoo/addons/base/models/ir_http.py", line 329, in _dispatch result = endpoint(**request.params) File "odoo/http.py", line 727, in route_wrapper result = endpoint(self, *args, **params_ok) File "addons/web/controllers/dataset.py", line 40, in call_button action = call_kw(request.env[model], method, args, kwargs) File "odoo/api.py", line 517, in call_kw result = getattr(recs, name)(*args, **kwargs) File "addons/mrp/wizard/mrp_batch_produce.py", line 59, in action_done return self._production_text_to_object(mark_done=True) File "addons/mrp/wizard/mrp_batch_produce.py", line 90, in _production_text_to_object productions = self.production_id._split_productions({self.production_id: productions_amount}) File "home/odoo/src/enterprise/18.0/mrp_workorder/models/mrp_production.py", line 87, in _split_productions productions = super()._split_productions(amounts=amounts, cancel_remaining_qty=cancel_remaining_qty, set_consumed_qty=set_consumed_qty) File "addons/mrp/models/mrp_production.py", line 1996, in _split_productions if workorder.production_id.id not in self.env.context.get('mo_ids_to_backorder', []): ``` An error occurs because the system retrieves a None value for 'mo_ids_to_backorder' from the context at [1], which is not iterable. This causes issues as an iterable value is expected. Link [1]: https://github.com/odoo/odoo/blob/99e2b13416256a0a23a1a619b92873bcfe15b8a9/addons/mrp/models/mrp_production.py#L1846 To resolve this issue, provide an empty list for 'mo_ids_to_backorder' if the retrieved value is None instead of an iterable. Sentry-6080156727 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188434

**Current behavior:** With a product that is invoiced based on ordered qty, has avg costing, and real time valuation: it is possible to invoice and received quantity in such an order that, when there is a landed cost associated with an invoice instance of the product, the standard price of the product may be updated with an incorrect value. **Expected behavior:** Product cost follows 'average' selection logically. **Steps to reproduce:** *Enable anglo-saxon accounting* 1. Create a product with: * real time property valuation * average cost method * on ordered quantities control policy 2. Create a purchase order for the product, for 100 000 units of the product at 1.35 each -> confirm the order 3. Create an invoice for 23 000 units, receive 23 000 units and backorder the rest 4. Create a landed cost on the invoice for 23 000 in the company currency units 5. Post the invoice 6. Create a second invoice for 27 000 units and post it 7. Receive 27 000 more units from the receipt 8. See that the product standard price is not the expected value of 1.81 **Cause of the issue:** The landed cost on the invoice is not taken into account. Since the price unit for the moves informing the new price value are obtained with `_get_price_unit()`, we end up only taking into account the sum value of the invoice lines linked to the move. So the landed cost does not get included in the subsequent price unit calculation here: https://github.com/odoo/odoo/blob/22e7bfb591c43e849c554eb4c128279d76ad31f9/addons/stock_account/models/stock_move.py#L328 **Fix:** Extract a method which returns invoice lines to the `_get_price_unit()` method of purchase_stock so that we may return line records that represent landed costs that will otherwise be omitted. opw-4048396 Forward-Port-Of: odoo/odoo#188427 Forward-Port-Of: odoo/odoo#185889

If we replace the original definition then the check between the existing definition and the original one will always fail, thus we are always removing and re-adding the same constraint. https://github.com/odoo/odoo/blob/5ba361ddffa757cf60968f37180c7fd1304b3fd4/odoo/models.py#L3209 Replacing `%` by `%%` works for `LIKE` operator because they are equivalent. Since they are sent as-is to the DB the constraint could actually be plainly wrong. ```sql test_17=> SELECT coalesce(d.description, pg_get_constraintdef(c.oid)) FROM pg_constraint c JOIN pg_class t ON t.oid = c.conrelid LEFT JOIN pg_description d ON c.oid = d.objoid WHERE t.relname = 'ir_model_fields' AND conname = 'ir_model_fields_name_manual_field' +------------------------------------------------+ | coalesce | |------------------------------------------------| | CHECK (state != 'manual' OR name LIKE 'x\_%%') | +------------------------------------------------+ ``` Example where the definition sent to the DB is wrong: ```py class A(models.Model): _inherit = "res.users" _sql_constraints = [("test_constraint", "CHECK (login !~ '%')", "Cannot have % in login")] ``` ```sql test_17=> \d res_users ... Check constraints: "res_users_test_constraint" CHECK (login::text !~ '%%'::text) ... ``` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188593

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 Forward-Port-Of: odoo/odoo#186799 Forward-Port-Of: odoo/odoo#186149

The query in `_get_invoice_matching_so_candidates` will frequently plan a Seq Scan because of the low selectivity of the conditions. And when it does not, the number of rows returned by the CTE is expected to high. Because of that, filtering the resulting rows by a sequence of `OR` conditions can quickly become slow. In this commit, the `OR` conditions are replaced by `LIKE(ANY(ARRAY[]))` conditions. That way the CTE is only referenced once in the conditions and applying the filter on each row is way faster. We also discarded duplicated `text_tokens` to reduce the size of the `ARRAY`. The reason why using a `LIKE(ANY(ARRAY[]))` is faster is because postgres inlines the CTE in the outer query. This means that it performs a Seq Scan on sale.order and injects the CTE definition of sub.name inside the `WHERE` conditions of the outer query, along with injecting the `WHERE` conditions of the CTE. So, the regex functions are distributed among the `OR` conditions. I.e. every `OR` condition left operand will contain the regex functions. As those have to be executed for every `OR` condition, this quickly becomes slow. We can explicitely materialize the CTE to avoid that. This makes postgres evaluate the regex functions only once. But it will still have lots of `OR` conditions to check along with running pattern matching for each one of them. `LIKE(ANY(ARRAY[]))` avoids this issue. The CTE is still inlined but since we now only have a single condition, the regex functions are only evaluated once and pattern matched once against an array of options. This makes the whole query faster and scale better. #### speedup Customer database with 808341 sale.orders. Query timing when increasing the number of text tokens. | Number of tokens | Before PR | After PR | |:-------------------:|:----------:|:--------:| | 2 | 7s | 1.3s | | 5 | 10s | 1.3s | | 10 | 18s | 1.4s | | 20 | 33s | 1.55s | opw-4329067 opw-4316765 Forward-Port-Of: odoo/enterprise#73755

Bug Fixes(3)

[FIX] mrp: restore the previous chatter behavious in BoM's

[FIX] website: fix website_form_editor tour

[FIX] social_linkedin: correct parsing of post statistics response

Other(34)

[FW][FIX] account_peppol: Fix bad write override in case of multiple records

Bug Fixes(3)

[FIX] mrp: restore the previous chatter behavious in BoM's

[FIX] website: fix website_form_editor tour

[FIX] social_linkedin: correct parsing of post statistics response

Other(34)

[FW][FIX] account_peppol: Fix bad write override in case of multiple records

[FW][FIX] mail: allow playing video on safari

[FW][FIX] l10n_gcc_invoice: correct wrong access to Arabic language

[FW][FIX] mail : Prevent changing the alias_domain_id if already exist

[FW][FIX] sale_project: fix the qunit test

[FW][FIX] web: Allow PDF printing on mobile

[FW] 17.0 stock backport replenish perf avd

[FW][I18N] l10n_ar{_website_sale}: update translations

[FW][FIX] pos_self_order: fix kiosk not closing

[FW] 17.0 fix change costing method arm

[FW][FIX] mass_mailing: fix overlap issues with mass_mailing_html_field

[FW][FIX] base: update translations after fixing the manifest of account_sepa_direct_debit

[FW][FIX] mrp: prevent an error when split a backorder of MO's

[FW][PERF] point_of_sale: load needed product tags fields

[FW][FIX] purchase_stock,stock_landed_costs: price unit reflect LC value

[FW][FIX] website: fix media dialog insert media tour

[FW][FIX] account: prevent error when opening invoice preview without invoice date

[FW][FIX] core: use the original constraint definition

[FW][FIX] barcodes_gs1_nomenclature: clean FNC1

[FW][FIX] packaging: empty windows install path

[FW][FIX] account: add syscebnl to uninstallable coas

[FW][FIX] mrp: workorder planning inconsistent duration

[FW][FIX] l10n_fr: Siret and ape invisible

[FW][FIX] mail: multi recipient duplication (16.0)

[FW][CLA] sign CLA for Xcellent Exchange

[FW][PERF] sale_account_accountant: improve so candidates query plan

[FW][FIX] l10n_mx_edi: Correct CFDI origin validation

[FW][FIX] stock_barcode(_picking_batch): grouped lines

[FW][FIX] account_bank_statement_import_csv: delete line values by index

[FW][I18N] l10n_ar_{edi,reports}: update translations

[FW][FIX] account_base_import: Don't skip tests if openpyxl installed

[FW][FIX] account_sepa_direct_debit module description

[FW][FIX] industry_fsm_sale: decrease priority to avoid being main view

[FW][IMP] hr_payroll: neutralize fr l10n