Wednesday, September 16, 2026
7 changes · saas-19.1
Resolved issues and error corrections
This fixes an issue in Discuss where quickly deleting the same attachment preview more than once could trigger an error, especially on slow connections. The system now tracks attachments already being removed, preventing duplicate requests and making attachment handling smoother for users.
Original PR description
**Steps to reproduce:** - Open Discuss app - Open any conversation - Setup the browser with throttled connection (e.g. Slow 4G) - Select multiple files to attach but don't send the message - While…
**Steps to reproduce:**
- Open Discuss app
- Open any conversation
- Setup the browser with throttled connection (e.g. Slow 4G)
- Select multiple files to attach but don't send the message
- While some are loading, double click the delete button of one of the loaded attachment preview
- Traceback will appear: `404 Not Found`
**Issue:**
On click the delete button triggers a deletion request on `/mail/attachment/delete`.
Repeatedly clicking the delete button before the first request was completed (and the `AttachmentList` get updated) but after the attachment was deleted, will cause a `404 Not Found` due to the `raise NotFound()` which was added by [1] in `mail_attachment_delete`.
```py
attachment = request.env["ir.attachment"].browse(int(attachment_id)).exists()
if not attachment or not attachment._has_attachments_ownership([access_token]):
request.env.user._bus_send("ir.attachment/delete", {"id": attachment_id})
raise NotFound()
```
**Fix:**
Prevent concurrent deletion requests for the same attachment by keeping track of attachments currently being deleted.
[1] https://github.com/odoo/odoo/commit/50f45dd436b97027cb1461410efeee7057dad4e8#
opw-6499125
Forward-Port-Of: odoo/odoo#285060The website editor color picker and shop comparison bar now handle longer translated labels more reliably. This prevents layout issues and ensures styling works consistently for users working in languages such as German.
Original PR description
Steps to reproduce: - Set the user language to German. - Open a color picker with the `Theme` tab in the website editor. - Check the color presets and the reset button. - Open the product comparison bar on the shop page. => Long labels do not fit and some styles are missing. Before this commit, long labels did not fit in the color preset picker. Some CSS selectors also relied on English `title` values, so their styles were not applied in other languages. After this commit, the preset picker adapts to long labels and the CSS selectors use dedicated classes that work in every language. task-6259086 Forward-Port-Of: odoo/odoo#286426
Testing a custom recorded tour from the tours list now properly loads the tour data before running it. This prevents the action from silently doing nothing, making it easier for users to validate recorded guidance and workflows.
Original PR description
Clicking "Testing" on a custom/recorded tour called startTour with mode "auto" and fromDB true, but getTour() only loaded from the database when mode was "manual". For a tour that only exists in the web_tour.tour record (not in the client-side registry), this left `tour` undefined and startTour() silently did nothing. Load from the database whenever fromDB is set, regardless of mode. Task-id: 6575435
The map view now uses the record limit configured on the action when no map-specific limit is set. This makes map behavior consistent with list and kanban views, helping users see the expected number of records.
Original PR description
Backport of odoo/enterprise#130336 The map view only considered the `limit` set in the arch, ignoring the one coming from the action (`ir.actions.act_window.limit`), unlike other views (list, kanban) which fall back to it. task-6531776 Forward-Port-Of: odoo/enterprise#131423
Adds a test to ensure batch invoicing for multiple subscription orders uses each order's own billing period. This helps prevent invoices from accidentally including timesheet entries outside the correct date range.
Original PR description
A test case to guarantee that batch invoicing multiple orders respects their individual time frames. This test is made to assert the fix in this [PR](https://github.com/odoo/odoo/pull/284781) opw-6507110 Forward-Port-Of: odoo/enterprise#130928 Forward-Port-Of: odoo/enterprise#129404
Clicking at the end of text inside an editor button now keeps the cursor in the expected position instead of jumping outside the button. This makes editing button labels more reliable and prevents frustrating text editing behavior for website or content editors.
Original PR description
Problem: When trying to place the caret at the end of a button's content with the mouse, the caret always moves outside of the button instead of staying inside it. Cause: This happens because of the previous commit https://github.com/odoo-dev/odoo/commit/c8e93dbc806b5ea511cce695afbc9e81e30a1ca9 (which aimed to fix placing the caret after a link when at the end of a paragraph in the editable), which was not fixing the issue properly. Solution: Check if the click happens at the end of a link and the caret will move inside the link then manually place the selection after the link. Steps to reproduce: - Add a button with one character. - Try to put selection after that character. - Selection always jumps after the button. opw-6499237 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#287853 Forward-Port-Of: odoo/odoo#284197
This fixes a form display issue where Save and Discard buttons could remain visible even after there were no real changes left to save. Users who re-enter equivalent values, such as the same number with different formatting, will now see the form return correctly to its clean state.
Original PR description
**Description of the issue/feature this PR addresses:** Fixes #287978 In `useInputField` (`input_field_hook.js`), `onChange` and `commitChanges` only trigger the `FIELD_IS_DIRTY` bus event with…
**Description of the issue/feature this PR addresses:** Fixes #287978 In `useInputField` (`input_field_hook.js`), `onChange` and `commitChanges` only trigger the `FIELD_IS_DIRTY` bus event with `false` when the newly typed value actually differs from the value already stored on the record. When the typed text parses to the *same* value as what is already on the record (e.g. retyping `6,250` after the field already holds `6,25`), the code takes the `else` branch, which only resets the displayed text and never notifies the bus that the field is no longer dirty. `form_status_indicator.js` keeps whatever `fieldIsDirty` state it last received from that bus event, and shows the Save/Discard buttons whenever `root.dirty || fieldIsDirty`. Since nothing ever fires `FIELD_IS_DIRTY(false)` in that `else` branch, `fieldIsDirty` stays stuck at `true`. `Discard` correctly resets `root.dirty`, but has no way to reset `fieldIsDirty`, so the Save/Discard buttons keep showing even though the record is clean. **Current behavior before PR:** 1. Edit a field to a new value, click away (value committed, indicator shows Save/Discard as expected). 2. Edit the same field again, this time typing different text that parses to the *same* value (e.g. `1.20` when the field already holds `1.2`), click away. 3. Click **Discard**. The record is reverted, but the Save/Discard buttons remain visible. They stay stuck until the page is reloaded. **Desired behavior after PR is merged:** Retyping different text that parses to the same value clears the field's dirty state like any other case where the field ends up unchanged, so Discard (or any other action) correctly hides the Save/Discard buttons once there is nothing left to save. Forward-Port-Of: odoo/odoo#288030