Monday, September 7, 2026
13 changes · saas-19.2
Resolved issues and error corrections
This fixes vendor bill processing so businesses can create assets that do not depreciate when needed. It removes an overly restrictive account check that previously blocked valid asset creation, helping accounting teams record these assets correctly.
Original PR description
This commit fixes the ability to create no depreciation assets from vendor bills. Previously, a condition on the depreciation account and expense account restricted the asset creation. backport of https://github.com/odoo/enterprise/pull/123070 task-6283929 opw-6540498
This fixes an issue where a sales order line removed from a planning shift could come back automatically after other shift changes. The shift now only updates its sales link when the related project or task changes, preventing unwanted changes to user-entered planning data.
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
The systray timer now loads only timesheet entries that are linked to a project. This prevents unrelated time entries from appearing in the timer, making time tracking clearer and reducing confusion for users.
Original PR description
exclude AAL without a project when loading systray timer data task: 6538364
Rental order lines created from the rental schedule now keep clean product names, such as “Bike,” instead of adding stock quantities to the line description. Stock quantities still appear where they are useful in schedule rows, reducing confusion while preserving schedule visibility.
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
This fix prevents Helpdesk Repair tickets from crashing when a returned product is changed and no longer matches the ticket product. Users can continue creating repairs from tickets without hitting 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
Fixed an issue where document folder shortcuts for journal entry actions could be removed by the automatic cleanup when users were working in another company. This helps multi-company users keep their embedded accounting actions available and avoids unexpected loss of folder configuration.
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
Invoice PDFs for Guatemala and Uruguay now show the partner’s selected identification type label instead of a default country VAT label. This prevents customer documents from displaying misleading tax ID descriptions when partners use alternative local identification types.
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 accounting localization text. It improves the accuracy and professionalism of labels shown to Spanish users without changing functionality.
Original PR description
@Tecnativa Forward-Port-Of: odoo/odoo#284053
This fix keeps the spreadsheet template search bar visible even when no templates match the search. It also prevents errors when users add a custom filter, making template selection in Documents smoother and more dependable.
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
The website editor now correctly saves size adjustments made with the keyboard arrow keys in range-based controls. This prevents changes from appearing temporarily and then reverting when the user clicks away, making snippet editing more reliable.
Original PR description
When a BuilderRange is displayed with its optional number input, using ArrowUp/ArrowDown updates the preview but does not save the new value. The range component passes its handler through onKeydown, while BuilderNumberInputBase only calls onKeydownArrow after handling arrow keys. As a result, the debounced commit is skipped. Steps to reproduce: - Drop a s_social_media inner snippet - Click on the snippet, then click on the "Size" input - Use "ArrowUp" to increase the value of the number input - Click anywhere on the page => The size goes back to the previous one. task-6385984 Forward-Port-Of: odoo/odoo#283504
This fix ensures bold formatting in blog articles is visibly distinct, even when the surrounding text uses a light font weight. It helps editors and readers see emphasized content as intended, improving readability and presentation consistency.
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 quick creation uses the user's current settings before shared page state. It prevents inconsistent behavior when leaving or refreshing the reconciliation screen, helping accounting users get more reliable results.
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
Odoo now handles unusually long web request addresses more gracefully when the server rejects them early. This avoids an internal error during the error 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