Friday, August 28, 2026
4 changes · saas-19.1
Security fixes and vulnerability patches
This update makes Odoo consistently enforce access permissions when related records are changed through background context commands. Unauthorized changes are now blocked in the same way as regular field updates, reducing the risk of hidden permission bypasses and improving data protection.
Original PR description
Some commands may perform a change on related records by using Commands. When passed through the context, unallowed actions are ignored instead of rising access errors. This check aligns the behaviour with normal writes of fields. A test in `project` module shows this behaviour. Backport of odoo/odoo#258845 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#285132 Forward-Port-Of: odoo/odoo#284501
Self-ordering payment notifications no longer include full order details when updates are sent in real time. This reduces unnecessary data sharing while keeping order status updates working for customers and staff.
Original PR description
Remove the order data from the websocket notification. Forward-Port-Of: odoo/odoo#284631
When a production database is neutralized for testing, staging, or support, saved outgoing mail usernames and passwords are now cleared. This prevents real email relay credentials from being carried into database copies while keeping email sending disabled as before.
Original PR description
### Impacted versions 19.0 (the same applies to every branch shipping `base/data/neutralize.sql`) ### Steps to reproduce 1. On a database with an outgoing mail server configured with a username and…
### Impacted versions 19.0 (the same applies to every branch shipping `base/data/neutralize.sql`) ### Steps to reproduce 1. On a database with an outgoing mail server configured with a username and password, neutralize it (`odoo-bin neutralize`, or restore/duplicate with neutralization enabled). 2. Look at the `ir_mail_server` row. ### Current behavior The server is archived, so the database can no longer send. `smtp_user` and `smtp_pass` are left untouched, so the credentials stay in the database and travel with every dump taken from it. The password still authenticates against the real relay. ### Expected behavior Neutralization is what turns a production database into one that can be copied and handed around — a staging build, a dump downloaded for debugging. A database that is not allowed to send mail has no use for a credential to send it with, and keeping it means the credential leaves the platform with the copy. ### Fix Clear `smtp_user` and `smtp_pass` in the same statement that archives the servers. The stub relay inserted just below still blocks the fallback to the command-line SMTP settings, so behavior is unchanged otherwise. Tested by seeding a mail server with credentials, running the file, and checking the row: archived, credentials empty, stub relay present. Forward-Port-Of: odoo/odoo#284960
The Sign app now checks whether a user can access signature data without automatically using elevated permissions. This helps ensure signature information is only accessed through the intended permissions path, while still allowing authorized elevated access when explicitly needed.
Original PR description
If the signature is needed with sudo, the user can read directly sign_signature_data.