Wednesday, April 23, 2025
11 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