Wednesday, April 23, 2025
20 changes · 17.0
Resolved issues and error corrections
This fixes an issue where Point of Sale demo data could fail to load after upgrading from an older Odoo version if a matching tax group was missing. The demo setup now includes the needed tax group, helping test and demo environments upgrade more smoothly.
Original PR description
The demo POS tax assumes the presence of a tax group that matches the company and country domains. This is a correct assumption on install because of the post-install [loading](https://github.com/odoo/odoo/blob/ce25577ba6cd6ab178cf05b111aebcf8e1815624/addons/account/demo/account_demo.xml#L31-L35) of the generic_coa in account module, but it is not necessarily true on upgrade, where the loading function is [not called](https://github.com/odoo/odoo/blob/36e6d6ea6792d5e549a7794f111a65fc32decd1c/odoo/tools/convert.py#L276-L278). Upgrading from 16.0 can happen without a coa loaded on the company, leading to the absence of a matching tax group, and the failure of loading the pos demo data. runbot error 161547 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a customer or vendor state is changed through the GST warning flow in Indian localization, the related fiscal position is now updated as expected. This helps keep GST tax treatment aligned with the latest address information and reduces manual correction work.
Original PR description
Before this commit: - Changing the state via the GST warning did not update the fiscal position. After this commit: - Changing the state via the GST warning correctly update the fiscal position. Task-4681566
This fix prevents an error when manufacturing operations have incomplete start or finish dates. It helps users save production orders reliably even when some dependent operations are not fully scheduled yet.
Original PR description
### Issue: The compute method of the json_popover raises a traceback if dates are not uniformly set on blocking operations. ### Steps to reproduce: - Create a bom for a product with 3 operations. - Allow operation dependancies and set op3 to be bloqued by op1 and op2. - Create an MO using that bom and confirm. - Try to set the date_start and date_finished on both op1 and op3 but not op2 - Save #### > Traceback: TypeError: '<' not supported between instances of 'bool' and 'datetime.datetime' #### Cause of the issue: The min and max call are simply performed by comparing boolean values with dates. This is a backport of 1278404cd6d5f9b6d7f8c510f168e77a870ba6ca opw-4511050 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Spreadsheet charts now keep the cumulative and starting cumulative settings separate when importing Odoo graph views. This prevents charts from using the wrong starting behavior and helps reports display expected totals.
Original PR description
The option of "cumulatedStart" was incorrectly infered from the "cumulative" option of an Odoo graph view. However, both options are not specifically linked. Task-4701303 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a form view issue where changes made to property fields could still appear after a user chose to discard them. The correction ensures the screen correctly returns to the original values, avoiding confusion even though the saved data was not affected.
Original PR description
Purpose: ------- Following the changes in [1], discarding the changes in a form view when a properties field has a change does not reset the field to its initial value (UI only issue: the change is not applied when reloading the view). This issue arises because after the changes in [1], the properties are not deep copied anymore. Therefore, when a property is updated, the value inside the relational model's record data is updated. The issue is fixed by returning a copy of the properties values again. [1]: https://github.com/odoo/odoo/commit/8723f020c3587a900c811b8cc23f53fe34b98df3#diff-89ec9296feb48614f91829b8b732dca614359831967fa65a2126d6fe68c84450
This change removes account 466 from the shared Spanish accounting template so it no longer appears in the SME chart of accounts. This keeps Spanish localization aligned with official accounting rules and avoids offering an account that should not be used by SME businesses.
Original PR description
This reverts commit e6153d7d796b4e580518ad64f572543f87b4fee8. 466 account **mustn't** be in the SMEs CoA. You can see in https://www.boe.es/biblioteca_juridica/publicacion.php?id=PUB-PB-2021-228&tipo=L&modo=2 that it's not present. @Tecnativa
This fixes an installation failure in Website CRM that could happen if the standard website contact page reference had previously been deleted. Businesses can now install the module more reliably without being blocked by this specific setup inconsistency.
Original PR description
Currently, an exception is generated when a user tries to install the `website_crm` module after deleting the external identifier `website.contactus`. Steps to Reproduce: 1. Install the `website` module. 2. Go to Settings -> Technical -> Sequences and Identifiers -> External Identifiers. 3. Delete the `website.contactus` identifier. 4. Try to install the `website_crm` module. 5. An error occurs. Error: `ParseError while parsing None:4, somewhere inside ` This issue [1] occurs because, during the installation of `website_crm`, Odoo tries to reference the deleted external identifier `website.contactus`. [1] - https://github.com/odoo/odoo/blob/a1969de6e6a292b14ad1d19c256ead04dc202528/addons/website_crm/views/website_templates_contactus.xml#L3-L13 This fix resolves the issue by using `forcecreate=0` to bypass record creation if it violates. sentry-6255808403 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Sendcloud delivery integration now avoids an error when an order contains matching positive and negative product quantities that cancel out. This prevents shipping requests from failing in return or adjustment scenarios where the total quantity becomes zero.
Original PR description
Beofre this commit: Products with both positive and negative sales order lines in SO can result it total quantity = 0 when calcuating average cost. Causing division by zero error. After this commit: Added a check to prevent division if total quantity of product is zero. Negative order lines are usually used for return of product, it is not included in shipping request. opw-4655713
The Planning app now handles cases where a user's timezone is not set, preventing an error during planning flows. This keeps scheduling screens and tests running reliably by using the same timezone logic consistently across related planning calculations.
Original PR description
Steps to reproduce: - starting planning_test_tour => error raised Source: - https://github.com/odoo/enterprise/pull/69888 introduced a new method _get_non_working_days_bounds which computes user_tz but the value can be False and also not coherent with user_tz computed in _calculate_start_end_dates (method from wich this new method is called) Fix: user_tz is computed the same way as its computed in the original method, the code is duplicated as signature cannot be changed in stable.
This update fixes a failing automated payroll dashboard tour by moving contract management checks into a more reliable test layer. It helps keep payroll-related quality checks stable without changing the day-to-day user experience.
Original PR description
Runbot error: https://runbot.odoo.com/odoo/error/160977 This commit fixes the tour by moving the steps related to the contract management in the python part of the test. Also fixes the formatting of the tour file.
Charts inserted into spreadsheets now correctly keep their configured cumulative starting point. This prevents spreadsheet charts from showing results that differ from the original chart view, improving consistency for users relying on reports.
Original PR description
We never took the 'cumulated_start' option of an Odoo chart into account and instead relied on 'cumulative' but the options are not linked neither one implied by the other. Task-4701303
Miscellaneous changes
…dd it in the tax details Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206052
Original PR description
…dd it in the tax details Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206052
This reverts commit a43d8b44405786023960a028aee7c5f79a1f0425. What is being called the "full" COA is actually the general one (https://www.boe.es/biblioteca_juridica/abrir_pdf.php?id=PUB-PB-2024-227) Whereas the "common" COA is the one of SMEs (https://www.boe.es/biblioteca_juridica/abrir_pdf.php?id=PUB-PB-2021-228). So there was a naming confusion in the reverted commit. Entreprise PR: https://github.com/odoo/enterprise/pull/83892 Forward-Port-Of: odoo/odoo#206967
Original PR description
This reverts commit a43d8b44405786023960a028aee7c5f79a1f0425. What is being called the "full" COA is actually the general one (https://www.boe.es/biblioteca_juridica/abrir_pdf.php?id=PUB-PB-2024-227) Whereas the "common" COA is the one of SMEs (https://www.boe.es/biblioteca_juridica/abrir_pdf.php?id=PUB-PB-2021-228). So there was a naming confusion in the reverted commit. Entreprise PR: https://github.com/odoo/enterprise/pull/83892 Forward-Port-Of: odoo/odoo#206967
Fixes an issue in `test_pos_js` when executed in a database without demo data, where missing payment methods cause test failures. This commit adds the necessary payment methods and a required product to the configuration, ensuring proper test execution. Runbot Error: 135208 Forward-Port-Of: odoo/odoo#199913
Original PR description
Fixes an issue in `test_pos_js` when executed in a database without demo data, where missing payment methods cause test failures. This commit adds the necessary payment methods and a required product to the configuration, ensuring proper test execution. Runbot Error: 135208 Forward-Port-Of: odoo/odoo#199913
Before this commit, `couponPointChanges` was not properly remapped, which led to am error when refreshing the browser after applying a reward. Steps to reproduce: 1. Create a promotion program with a free product for orders over $100. 2. In PoS, create an order meeting the $100 and apply the reward. 3. Validate the order and start a new one. 4. Again, make an order over $100 and apply the reward. 5. Refresh the browser at this point. => You will encounter the following error: `Cann
Original PR description
Before this commit, `couponPointChanges` was not properly remapped, which led to am error when refreshing the browser after applying a reward. Steps to reproduce: 1. Create a promotion program with a free product for orders over $100. 2. In PoS, create an order meeting the $100 and apply the reward. 3. Validate the order and start a new one. 4. Again, make an order over $100 and apply the reward. 5. Refresh the browser at this point. => You will encounter the following error: `Cannot read properties of undefined (reading 'appliedRules')` opw-4644333 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202970
## 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 c
Original PR description
## 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…
## 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#203038This is used in the event a request is timing out or has an out of memory issue. This would cause the profile to be committed to the database before the request gets terminated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204673
Original PR description
This is used in the event a request is timing out or has an out of memory issue. This would cause the profile to be committed to the database before the request gets terminated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204673
This reverts commit d33bd999df9c8377518b969729e7fcd1826b7c5d. What is being called the "full" COA is actually the general one (https://www.boe.es/biblioteca_juridica/abrir_pdf.php?id=PUB-PB-2024-227) Whereas the "common" COA is the one of SMEs (https://www.boe.es/biblioteca_juridica/abrir_pdf.php?id=PUB-PB-2021-228). So there was a naming confusion in the reverted commit. task-none Forward-Port-Of: odoo/enterprise#83892
Original PR description
This reverts commit d33bd999df9c8377518b969729e7fcd1826b7c5d. What is being called the "full" COA is actually the general one (https://www.boe.es/biblioteca_juridica/abrir_pdf.php?id=PUB-PB-2024-227) Whereas the "common" COA is the one of SMEs (https://www.boe.es/biblioteca_juridica/abrir_pdf.php?id=PUB-PB-2021-228). So there was a naming confusion in the reverted commit. task-none Forward-Port-Of: odoo/enterprise#83892
…arning domain The unposted entries warning was sometimes triggered unnecessarily due to the domain used for querying move not accounting for the companies accessible by the report. This led to cases where unposted entries from unrelated companies were considered, resulting in misleading warnings. This commit addresses the issue by using the company IDs returned by `get_report_company_ids()` to properly scope the domain. no-task Forward-Port-Of: odoo/enterprise#83025
Original PR description
…arning domain The unposted entries warning was sometimes triggered unnecessarily due to the domain used for querying move not accounting for the companies accessible by the report. This led to cases where unposted entries from unrelated companies were considered, resulting in misleading warnings. This commit addresses the issue by using the company IDs returned by `get_report_company_ids()` to properly scope the domain. no-task Forward-Port-Of: odoo/enterprise#83025
Most tests of the module need to create a sale order, which requires the `group_sale_salesman` at least. Set this group. https://runbot.odoo.com/odoo/error/163649 Forward-Port-Of: odoo/enterprise#83802
Original PR description
Most tests of the module need to create a sale order, which requires the `group_sale_salesman` at least. Set this group. https://runbot.odoo.com/odoo/error/163649 Forward-Port-Of: odoo/enterprise#83802