Monday, September 7, 2026
11 changes · saas-19.3
Resolved issues and error corrections
This fix prevents a shift from automatically restoring a previously removed sales order line when unrelated shift details are edited. The sales link will now only update when the linked project or task changes, reducing unexpected billing or planning changes for users.
Original PR description
Before this commit, when a change is made in a shift, the SOL initially removed by the user can be set by the one set on the task/project linked to that shift. The reason is because each time the compute of SOL field is triggered, the compute will set the SOL of the task or the project linked. The problem is we only want that behavior when the user changes the project or the task. This commit removes the logic the compute to set the SOL of the project/task, to do that logic inside an onchange method instead. Task-6354078 Forward-Port-Of: odoo/enterprise#125814
This fixes an automated stock workflow test so it searches for the exact product name instead of a broad term. The change prevents the test from selecting the wrong product when another item has a similar reference, improving test reliability without changing user-facing behavior.
Original PR description
When searching for the product created in the test we were only searching for "Serial" but another product with this word in the internal reference was showing up alone. To fix this we now look for the exact product name to avoid finding another product. The other matching record was introduced in this commit : https://github.com/odoo/enterprise/commit/6d4f4ec471d0d20c4deae5ad5d4fd4f803c20933 runbot-242820
This update fixes missing accent marks in Spanish localization data. It improves the quality and professionalism of displayed Spanish fiscal position names without changing business logic or workflows.
Original PR description
@Tecnativa Forward-Port-Of: odoo/odoo#284053
Invoice PDFs for Guatemala and Uruguay now show the partner’s selected identification type label instead of using the company country’s default VAT label. This prevents customers from seeing a misleading label next to their identification number on official invoice 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 fix keeps the spreadsheet template search bar visible even when no templates match the search. It also prevents an error when users choose to add a custom filter, making template selection in Documents smoother and more reliable.
Original PR description
- templates searchbar disappear when the search has no match - Clicking "Add a custom filter' in the searchbar crashes Task-6526322 Forward-Port-Of: odoo/enterprise#130376 Forward-Port-Of: odoo/enterprise#130096
Rental order lines created from the rental schedule now keep the normal product name instead of adding stock quantities to the line description. Stock quantities still appear where they are useful: in the schedule rows, helping users plan availability without cluttering order details.
Original PR description
Versions -------- 19.0 and later Steps ----- - Install `sale_stock_renting`. - Go to Rental > Orders > Rental Schedule. - Create a new rental order line from a cell of the gantt view, on a row…
Versions -------- 19.0 and later Steps ----- - Install `sale_stock_renting`. - Go to Rental > Orders > Rental Schedule. - Create a new rental order line from a cell of the gantt view, on a row grouped by a storable rentable product. Issue ----- The first line of the description of the created line is named "Bike (3 items)" instead of "Bike". Cause ----- The `display_name` override adding that quantity is keyed on the `in_rental_schedule` context key. That key is set on the `action_rental_order_schedule` action itself, so it is part of the search context and is propagated to every record, dialog and dropdown opened from the schedule, while it is only meant to flag that we are in the schedule (default values conversion, hidden onchange buttons, group expansion, ...). Solution -------- Introduce a dedicated `display_renting_stock_quantity` context key and depend on it instead when fetching data to build the gantt rows, leaving the records opened from the schedule with their regular display name. Forward-Port-Of: odoo/enterprise#130513 Forward-Port-Of: odoo/enterprise#130322
Fixed an issue where helpdesk repair tickets could crash if a return operation was changed to a different product before starting a repair. This keeps the repair workflow available and avoids an unexpected error for support teams handling returns.
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
Fixed an issue where gradient angle edits in the website editor color picker could be lost after saving. This ensures users see the same gradient direction they selected when reopening or viewing the edited content.
Original PR description
Problem: When changing the gradient angle input in the color picker and saving the record, the updated angle is not saved and reverts to the previous value. Cause: `setOnCloseCallback` runs before `onAngleChange` because the angle input fires the `change` event on blur/close. As a result, `onColorGradientChange` is called with the previous angle value, and `onColorGradientPreview` runs afterwards with the new value, causing the applied preview to be reverted later. Solution: Call `onAngleChange` on the `input` event instead of `change` so that state and preview update immediately each time the user types. Steps to reproduce: - Add a gradient to a building block. - Define a value of 180 degrees. - Save - If you open the color picker the value is still 135. task-6522533 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#285967
This fix ensures Odoo responds properly when a web request address is too long and is rejected early by the server. It avoids an internal error during that response, improving reliability for edge-case web traffic.
Original PR description
- When the request URI is too long, the HTTP server rejects the request before parsing the headers. As a result, `self.headers` is not available when the WebSocket compatibility code in `send_header()` and `end_headers()` is executed. - Access `self.headers` safely to avoid an AttributeError while handling the 414 response. **opw-6501275** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#286494 Forward-Port-Of: odoo/odoo#285870
Blog posts now show bold formatting more reliably, even when the surrounding text uses a light font style. This helps editors and readers clearly see emphasized text as intended.
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 fixes an inconsistency in bank reconciliation when quick-creating records by making the user’s context take priority over the global state context. It helps prevent unexpected behavior during statement processing and record creation.
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