Odoo Changelog — 2024-11-28

Thursday, November 28, 2024

22 changes · saas-17.2

Bug Fixes(1)

Resolved issues and error corrections

[FIX] sale_project: fix the qunit test

Coresaas-17.2sale_project

A test in the Sales Project area was corrected so it checks the intended result instead of passing accidentally. This improves confidence that future changes to project milestone forms are validated properly before release.

Original PR description

Currently, the assert function returns undefined, which is why this test case is passing. However, assert always returns undefined, regardless of whether the value satisfies the condition or not.

task-4354290

#testing#project milestones#quality

Other(21)

Miscellaneous changes

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

PR #74815

Enterprisesaas-17.2

Original PR description

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…

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

Currently, the assert function returns undefined, which is why this test case is passing. However, assert always returns undefined, regardless of whether the value satisfies the condition or not. task-4354290

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

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

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

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

Bug Fixes(1)

[FIX] sale_project: fix the qunit test

Other(21)

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

Bug Fixes(1)

[FIX] sale_project: fix the qunit test

Other(21)

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

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

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

[FW][FIX] account_sepa_direct_debit module description

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

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

[FW][FIX] l10n_mx_edi: only keep needed schemaLocation in CFDI

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

[FW][CLA] sign CLA for Xcellent Exchange

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

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

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

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

[FW][IMP] web: TreeEditor: domain in autocompletes

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

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

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

[FW] 17.0 stock backport replenish perf avd

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

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

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