Monday, September 7, 2026
14 changes · saas-19.4
Enhancements to existing features
The rental stock integration now reuses an existing shared rule for identifying rented quantities. This makes it easier for other add-ons to customize rental behavior consistently, with no expected change for day-to-day users.
Original PR description
There is already an existing hook on product.product ([sale_renting.models.product_product.ProductProduct._get_qty_in_rent_domain](https://github.com/acsone/enterprise/blob/2cd105c93bb7199a5ecea67a919a7ab5d9251cbf/sale_renting/models/product_product.py#L24)), use it to get the domain, so it can be inherited by other modules.
While the upstream method uses `('product_id', 'in', self.ids)` instead of this one's `('product_id', '=', self.id)`, this isn't an issue since there's a `self.ensure_one()` just above.
Forward-Port-Of: odoo/enterprise#130090
Forward-Port-Of: odoo/enterprise#129191Resolved issues and error corrections
Installing the Website app with demo data could create duplicate menu entries for additional websites. This fix prevents menus from being copied when a website already has one, keeping navigation clean and avoiding confusion for users.
Original PR description
Since [1], we have 2 calls to `_bootstrap_homepage` - one in the `post_init_hook`, and one in `website.create`, causing the menu hierarchy to be duplicated. This doesn't apply to the default website (from base) as there was no `create` method override at the point of creation (website is not installed yet) and the homepage/menu is only created once, by the `post_init_hook`. Steps to reproduce: 1. Install website with demo data. 2. Menus for website 2 are duplicated. Solution: Simply check if the website doesn't have a menu before duplicating it. [1]: https://github.com/odoo/odoo/commit/ae81b6f6074632d1a609387e53f97a61ee6c95f4 task-6030210
The settings screen now hides both the Project label and its field when Billing is disabled or Project Planning is enabled. This removes a confusing leftover label and makes the Billable settings clearer for users.
Original PR description
*: planning_field_service_sale_timesheet,project_timesheet_forecast_field_service_sale ## Before this commit Only the project field was hidden when "Billing" is not enable, or if "Project Planning" is enabled, leaving the "Project" label visible in any case. ## After this commit The label and field are hidden if "Billing" is not enabled, or if "Project Planning" is enabled. task-6478896
Fixed an issue where card views could stop refreshing correctly after the first reload. This helps ensure users see updated card information reliably without needing extra actions.
Original PR description
`this.key` is the signal function, so `this.key + 1` concatenates its source and `set` stores that same string on every reload: the first reload changes the key and re-creates the Record, the next ones are no-ops. Introduced in odoo/odoo#260098
Public spreadsheets no longer show chart links that try to open internal Odoo menus or data sources. This avoids confusing public viewers with actions that would fail because they do not have backend access.
Original PR description
Task: 6449019 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
Fixed an issue where embedded document folder actions could be deleted by automatic cleanup when users were working in a different company. This helps multi-company users keep their configured journal entry shortcuts available and avoids unexpected loss of setup.
Original PR description
Step to reproduce: - You must have at least 2 companies with an account Journal - Create a New Journal Entry actions (child or parent) - Embed it to a folder - Set your company on a different one than the journal's one - Run the Garbage collector cron (Base: Auto-vacuum internal data) - The embed action has been removed The cause of this is that in the `_get_base_server_actions_domain` method in `documents_account` module there is a check on company to avoid using/running the actions when not in the right company. But the garbage collector don't need to have this check. Task-6147618 Forward-Port-Of: odoo/enterprise#122821
This fix prevents Helpdesk Repair tickets from crashing when a returned product has been changed and no longer matches the ticket product. Users can continue the repair workflow without encountering an unexpected error in this edge case.
Original PR description
## Steps to Reproduce: - Install the `helpdesk_repair` module. (with demo data) - Open the ticket titled **"Cabinet Colour and Lock aren't proper"**. - Go to Returns and change the product in Operations. - Click the "**Repair**" button on the ticket. ## Error: `IndexError - tuple index out of range` ## Cause: When the product on the picking does not match the ticket's product, the filtered picking recordset is empty. Accessing `[-1]` on an empty recordset raises an _IndexError_. ## Fix: Use `[-1:]` instead of `[-1]` when retrieving the matching picking, so an empty recordset is handled. sentry-7692929099 Forward-Port-Of: odoo/enterprise#130165 Forward-Port-Of: odoo/enterprise#129526
Invoice PDFs for Guatemala and Uruguay now show the correct identification label for customers when a non-default tax or ID type is selected. This avoids confusion and helps ensure customer identification details are presented accurately on official documents.
Original PR description
Currently invoice reports use the label related to the company's country for the partner's vat number, however in the case of latin america countries, a new field l10n_latam_identification_type_id is…
Currently invoice reports use the label related to the company's country for the partner's vat number, however in the case of latin america countries, a new field l10n_latam_identification_type_id is added to partners that allows the use of different identification types. This results in invoice reports showing the identification number next to an incorrect label. This commit fixes the issue for Guatemala and Uruguay by overriding the vat label in their respective invoice template to match the selected identification type. Steps to reproduce: - Install a latam localisation (Uruguay or Guatemala) - Change company to that country's Company - Create a partner located in said country, ensure the identification number is set to something else than the default one - Create an invoice for the partner, confirm it, and then Send it - In the pdf generated for the invoice you will see that under the partner's address the "vat number" has the wrong label opw-6087359 related to: https://github.com/odoo/odoo/pull/260159 Forward-Port-Of: odoo/enterprise#122512
This update fixes missing accent marks in Spanish fiscal position labels. It improves the quality and professionalism of Spanish localization text without changing business logic or workflows.
Original PR description
@Tecnativa Forward-Port-Of: odoo/odoo#284053
This fix ensures Belgian payroll reads the correct canteen cost information when calculating payslips. It completes a previous correction, helping avoid inaccurate payroll accounting for employee meal-related costs.
Original PR description
Previous fix 9c4acee2d324a454d12dd21388ae083f99c40416 was missing a change in the list of code to read. Forward-Port-Of: odoo/enterprise#130481
Blog content now displays bold formatting more reliably, even when the surrounding text uses a light font style. This makes emphasized text easier for readers and editors to recognize in website blog posts.
Original PR description
Problem: When a parent element applies a `font-weight: 300` to its content, a child `<strong>` tag defaults to `font-weight: bolder`, which resolves to a computed font weight of `400`. For certain font families, weight `400` is visually identical to `300`, leaving no visual distinction for bold text. Cause: `<strong>` tags relied on relative weight boosting (`bolder`), which only increases the parent weight from `300` to `400` instead of applying explicit bold weight. Solution: Explicitly set `font-weight: bold` on `strong` for `.o_wblog_read_text` Steps to reproduce: - Go to /blog - Open any blog - Open editor. - Select some text from the content of the blog. - Apply Bold. - Observe that there is no visual difference. opw-6460699 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#282667
This fix ensures bank reconciliation uses the correct user context when creating items quickly. It prevents mismatched settings from causing inconsistent behavior during automatic statement processing, improving reliability for accounting users.
Original PR description
Since this commit: https://github.com/odoo/enterprise/commit/938978c622700f9de097d9ff163f5b3c043231ed We pass the auto_statement_processing context key to false when destroying the component. The problem is that for the quick creation we use the model context. It might happen that those two contexts are different and can create inconsistancy. This commit will make sure the user context has priority on the global state context. no task id Forward-Port-Of: odoo/enterprise#130456 Forward-Port-Of: odoo/enterprise#129957
Tables pasted into the HTML editor from tools like Google Docs are now cleaned so only the first row remains a header. This prevents confusing table formatting and keeps pasted content consistent with what the editor supports.
Original PR description
Steps to Reproduce - Copy a table with multiple header rows from Google Docs. - Paste the table into the editor. Description of the issue: - The pasted table contains multiple header rows, but the editor supports only the first row as the table header row. Cause: - During paste, `cleanForPaste` does not handle tables with multiple header rows - As a result, header cells (`<th>`) in rows other than the first row remain as header cells instead of being converted to normal table cells (`<td>`). Solution: - Update `cleanForPaste` to handle tables with multiple header rows. - If a table contains `<th>` elements in any row other than the first row, replace those `<th>` elements with `<td>` elements. - This ensures that only the first row is treated as the table header row. task-6455248 Forward-Port-Of: odoo/odoo#286303 Forward-Port-Of: odoo/odoo#281234
This fix prevents an error during vendor bill payment when a user removes the currency while withholding tax is applied. The system now uses the company currency as a temporary fallback, allowing users to continue and choose a valid currency before saving.
Original PR description
Currently, an error occurs when user tries to pay on a vendor bill and removes the currency. Steps to replicate: - Install `l10n_account_withholding_tax`and activate multiple currencies. - Open…
Currently, an error occurs when user tries to pay on a vendor bill and removes the currency.
Steps to replicate:
- Install `l10n_account_withholding_tax`and activate multiple currencies.
- Open Invoicing > Vendors > Bills and create a new bill and add a vendor and bill date.
- Add a product and tax `2% WTH`.
- From the Cog menu > Click Pay > Remove the Currency.
Error:
```
File '/home/odoo/src/odoo/saas-19.4/addons/l10n_account_withholding_tax/models/account_withholding_line.py', line 208, in _compute_original_amounts
line.original_base_amount = line_curr.round(base_amount * rate)
File '/home/odoo/src/odoo/saas-19.4/odoo/addons/base/models/res_currency.py', line 264, in round
self.ensure_one()
File '/home/odoo/src/odoo/saas-19.4/odoo/orm/models.py', line 5342, in ensure_one
raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: res.currency()
```
Cause:
- As the user removed currency, the `comodel_currency_id`is received as false.
- Later when we call `round()` on the empty res.currency recordset causes this error to occur.
Solution:
- Added the company currency as a fallback value when `currency_id` is removed by user, since `currency_id` is a required field user will need to select a currency when saving.
sentry-7616890592
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#283405
Forward-Port-Of: odoo/odoo#277507