Daily updates from Odoo
Monday, October 13, 2025
9 changes · saas-18.2
Resolved issues and error corrections
This update adjusts an internal test workaround for Gantt scheduling so automated checks continue to run correctly after changes in the testing framework. It is limited to unit tests and does not change business functionality or user workflows.
Original PR description
## Pull Request HOOT 37 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Community: https://github.com/odoo/odoo/pull/230556 Forward-Port-Of: odoo/enterprise#96647
Employee contracts in Swiss payroll now only show insurance options that belong to the relevant company. This prevents accidental selection of insurance records from another company in multi-company environments, improving data accuracy and payroll setup.
Original PR description
Currently, in a multi-company setup, you are able to select insurances from other companies on the employee contract task-5157106 Forward-Port-Of: odoo/enterprise#96821
SEPA payment files will now mark payments as high priority only for Belgian companies. This helps companies in other countries avoid unnecessary bank fees caused by high-priority processing.
Original PR description
Having priority set as HIGH for SEPA payments can induce extra fees (ex. in CH). This commit only sets the priority to HIGH for BE companies. task-4874217 Forward-Port-Of: odoo/enterprise#96794 Forward-Port-Of: odoo/enterprise#95420
UrbanPiper POS orders now apply the correct taxes when a point of sale is set up under a branch company. This prevents undercharging or inaccurate tax reporting in multi-branch businesses, including cases where taxes are split into sub-taxes.
Original PR description
Steps to reproduce: --- - Install `pos_urban_piper`. - Create a branch under *Main Company*. - Switch to the new branch. - Create a POS config in this branch and set up UrbanPiper. - Sync "Apple Pie". - Place an order with "Apple Pie". Issue: --- - The 15% tax defined on Apple Pie is not applied on the orderline. Cause: --- - While creating the order line, the tax company was compared directly with the POS config’s company. In this case, the tax belongs to the parent company, while the POS config belongs to a child company. Fix: --- - Compare the `root_id` of both companies instead of the direct company ID to ensure taxes are applied correctly in multi-branch setups. - Additionally, handled the case where a main tax has sub-taxes (e.g., 5% GST split into 2.5% SGST and 2.5% CGST). In such cases, we now fetch the tax type from the sub-taxes instead of the main tax. Task-5050682 Forward-Port-Of: odoo/enterprise#93467
Mexican DIOT reports now identify United Kingdom transactions with the correct country code instead of grouping them under "Other country." This helps businesses produce more accurate tax reporting for UK-related records.
Original PR description
The DIOT country adaptation map lacked the ISO 3-letter code for the UK, causing records with country 'GB' to be reported as 'ZZZ' ("Other country").
Added mapping 'GB' → 'GBR' to ensure correct DIOT country code generation.
Forward-Port-Of: odoo/enterprise#96771This fixes a timing issue that could make follow-up report tests fail when they started before midnight and finished after midnight. It improves confidence in automated testing without changing how customers use the reporting feature.
Original PR description
Tests https://runbot.odoo.com/odoo/runbot.build.error/159772 where failing when setUpClass run before midnight and the test itself run at/after midnight because `today` was not the same. As follow-up report divides the lines per partner to due/overdue utilizing `today` in comparison, This resuls in different lines than expected. Forward-Port-Of: odoo/enterprise#96486
Document upload request emails now greet the person being asked to upload the document, rather than the sender. Invitation and reminder emails are also sent in the requestee's language, making messages clearer and more personalized.
Original PR description
Currently, the email template inviting a user to upload a document displays the document owner's name in the greeting instead of the requestee's. This commit updates the template to display the correct name. Steps to reproduce: 1. Log in as Mitchell Admin 2. Go in the Document app 3. Click on the New > Request 4. Enter a document name and select Joel Willis as requestee 5. Send the request by clicking on the "Request" button => The invitation email is correctly sent to Joel Willis but it says "Hello Mitchell Admin" instead of "Hello Joel Willis" Additionally, this PR ensures that the reminders and the invitation emails are sent in the requestee's language rather than the sender's. Task-5130591 Forward-Port-Of: odoo/enterprise#96161
This fix prevents Field Service report cleanup logic from failing when related worksheet data has already been removed during module uninstallation. It helps avoid incomplete uninstallations that can later cause reinstall problems or database consistency issues.
Original PR description
Recently pull request https://github.com/odoo/enterprise/pull/86084 introduced an ondelete method on `ir.model` that retrieves some worksheet templates to delete them. However, this method breaks…
Recently pull request https://github.com/odoo/enterprise/pull/86084 introduced an ondelete method on `ir.model` that retrieves some worksheet templates to delete them. However, this method breaks when uninstalling module `worksheet`:
```
ir.model.data._module_data_uninstall():
... records are deleted ...
ir.model.fields.unlink():
drop column of corresponding fields
delete ir.model.field records
ir.model.unlink():
drop table of corresponding models
ir.model._unlink_if_uninstalling():
self.env['worksheet.template'].search([('model_id', ...)]).unlink()
delete ir.model records
```
The call to `ir.model.unlink()` crashes when searching for worksheet templates, since column `model_id` has been dropped already. This makes the transaction fail, and it is rolled back to a savepoint just before the call to `ir.model.unlink()`. In other words, the uninstallation manages to drop most of the columns that must go, but fails to drop all the tables that must go. And the uninstallation proceeds anyway...
Now consider uninstalling module `resource`. That module defines model `resource.calendar` with required field `name`, and also defines a record in that model (a default calendar). When the module is uninstalled, module `worksheet` is also uninstalled (because it depends on `resource`), and so the situation above happens. Consequently, most of the columns of table `resource_calendar` are dropped, but the table is not. If we reinstall module `resource` after that, the ORM re-creates column `name` (which is `NULL` on the default calendar at least), but fails to add the `NOT NULL` constraint on that column.
The fix consists in avoiding the `search()` above in the ondelete method if the column `model_id` does not exist anymore.
Forward-Port-Of: odoo/enterprise#96845This update corrects automated test setup for products used in manufacturing planning and rentals. It ensures test products are treated as properly configured, preventing false failures caused by default lead-time rules rather than real business issues.
Original PR description
This PR addresses the issue where tests were failing due to unconfigured products (no vendor/ no BoM). Now unconfigured products' lead_time is incremented by 365 due to this PR: https://github.com/odoo/odoo/pull/216293 Before this fix: Products have `buy` route by default and no vendor, so they are considered unconfigured products and lead time is incremented by 365, and tests fail as any lead time refers to a date earlier than today would only affect the first period in the MPS which is not intended in the tests. After this fix: Products have `manufacture` route and there is BoM, so they are considered configured products and lead time is calculated normally from BoM which is 0. Task-4779057 Forward-Port-Of: odoo/enterprise#88766