Friday, September 4, 2026
21 changes · saas-19.1
Resolved issues and error corrections
This fix improves the visual separation between vertical notebook tabs when using dark mode. It makes pages with these tabs easier to read and navigate, reducing confusion for users working in darker interface themes.
Original PR description
## Behavior Before the Commit When a user opens a page with a vertical notebook in dark mode, the different tabs aren't separate from one another. task-[5933892](https://www.odoo.com/odoo/project/4105/tasks/5933892) Forward-Port-Of: odoo/enterprise#126013
Vertical notebook tabs now line up correctly when shown in dialogs such as Kanban examples. Longer tab labels wrap cleanly onto a new line, keeping the page readable and preventing layout issues.
Original PR description
When a user opened a page with a vertical notebook, the tabs were not aligned with each other. Vertical notebooks should now have properly aligned tabs. If a tab title is too long, it will wrap onto the next line instead of breaking the layout. task-[5933892](https://www.odoo.com/odoo/project/4105/tasks/5933892) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#279098
Fixed an issue where helpdesk tickets linked to repairs could fail if a returned product was changed and no longer matched the ticket product. Users can now click the Repair button without encountering an error in this situation, improving reliability for support and repair workflows.
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#129526
This update fixes outdated internal documentation about how temporary records are protected. It clarifies that standard access rights and record rules apply, helping developers and administrators rely on accurate guidance when managing permissions.
Original PR description
Since 6d8688bb124d, TransientModel records use the regular access rights mechanisms instead of being implicitly restricted to their creator. The docstring was not updated with that change and has therefore incorrectly documented creator-only access since 14.0. Forward-Port-Of: odoo/odoo#286374 Forward-Port-Of: odoo/odoo#286251
This update fixes a cleanup issue in the HTML editor so file-related event handlers are properly removed when an editor is closed or replaced. It helps prevent gradual browser slowdowns or memory buildup when users work with multiple editor instances over time.
Original PR description
FilePlugin registered its click, keydown and pointerdown handlers with raw `addEventListener`, so they were never removed when the plugin was destroyed. The pointerdown one is bound to the document, which outlives the editable, leaking a handler per editor instance. Use `addDomListener` so Plugin.destroy() removes them. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#286144
Timesheet email suggestions from designated blocked addresses, such as online@odoo.com, are no longer automatically linked to projects or tasks. This prevents incorrect timesheet context from being assigned when certain generic or unwanted sender addresses are recognized in the database.
Original PR description
Before this commit, incoming email suggestions were automatically matched to tasks or projects whenever the sender’s email address could be linked to a partner in the database. In certain niche cases, this resulted in unwanted matches for specific email addresses or partners. After this commit, Email suggestions originating from designated addresses (e.g., online@odoo.com) are now excluded from task/project matching. task-[6414046](https://www.odoo.com/odoo/project/4105/tasks/6414046)
This fixes an issue where bank reconciliation quick creation could use conflicting settings when a screen was closed or refreshed. User-specific settings now take priority, helping prevent inconsistent behavior during statement processing.
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#129957
Fixes an issue where using the up or down arrow keys in certain website builder size fields only changed the preview temporarily. The selected value is now saved as expected, preventing edits from reverting after clicking away.
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
The inventory report layout was corrected by reverting a prior change that caused table rows to have more columns than the header. This prevents confusing or broken report displays for users reviewing stock information.
Original PR description
This reverts commit 43add3f72f29c35280869010b897c3c5656f5120. It was adding too many columns in table body after columns were removed from the header in 19.0. opw-6307728 Forward-Port-Of: odoo/odoo#286294
This update fixes an automated check for the Field Service report flow that could fail when expected test data was missing or a pop-up appeared. It helps keep quality checks reliable for this version without changing day-to-day user functionality.
Original PR description
The test database is nearly empty while the tour assumed an employee record to exist. The necessary information is created in test setup. The tour had an hidden error where it didn't properly sync around an interrupting modal. The step conditions have been updated to properly validate the modal. Fix **only** on 19.1, the industry_fsm* modules dissappear from the enterprise repo starting from 19.2. REF Runbot; https://runbot.odoo.com/odoo/error/234337
Reference fields now show a placeholder for the record selector, making it easier for users to notice when a linked record still needs to be chosen. This helps prevent incomplete links from being saved and later disappearing after the page is refreshed.
Original PR description
Steps to reproduce: 1. Install Sign. 2. Open the form view of a document. 3. Select a model in the "Link to" (Reference) field, but leave the record empty. 4. Save and refresh the page. Issue: -…
Steps to reproduce:
1. Install Sign.
2. Open the form view of a document.
3. Select a model in the "Link to" (Reference) field, but leave the record empty.
4. Save and refresh the page.
Issue:
- After refreshing, the selected model is cleared because the reference value is invalid.
Cause:
- A reference field is only valid when it contains both a model and a record ID. However, the record selector has no placeholder, making it easy to overlook and save an incomplete value.
Solution:
- Add a default placeholder to the record selector of reference fields to make it more visible.
<table>
<tr>
<th>Before</th>
</tr>
<tr>
<td>
<img src="https://github.com/user-attachments/assets/3ba34b77-f901-4d3e-9768-5acaf2e673b8" alt="Before" width="100%">
</td>
</tr>
<tr>
<th>After</th>
</tr>
<tr>
<td>
<img src="https://github.com/user-attachments/assets/1fe54b89-221f-4d28-bd2b-0a3c706d5746" alt="After" width="100%">
</td>
</tr>
</table>
opw-6426339
Forward-Port-Of: odoo/odoo#280266This update removes an older Point of Sale data cleanup step that is no longer needed. A newer, more targeted fix now handles stale loyalty reward lines, reducing the risk of removing more data than necessary while keeping checkout behavior reliable.
Original PR description
This fix is no longer required(https://github.com/odoo/odoo/pull/202752) as this one (https://github.com/odoo/odoo/pull/257043) is cleaner and less aggressive (it will only delete stale reward lines). This is the relevant part of the new fix to delete the previous one: https://github.com/odoo/odoo/pull/257043/changes#diff-18cef42f8c39513a82387e9cb81bc732b252304cd15b5b2f7b0b4623ac20cb41R100-R104 opw-6447092 Forward-Port-Of: odoo/odoo#286072 Forward-Port-Of: odoo/odoo#285376
Odoo now handles oversized web request addresses more gracefully when the server rejects them before reading all request details. This prevents an internal error during the response process and helps return the proper "request too long" response reliably.
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
This update ensures the website editor correctly recognizes the selected design option in more cases. It prevents certain composite editing actions from being ignored, improving consistency for users editing website content.
Original PR description
The function `useSelectableComponent` looked for the selected option by searching for the option with the highest priority among the options that are applied. The search for highest priority implicitely excluded options with negative priority. This case happens with `composite` action when the inner actions have no definition of `getPriority`. This commit initialize the "highest priority found so far" as `-Infinity` instead of 0. task-5245362 Forward-Port-Of: odoo/odoo#286503
Vendor bill XML imports now handle files that do not include a supplier country. When the country is missing from the XML, Odoo uses the country already saved on the supplier record, preventing an upload error and reducing manual correction work.
Original PR description
Steps to reproduce: - Install accounting and create BE company - Create BIS3 xml where there's no country for AccountingSupplierParty - From BE company, upload the xml vendor bill Current behavior: Error when trying to upload xml Expected behavior: No error Cause of issue: Currently there's no check to see if a country exists in the BIS3 xml. This PR adds a check and adds a fallback to get the country attached to the partner record if there's none present in the xml opw-6498830 Forward-Port-Of: odoo/odoo#284862 Forward-Port-Of: odoo/odoo#284554
French electronic invoices that are already paid will now automatically include the required due date, matching the payment date. This helps ensure exports comply with the latest French invoicing validation rules and avoids rejected documents.
Original PR description
According the schematron v1.4, the cbc:DueDate is required when the move is PAID. "[BR-FR-CO-09/BT-23] : Si le cadre de facturation (BT-23) est B2, S2 ou M2, alors la date d’échéance (BT-9) doit être renseignée et correspondre à la date de paiement." no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#286263
Product pages now keep thumbnail sizes consistent when image auto-cropping is disabled. This prevents unusually wide or tall product images from disrupting the thumbnail row or making the main carousel image appear misaligned, improving the shopping experience.
Original PR description
Steps to reproduce: =================== 1. Add several images to a product, one of them much wider than tall. 2. On the product page, set the image ratio to "Disabled". 3. Move the thumbnails below…
Steps to reproduce: =================== 1. Add several images to a product, one of them much wider than tall. 2. On the product page, set the image ratio to "Disabled". 3. Move the thumbnails below the image. => The wide thumbnail sits at the top of its slot, with blank space under it. Root cause: =========== Thumbnails are given a fixed width of 64px and take their height from `aspect-ratio: var(--o-wsale-product-image-ratio)` [1]. With cropping disabled that variable is `auto`, so each thumbnail keeps the shape of its own image and they no longer share a height. They sit in a flex row, which stretches every slot to the height of the tallest one. The image inside keeps its own height and stays at the top of the slot, so a wide image leaves the rest of its slot empty. The slots are only stretched when the images differ in height, which is why the problem needs cropping to be disabled, and why it does not appear when every image is a landscape one. - [1] sized the thumbnails from the image ratio. Fix: ==== Center the thumbnails in the row so each one keeps the height of its own image instead of being stretched to the tallest. Their width stays at 64px, so a row of wide images still takes the same space as before and none of them is pushed out of the container. [1]: 670b1daa2254 opw-6472484 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#283246
Fixes an issue in the demo payment provider where refunds after manually capturing a payment could get stuck as only authorized. This prevents blocked refund workflows and incorrect negative authorized amounts during testing or demonstrations.
Original PR description
Issue: --- When using manual capture, you can refund the transaction but it will be only authorized, and you'll then be blocked with a negative authorized amount and the impossibility to refund it. This seems to be specific to demo payment provider. Steps: 1- Enable manual capture on demo provider. 2- Buy a product from shop and checkout and pay. 3- Capture the payment in backend. Then click on post process. 4- Try refund. opw-6413515 Forward-Port-Of: odoo/odoo#286084 Forward-Port-Of: odoo/odoo#282315
This fix ensures remaining hours on sales order lines are recalculated when relevant unit or availability information changes. Businesses get more reliable project and timesheet tracking without manual refreshes or incorrect remaining-hour figures.
Original PR description
The dependencies of _compute_remaining_hours do not match the fields actually used for the computation: it lists analytic_line_ids, which it never uses, and omits both remaining_hours_available, and product_uom. _compute_remaining_hours_available has the same issue: it uses product_uom but only depends on product_id.service_policy. analytic_line_ids, on the other hand, can be dropped: qty_delivered already depends on it, along with its so_line, unit_amount, product_uom_id and project_id, so the timesheet flow keeps triggering the recomputation. This PR fixes the dependencies for both aforementioned compute methods. Task-4748521 Forward-Port-Of: odoo/odoo#285685 Forward-Port-Of: odoo/odoo#284750
Updated internal tests so they use the same timezone setting as the application when checking date-based sequence values. This prevents rare overnight test failures and helps keep releases more stable without changing user-facing behavior.
Original PR description
## Issue By default in Odoo, `datetime.now()` returns the UTC time, which is two hours behind the local time in Belgium. This leads to two tests failing when executed between 00:00 and 02:00 Belgian…
## Issue By default in Odoo, `datetime.now()` returns the UTC time, which is two hours behind the local time in Belgium. This leads to two tests failing when executed between 00:00 and 02:00 Belgian time: `test_ir_sequence_interpolation_dict` and `test_ir_sequence_iso_directives`. The `_interpolate_dict` method (responsible for interpolating the prefix/suffix from the sequences) specifies the tzinfo when calling `datetime.now()`: https://github.com/odoo/odoo/blob/9c67949be529eb86886b3d5bde08e81e048ecfe7/odoo/addons/base/models/ir_sequence.py#L211-L212 Since this is not the case in the tests, the tests evaluate the date using UTC. This creates a two hours difference between the time expected and the time actually used by `next_by_code`. The tests thus fail between 00:00 and 02:00 because the evaluate dates from both `datetime.now` calls differ, leading to a mismatch in the expected prefixes. ## Fix We force the `env.tz` on the `datetime.now()` call, to mimic the behavior from the `_interpolate_dict`. runbot-242662 Forward-Port-Of: odoo/odoo#284955
Selecting a company or contact suggestion now correctly updates the form status after the record is enriched and saved. This prevents users from seeing save or discard buttons that no longer have any action, reducing confusion during partner data entry.
Original PR description
Steps to reproduce: 1) open partner form view 2) type in the name field 3) select a suggestion from the autocomplete dropdown Issue: The record is enriched and saved, but the form still displays the save/discard buttons, and clicking them does nothing. The record dirty indicator is driven by 2 signals 1) `model.root.dirty`, which is cleared by save() call earlier in the onSelect() 2) the state `fieldIsDirty` of the `FormStatusIndicator` The second indicator is set to true when the user types in an input field, and selecting an option never clears it. The `setDirty` prop no longer exists, and therefore was deadcode. This commit emits `FIELD_IS_DIRTY` bus event, which is the only way to update the second indicator. With that, the indicator goes back to saved state once the record is updated. task-6475332 Forward-Port-Of: odoo/odoo#286268 Forward-Port-Of: odoo/odoo#285897