Thursday, September 24, 2026
3 changes · 18.0
Resolved issues and error corrections
This fix prevents chatter actions from discarding a user's unsaved form changes when the record cannot be saved, such as when a required field is empty. Users will now keep their in-progress edits instead of seeing the form revert to the last saved values after posting a message or changing followers.
Original PR description
Before this commit, posting a message in the chatter of a form view with `post_refresh` lost the unsaved changes of an invalid record, for instance after emptying a required field. The form showed the invalid field for a moment, then came back with the saved values. The same happens on the other chatter actions that reload the form, such as a follower change. This happens because the chatter reloads the record after it tries to save it, even when the save fails. This commit fixes the issue by reloading the record only when the save succeeds. Forward-Port-Of: odoo/odoo#290204
This fix prevents the HTML editor from showing an error when users select text beyond the editor area, such as with Ctrl+A or by dragging. It improves editing reliability in Chromium-based browsers like Chrome and Edge while keeping existing behavior unchanged.
Original PR description
## Description Fixes issue #187539 where selecting text that extends outside the HTML editor boundaries throws an uncaught promise error. ## Problem When using Ctrl+A or dragging a selection from inside the editor to outside its boundaries, the `updateSelectionTable` method in `table_plugin.js` would process the invalid selection and call `setSelection()` with nodes outside the editable area, causing: This only affected Chromium-based browsers (Chrome, Edge) as Firefox already had protection against this scenario. ## Solution Added a safety check in `updateSelectionTable` to verify that the document selection is within the editable area before processing table selection updates. This extends the same protection Firefox had to all browsers. ## Changes - `addons/html_editor/static/src/main/table/table_plugin.js`: Added validation check - `addons/html_editor/static/tests/table/selection.test.js`: Added regression test Closes #187539
Contact merges now correctly check linked portal users across all accessible company contexts before allowing a merge. This prevents multiple user accounts from being accidentally attached to the same contact when users switch companies, preserving data integrity and consistent behavior.
Original PR description
Switching companies can let a contact merge bypass the check that prevents multiple users from ending up linked to the same contact. ### Steps to reproduce 1. As a user with Contact Creation rights…
Switching companies can let a contact merge bypass the check that prevents multiple users from ending up linked to the same contact. ### Steps to reproduce 1. As a user with Contact Creation rights and access to companies A and B, select company A. 2. Create two contacts with no company set and grant each portal access. 3. Select only company B. 4. Merge the contacts. The merge succeeds and links both portal users to the surviving contact. With company A selected, the same merge is correctly rejected. ### Cause The wizard checks that the contacts have at most one linked user in total, including archived users. However, it reads `user_ids` with the acting user's permissions. Company record rules hide both portal users when only B is selected, so the check finds none. The subsequent SQL update still moves both users' contact links to the surviving contact. ### Fix Use `sudo()` only for this check, since it must count every user whose link the merge would move. Retain `active_test=False` to include archived users. Add a regression test covering both company selections. opw-6586945