Odoo Changelog — 2025-04-25

Friday, April 25, 2025

30 changes · saas-17.4

Bug Fixes(1)

Resolved issues and error corrections

[FIX] pos_restaurant_preparation_display: runbot error 181562

Enterprisesaas-17.4pos_restaurant_preparation_display

This fixes an automated test that could fail randomly when restaurant orders were sent for preparation and then validated immediately. The customer-facing behavior remains unchanged, while test results should be more stable and reduce false failures in quality checks.

Original PR description

`sync_from_ui` server method is called when sending items for preparation and when validating an order. We call the method asynchronously when sending items for preparation, so when running the test automatically, there is a risk of concurrent calls of `sync_from_ui` if preparation order action is immediately followed by validating the order. Runbot observes the issue randomly.

It's a functional requirement that we don't wait for the preparation order request so in this PR, we fix the test by waiting for the preparation order request to finish before proceeding to the succeeding steps.

#restaurant#point-of-sale#testing#stability

Other(29)

Miscellaneous changes

[FW][FIX] l10n_es: Modelo 390 section 1 and 2 totals.

PR #205927

Coresaas-17.4l10n_es

Original PR description

In https://github.com/odoo/odoo/pull/205403 I did some wrong changes to the totals of Modelo 390 section 1. This PR reverts these changes and fixes the section 2, which was the initial plan.

Details:

l10n_es tax has two main tax reports, modelo 303 (quarterly taxes) and modelo 390 (annual taxes).

For both of these reports, for invoices, the taxes use positive tax tags corresponding the to tax line in the tax report. For refunds, the two reports work differently. Modelo 303 links all the refund amounts to some special report line (modification/correction of base/taxes), whereas the modelo 390 uses the negative tax tags corresponding to the tax line in the report.

The issue lies in the multiple cross report references from modelo 303 to modelo
390. In section 1, some base and tax amounts are referrenced from modelo 303, as well as the modification amounts (the total of refunds mentionned above). When we compute the totals for that section, some refunds can be counted twice (once from the report using the negative tax tags, and a second time if we count the modification cross referenced from modelo 303). Since we have more taxes using the negative tags than cross-referenced in that section, it is better to omit the modification from the totals (i.e. we do not subtract [30] for the totals, as the negative amounts are already accounted for for the majority of the taxes). The totals will still be incorrect for that section, but less wrong.

A future PR for master will fix the report by splitting all the tags used for the two reports.

In section 2, we are in a similar case, so we remove the subtraction of [62] from the totals. In this case, the totals are correct after this modification.

Forward-Port-Of: odoo/odoo#205860

`sync_from_ui` server method is called when sending items for preparation and when validating an order. We call the method asynchronously when sending items for preparation, so when running the test automatically, there is a risk of concurrent calls of `sync_from_ui` if preparation order action is immediately followed by validating the order. Runbot observes the issue randomly. It's a functional requirement that we don't wait for the preparation order request so in this PR, we fix the test by waiting for the preparation order request to finish before proceeding to the succeeding steps.

In https://github.com/odoo/odoo/pull/205403 I did some wrong changes to the totals of Modelo 390 section 1. This PR reverts these changes and fixes the section 2, which was the initial plan. Details: l10n_es tax has two main tax reports, modelo 303 (quarterly taxes) and modelo 390 (annual taxes). For both of these reports, for invoices, the taxes use positive tax tags corresponding the to tax line in the tax report. For refunds, the two reports work differently. Modelo 303 links all the refund amounts to some special report line (modification/correction of base/taxes), whereas the modelo 390 uses the negative tax tags corresponding to the tax line in the report. The issue lies in the multiple cross report references from modelo 303 to modelo 390. In section 1, some base and tax amounts are referrenced from modelo 303, as well as the modification amounts (the total of refunds mentionned above). When we compute the totals for that section, some refunds can be counted twice (once from the report using the negative tax tags, and a second time if we count the modification cross referenced from modelo 303). Since we have more taxes using the negative tags than cross-referenced in that section, it is better to omit the modification from the totals (i.e. we do not subtract [30] for the totals, as the negative amounts are already accounted for for the majority of the taxes). The totals will still be incorrect for that section, but less wrong. A future PR for master will fix the report by splitting all the tags used for the two reports. In section 2, we are in a similar case, so we remove the subtraction of [62] from the totals. In this case, the totals are correct after this modification. Forward-Port-Of: odoo/odoo#205860

