Thursday, September 24, 2026
4 changes · 18.0
Enhancements to existing features
Odoo will now notify the right administrators when a Xendit payment setup needs its webhook settings updated for Xendit's v3 events. This helps prevent missed payment or card status updates after Xendit phases out the old webhook configuration.
Original PR description
Xendit replaced the single "Invoices paid" webhook field with separate v3 event groups (Payment tokens v3 / Payment requests v3). Databases that had Xendit configured before this change stop…
Xendit replaced the single "Invoices paid" webhook field with separate v3 event groups (Payment tokens v3 / Payment requests v3). Databases that had Xendit configured before this change stop receiving payment and card token status updates until the Xendit Dashboard is updated with the new fields. Hook into the daily autovacuum cron instead of a dedicated one or an upgrade-triggered migration script: SaaS/.sh don't force module upgrades, so a migration script would only catch the providers, companies, and admins that existed at the exact moment of the upgrade, and a dedicated ir.cron record wouldn't exist on already-installed databases until then either. @api.autovacuum methods are discovered directly from the Python class, so they run immediately everywhere, keep covering providers and admins added later, and can be removed later by deleting the method, with no leftover cron record to clean up through a migration. For the same reason, track whether admins were already notified by checking for an existing pending activity instead of adding a stored field on payment.provider: a new column wouldn't exist either on databases where the module isn't upgraded, and the ORM would error on any domain filtering on it. Notify base.group_system, account.group_account_manager, and sales_team.group_sale_manager rather than only Sales admins: those are the groups actually granted write access to payment.provider and its Xendit credential fields, or otherwise likely to own the provider's configuration, and covering all three means databases using Xendit without the Sales app installed (e.g. through Invoicing or Point of Sale) still have someone to notify. A user in more than one of these groups is only notified once. The activity note explains why the change is needed and links the "webhook configuration" and "Xendit Dashboard" mentions inline to the Odoo documentation and to the Xendit Dashboard's webhook settings, respectively, calling out the October 1, 2026 date after which the old webhook field stops being honored. Task-6373405 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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