Odoo Changelog — 2026-04-14

Tuesday, April 14, 2026

2 changes · 19.0

Improvements(2)

Enhancements to existing features

[IMP] account_budget: include asset accounts in budget report

Enterprise19.0accountMEDIUM

This update enhances budget reporting by automatically including asset accounts (current, non-current, and fixed) in budget reports. This provides a more complete financial picture for users who track expenses and budgets related to company assets.

Original PR description

Expand the scope of budget tracking to include asset accounts.

Modified the account filtering logic so that when a budget type is set to "Expenses" or "Both", the query includes 'asset_current', 'asset_non_current', and 'asset_fixed' account types.

task-5994048

Forward-Port-Of: odoo/enterprise#109496

#budget#assets#reporting

[IMP] hr_contract_salary: offer amendment

PR #103846

Enterprise19.0hr_contract_salaryMEDIUM

This update automatically treats new offer start dates within existing contract periods as amendments, creating new contract versions and archiving outdated ones. A warning alerts users to potential replacements, ensuring data accuracy and preventing conflicts. This improves the management of employee contracts and simplifies the versioning process.

Original PR description

**Contract Amendment & Versioning Logic** * When an offer's contract start date falls within an existing contract period, it is treated as a contract amendment (new version) rather than a new…

**Contract Amendment & Versioning Logic**

* When an offer's contract start date falls within an existing contract period, it is treated as a contract amendment (new version) rather than a new contract.
* For contract amendments, the offer's contract end date is read-only and automatically inherited from the existing contract.
* When creating a new offer, any existing versions with effective dates **on or after** the new offer's contract start date are automatically archived, as they likely contain outdated data.
* Added a warning to notify users when a new offer will replace existing future versions.

**Technical Refactoring**

* Simplified the `employee_version_id` computation by delegating to the existing `_get_version` method on the employee model. This ensures the selected employee version correctly matches the contractual state effective at the new offer's
* Ensured cache invalidation after rollback savepoints to prevent stale data. The overridden `_get_version` in `hr_contract_salary_payroll` writes to `employee.version_id` and the `contract_template_id`; although rolled back, it polluted the cache. We now always invalidate the cache after rollbacks to avoid inconsistencies, including later module installation.

**Simulation & Chatter**

* Inside the simulation, when calling `_get_version`, we need to adjust the contract dates of the version being simulated. The main challenge is allocating this simulated version between existing employee versions without creating contract overlaps, since overlaps raise validation errors.
* To avoid this issue, we move to a new approach. We archive all versions after `employee.version_id` and set `employee.version_id.contract_date_end = False`.
* Then, instead of replacing the active version, we create the simulation version as an amendment to `employee.version_id`. The amendment's effective date is set to `max(fields.Date.today(), employee.version_id.contract_date_start, self.contract_start_date)` + 1 day. This ensures the current version remains unchanged, avoids contract overlaps, and prevents chatter pollution.

task: 5408192

#contracts#offers#versions#employee management

Expand the scope of budget tracking to include asset accounts. Modified the account filtering logic so that when a budget type is set to "Expenses" or "Both", the query includes 'asset_current', 'asset_non_current', and 'asset_fixed' account types. task-5994048 Forward-Port-Of: odoo/enterprise#109496

**Contract Amendment & Versioning Logic** * When an offer's contract start date falls within an existing contract period, it is treated as a contract amendment (new version) rather than a new contract. * For contract amendments, the offer's contract end date is read-only and automatically inherited from the existing contract. * When creating a new offer, any existing versions with effective dates **on or after** the new offer's contract start date are automatically archived, as they likely contain outdated data. * Added a warning to notify users when a new offer will replace existing future versions. **Technical Refactoring** * Simplified the `employee_version_id` computation by delegating to the existing `_get_version` method on the employee model. This ensures the selected employee version correctly matches the contractual state effective at the new offer's * Ensured cache invalidation after rollback savepoints to prevent stale data. The overridden `_get_version` in `hr_contract_salary_payroll` writes to `employee.version_id` and the `contract_template_id`; although rolled back, it polluted the cache. We now always invalidate the cache after rollbacks to avoid inconsistencies, including later module installation. **Simulation & Chatter** * Inside the simulation, when calling `_get_version`, we need to adjust the contract dates of the version being simulated. The main challenge is allocating this simulated version between existing employee versions without creating contract overlaps, since overlaps raise validation errors. * To avoid this issue, we move to a new approach. We archive all versions after `employee.version_id` and set `employee.version_id.contract_date_end = False`. * Then, instead of replacing the active version, we create the simulation version as an amendment to `employee.version_id`. The amendment's effective date is set to `max(fields.Date.today(), employee.version_id.contract_date_start, self.contract_start_date)` + 1 day. This ensures the current version remains unchanged, avoids contract overlaps, and prevents chatter pollution. task: 5408192