## Description I am experiencing slow processing times for incoming stock from vendors when the historical data contains a large number of records. Currently, my company has around 20 million `stock.valuation.layer` records. As a result, any transaction involving incoming stock takes approximately 5–21 seconds to complete, even for a small number of products (around 1–5 products). Through profiling, I have identified that the root cause is the compute function `_compute_value_svl`. This computed field is always triggered during incoming stock transactions when calculating the average cost or fixing rounding errors. ## Proposal To improve performance, I propose implementing a Parallel Index-Only Scan. This method is effective for grouping large datasets while retrieving only fixed columns, optimizing query execution. ## Benchmark | Before | After | Speedup | |--------|--------|--------| | 1.1 s| 97.8 ms | 11x| ### Before ``` Finalize GroupAggregate (cost=1000.56..397852.39 rows=538 width=80) (actual time=1040.355..1114.694 rows=1 loops=1) Group Key: product_id Buffers: shared hit=227534 read=330906 dirtied=83 written=683 -> Gather (cost=1000.56..397825.49 rows=1076 width=80) (actual time=1039.900..1114.679 rows=3 loops=1) Workers Planned: 2 Workers Launched: 2 Buffers: shared hit=227534 read=330906 dirtied=83 written=683 -> Partial GroupAggregate (cost=0.56..396717.89 rows=538 width=80) (actual time=1036.758..1036.759 rows=1 loops=3) Group Key: product_id Buffers: shared hit=227534 read=330906 dirtied=83 written=683 -> Parallel Index Scan using stock_valuation_layer_index on stock_valuation_layer (cost=0.56..392927.16 rows=302613 width=20) (actual time=0.608..975.431 rows=247487 loops=3) Index Cond: ((product_id = 140) AND (company_id = 1)) Buffers: shared hit=227534 read=330906 dirtied=83 written=683 Planning: Buffers: shared hit=9 dirtied=1 Planning Time: 0.139 ms Execution Time: 1114.732 ms ``` ### After ``` Finalize GroupAggregate (cost=1000.56..21876.83 rows=538 width=80) (actual time=91.888..97.719 rows=1 loops=1) Group Key: product_id Buffers: shared hit=12889 read=7121 -> Gather (cost=1000.56..21849.93 rows=1076 width=80) (actual time=91.636..97.704 rows=3 loops=1) Workers Planned: 2 Workers Launched: 2 Buffers: shared hit=12889 read=7121 -> Partial GroupAggregate (cost=0.56..20742.33 rows=538 width=80) (actual time=87.579..87.580 rows=1 loops=3) Group Key: product_id Buffers: shared hit=12889 read=7121 -> Parallel Index Only Scan using idx_svl_company_product on stock_valuation_layer (cost=0.56..16951.60 rows=302613 width=20) (actual time=0.044..46.642 rows=247487 loops=3) Index Cond: ((company_id = 1) AND (product_id = 140)) Heap Fetches: 9188 Buffers: shared hit=12889 read=7121 Planning Time: 0.107 ms Execution Time: 97.751 ms ``` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206587 Forward-Port-Of: odoo/odoo#203038

Steps to reproduce [17.1]: - Add a property field to a job application in the backend. - Go to the linked website job application form (in edit mode). - The property field is inaccessible. To be able to access the new property field in the application form, the `job_id` value of the related job record needs to be specified by default. Unfortunately, these values are removed before accessing "edit" mode: Starting from [1], a fix was added to clear default values coming from `data-for` attributes when the form is edited (at `cleanForSave()`) to prevent saving it with changed default values. Since the code from [1] can also remove default values set by the user, a new fix (see [2]) updated this implementation to ensure that only values from auto-fill and data-for fields will be removed (this time, when the form public widget is destroyed [3]). The behaviour from [3] will always unlink the `data-for` values in edit mode, and as a consequence, the related property fields won't be correctly retrieved. The goal of this commit is to fix this behaviour by excluding `data-for` values from the reset in [3]. An extra check will be added to be sure the form won't be saved with updated default values if it already has `data-for` ones [4]. Important: The diff from [5] made the `email_to` field as an exception for the data-for/prefill priority system and only used the `data-for` value if nothing has been configured by the user (it also used the `data-for` value if what was configured by the user is the dummy default email: `info@yourcompany.example.com`). That's why we need to exceptionally allow saving the default value added by the user in the check from [4] to preserve the same behavior. Following [6], The `email_to` value won't be kept in edit mode to prevent breaking its dynamic behavior. [1]: https://github.com/odoo/odoo/commit/b637a5e32f767b62736241042f88fa0cecf9f10b [2]: https://github.com/odoo/odoo/commit/043e1fdf923d2037dd8da128ab99388f0c92e544 [5]: https://github.com/odoo/odoo/commit/a08574a04ff2ce8ea2d6fd2b79f56cc57bba953b [6]: https://github.com/odoo/odoo/commit/6658d61e304c9dfd8e512648c4a001dcaac44bc1 task-3922573 Forward-Port-Of: odoo/odoo#166565

