Thursday, April 2, 2026
6 changes · 17.0
New functionality added to Odoo
This update introduces a new tool for securely generating and verifying tokens. The primary goal is to reduce the storage of individual tokens by using signed payloads instead, improving security and efficiency. This change enhances the system's ability to manage access and permissions.
Original PR description
Backport of fd94042de04682895b90624c0a27639cfa7694bf Add a tool to generate signed payload to be used as token. The main purpose is to stop storing every token. Two functions are added: `odoo.tools.misc.hash_sign()` This functions takes as required arguments, a json dumpable payload, a scope as a string, a sudo environnement, and finally either and expiration as datetime.datetime, or expiration_hours as an int. `odoo.tools.misc.verify_hash_signed()` This function takes as arguments, a sudo environnement, a scope as a string (must be the same as the encoding scope), and a token generated by hash_sign()
Enhancements to existing features
This update clarifies French accounting reports by splitting account 649 into two new accounts (6491 and 6492). This change accurately separates social security charges from salaries, aligning with French tax regulations. The original account remains for legacy systems but is marked as deprecated.
Original PR description
Splitting account 649 into two new accounts (6491 and 6492) is necessary to handle the Profit and Loss report properly. This ensures we can accurately separate social security charges from salaries in the report. Reference: ANC PCG 2026, page 445, note (h) https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf task-6053784
Resolved issues and error corrections
This update reduces log clutter when QWeb templates fail to render, making it easier for support teams to diagnose issues. The change intelligently truncates template logs while retaining full source for unidentified errors, improving system performance and support efficiency.
Original PR description
This is mainly a backport of an IMP done at https://github.com/odoo/odoo/pull/252455 Given it's potential to reduce server bloat and increase of QOL for sys admins and support agents, backporting (a…
This is mainly a backport of an IMP done at https://github.com/odoo/odoo/pull/252455 Given it's potential to reduce server bloat and increase of QOL for sys admins and support agents, backporting (a sligthly modified version) seemed adequate. Summary: When a QWeb template fails to render, the current logic logs the entire template source and raises a generic UserError. This leads to significant log bloat and makes it difficult for developers and support staff to identify the specific failing template or the root cause of the error. This commit improves the error handling in `mail.render.mixin` and `mail.template` by: - mail.render.mixin: Added logic to identify the failing template's name and ID if it belongs to a `mail.template` or `mail.compose.message` (mass mailing). - Log Truncation: Implemented truncation for identified templates, showing only a snippet (first and last 500 chars) in logs and UserErrors to prevent log/UI bloat while keeping full source logging as a fallback for unidentified templates. OPW-5980295 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update clarifies French Profit and Loss reports by splitting account 649 into two new accounts (6491 and 6492). This change ensures accurate reporting of social security charges and salaries, aligning with French accounting standards (ANC PCG 2026). The original account remains for legacy systems.
Original PR description
Splitting account 649 into two new accounts (6491 and 6492) is necessary to handle the Profit and Loss report properly. This ensures we can accurately separate social security charges from salaries in the report. Reference: ANC PCG 2026, page 445, note (h) https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf task-6053784
This update fixes an issue where accrual calculations weren't working correctly for allocation modes other than 'By Employee'. The change ensures that allocation durations are automatically calculated accurately, regardless of the chosen allocation mode, improving the reliability of holiday accruals. This resolves a previous bug impacting how employees accrue time off.
Original PR description
### Steps to reproduce: - Create an accrual plan of one level to give 20 days at the start of the year - Create an allocation with different mode than 'By Employee' - Set the accrual plan for the…
### Steps to reproduce: - Create an accrual plan of one level to give 20 days at the start of the year - Create an allocation with different mode than 'By Employee' - Set the accrual plan for the allocation and date from 1st Jan - Notice the Allocation number of days doesn't get automatically calculated ### Cause: This is happening because when trying to process the accrual plan we won't have any records in the field employee_id https://github.com/odoo/odoo/blob/bcdd12d13d73915e565fd2c8478b936a16efb9f4/addons/hr_holidays/models/hr_leave_allocation.py#L892-L893 And since employee_id is computed field when computing it we don't handle the case of any other mode other than 'By Employee'. https://github.com/odoo/odoo/blob/bcdd12d13d73915e565fd2c8478b936a16efb9f4/addons/hr_holidays/models/hr_leave_allocation.py#L259-L270 ### Fix: If we have different mode in the allocation we fetch the employees in this mode (Department, Company, Employee Tag) and set them as the allocation employee_ids so when computing the employee_id we will have a record in the field and it won't be null P.S. In the forward port we will have to introduce another fix for the multi allocation wizard opw-5888023
This update fixes an issue where self-billed invoices received from Peppol companies were incorrectly assigned to the wrong company within a multi-company Odoo database. The change ensures invoices are routed to the correct company based on the current database setup, improving invoice processing accuracy and reducing potential errors. This resolves a previous bug impacting financial reporting.
Original PR description
Currently, if a database has multiple companies registered on Peppol, receiving a self-billed invoice may assign it to the wrong company. The system was searching the journal using a domain that included all companies (in self), instead of filtering by the correct current company. Steps to reproduce: - Create a database with 2 companies, both on Peppol - Receive a self-billed invoice from a random other company on Peppol - The received invoice will potentially be assigned to the wrong company opw-6045669