Odoo Changelog — 2026-07-07

Tuesday, July 7, 2026

2 changes

Branch: saas-19.3

1 change

Security(1)

Security fixes and vulnerability patches

[FIX] sign: harden "Auto write" feature against edge cases

PR #115118

Enterprisesaas-19.3signSECURITY

The Sign app now prevents Auto write from being enabled in situations where it could update records unintentionally or without a valid linked field. This reduces the risk of accidental or unauthorized changes to sensitive information while improving feedback when automatic updates cannot be completed.

Original PR description

Fix scenarios where the auto-write feature could fail or be unsafe:

- Prevent unsafe mass updates: Users could enable auto-write in bulk without proper awareness, leading to unintended behavior. Additionally, the field could be manually exposed even when no linked model/field is set. we add safeguards and constraints to prevent enabling it in invalid cases.

- Improve test coverage: Update test cases to ensure correct behavior when users have access to partner records but must not be allowed to update sensitive fields (e.g., email) of other users through those records.

task-6147410

#sign#auto-write#data-protection#permissions

Branch: master

1 change

Security(1)

Security fixes and vulnerability patches

[IMP] hr_appraisal: validate read/write access

PR #108701

Enterprisemasterhr_appraisalhr_appraisal_skillsSECURITY

Appraisal permissions are now enforced in the underlying business logic, not only in the web interface. This helps prevent employees from using APIs to change restricted appraisal information or perform manager-only actions.

Original PR description

A lot of the access restrictions within the appraisal app, such as field visibility, editability and certain actions, were enforce only at the view layer through invisible/read-only. This works great for the usual case when uses the web-ui. However, when using the JSON2 API to interact with the appraisal app, the user could bypass these "security rules" as the usual invisible/read-only restrictions don't apply to the API. So a normal user could for example, modify the private note or mark an appraisal as done through the API which was impossible for them to do through the web-ui.

This PR introduces the same security rules and validations to the model layer itself which makes it harder to perform unauthorized actions regardless of the interfaces.

Task-5926306

#appraisals#access control#API security

Fix scenarios where the auto-write feature could fail or be unsafe: - Prevent unsafe mass updates: Users could enable auto-write in bulk without proper awareness, leading to unintended behavior. Additionally, the field could be manually exposed even when no linked model/field is set. we add safeguards and constraints to prevent enabling it in invalid cases. - Improve test coverage: Update test cases to ensure correct behavior when users have access to partner records but must not be allowed to update sensitive fields (e.g., email) of other users through those records. task-6147410

A lot of the access restrictions within the appraisal app, such as field visibility, editability and certain actions, were enforce only at the view layer through invisible/read-only. This works great for the usual case when uses the web-ui. However, when using the JSON2 API to interact with the appraisal app, the user could bypass these "security rules" as the usual invisible/read-only restrictions don't apply to the API. So a normal user could for example, modify the private note or mark an appraisal as done through the API which was impossible for them to do through the web-ui. This PR introduces the same security rules and validations to the model layer itself which makes it harder to perform unauthorized actions regardless of the interfaces. Task-5926306