Currently, when validating deliveries, if multiples attachments are posted in the same chatter message, the printing jobs do not complete. Steps to reproduce: ------------------- * Install fedex * In operation types, select Delivery Orders then hardware * In print on validation, enable Carrier Labels and Export Documents * In the shipping methods, select fedex international * Change Label format to ZPL11 * Connect the database to an iot box * Set up the shipping labels to be send on zebra printer * Set up commercial invoice (/invoice) to be sent to another printer * Create a sale order, using fedex international as shipping * Confirm the SO * Select the delivery * Validate the delivery > Observation: Nothing prints, jobs are sent to CUPS bu not printing Why the fix: ------------ https://github.com/odoo/enterprise/blob/8075101192fb81a78f2a984cf2adf67fc77c0194/delivery_fedex_rest/models/delivery_fedex.py#L192-L196 As show, when sending the shipping, if the invoice is generated, it gets added to the attachements. The function `message_post` will post all attachments in the same chatter message. In `delivery_iot` the `message_post` function is overridden to allow sending the printing jobs to the iot. https://github.com/odoo/enterprise/blob/8075101192fb81a78f2a984cf2adf67fc77c0194/delivery_iot/models/stock_picking.py#L33-L46 Here, `attachments_names` will both contain `Label` and `ShippingDoc`. Since we enter the first if condition, the report is related to the shipping labels. Then we send the data related to all attachments to the device linked to the shipping labels, aka the zebra printer. Since the other attachment is of type PDF, the zebraprinter does not know what to do with it and ends up printing nothing. Since we can have multiple different attachment, the if/elseif condition does not make sense. By breaking it in two if, we can send both reports separately, while still keeping all attachments in the same chatter message. opw-4546715 Forward-Port-Of: odoo/enterprise#82094

Bug Fixes(1)

[FIX] pos_restaurant_preparation_display: runbot error 181562

Other(29)

[FW][FIX] l10n_es: Modelo 390 section 1 and 2 totals.

Bug Fixes(1)

[FIX] pos_restaurant_preparation_display: runbot error 181562

Other(29)

[FW][FIX] l10n_es: Modelo 390 section 1 and 2 totals.

[FW][FIX] l10n_fr: invert lines in Chart of Accounts

[FW][FIX] reCaptcha, turnstile: disable both protection on neutralize

[FW][FIX] website: prevent upload if logo is too big in configurator

[FW][FIX] base_vat: romanian vat check

[FW][PERF] stock_account: optimize compute valuation

[FW][FIX] website: edit theme with google 300 size only font

[FW][FIX] web: prevent error with extremely vertical logos in document layout

[FW][FIX] stock_account: Select correct rounding method

[FW][FIX] l10n_hu_edi: last credit note as Storno

[FW][FIX] l10n_hu_edi: invoice spacing

[FW][FIX] web_editor: traceback when applying gradient color

[FW][FIX] account: prevent posting invoice with mismatched account currency

[FW][FIX] payment_buckaroo: add payment method codes

[FW][16.0][REF] stock: refactor _create_backorder

[FW][FIX] website: ensure robots.txt matches domain with punycode support

[FW][FIX] account,l10n_ch: skip_create also skips the search

[FW][FIX] point_of_sale: correctly search contacts by phone without spaces

[FW][FIX] sale_timesheet: respect uom user-defined defaults for products

[FW][FIX] l10n_fr: add missing pcg_758 in Chart of Accounts

[FW][FIX] website: prevent the removal of the form's default values

[FW][FIX] spreadsheet_dashboard_sale_subscription: change displayed data

[FW][FIX] delivery_fedex_rest: get fedex rate for GDB in UK

[FW][FIX] sendcloud_service: Prevent division by zero for average cost

[FW][FIX] l10n_in_reports_gstr: add validation before gst cron

[FW][IMP] l10n_in_reports_gstr: separate B2B & B2C Reporting in GSTR-1 HSN Summary

[FW][FIX] delivery_iot: send seperate printing jobs when validating deliveries

[FW][FIX] l10n_ch_hr_payroll_elm_transmission: Relax critical constraint to allow multi company use

[FW][FIX] planning: user_tz is False