Monday, September 28, 2026
4 changes · 17.0
Enhancements to existing features
Swiss payroll users can now include selected salary rule totals in section 15 remarks on salary certificates, shown in the employee's language with CHF amounts. This improves flexibility for reporting certificate-specific compensation details without requiring stored database changes for new sections.
Original PR description
Salary rules can be set on section 15 of the salary certificate: the total of each of them over the certificate period is added to the remarks, after the additional text of the profile, as "<rule name in the employee language>: <amount> CHF". The sections become a dynamic selection, whose values are not stored in the database, so that one can be added in stable.
Resolved issues and error corrections
This fixes electronic invoice handling so deferred revenue or expense dates are correctly included when exporting UBL invoices and restored when importing vendor bills. Businesses using deferred accounts will have more accurate invoice period information in exchanged XML documents, reducing manual corrections and accounting mismatches.
Original PR description
Revert to the original behavior for UBL export/import dates with deferred accounts. When creating an invoice with a deferred account whose move line contains deferred_start_date and deferred_end_date, add <cac:InvoicePeriod> at the line level in the UBL. When importing a vendor bill, fill deferred_start_date and deferred_end_date if they exist in the XML. Reverting this commit f91c8988ec07bb35f8317cda8d2cf333ff092b0c task-6544976
This fix prevents the website builder from getting stuck when editing sticky headers in newer Chrome versions. It avoids repeated visual recalculations that could cause automated website tours or editing actions to time out, improving reliability for users managing website headers.
Original PR description
Steps to reproduce: 1. Enable a website header with a sticky header. 2. In the website builder, select that header to open its options. In nutshell, `SnippetEditor.cover()` momentarily toggles…
Steps to reproduce: 1. Enable a website header with a sticky header. 2. In the website builder, select that header to open its options. In nutshell, `SnippetEditor.cover()` momentarily toggles `.o_transform_removal` (`transform: none !important`) on the selected element to read its "clean" transform for the overlay. On an element with a CSS `transition: transform` rule, this starts and then immediately interrupts a transition on `transform`. An interrupted transition fires `transitioncancel`, not `transitionend`, but the surrounding code (`_animationsCount` in the same file) only listens for `transitionend`/`animationend`, falling back to a 500ms timer otherwise. Recent Chrome versions (153+, following the "EventTimingMatchingHTML" timing change) correctly dispatch `transitioncancel` for this case, so the fast path is never taken and the 500ms fallback always fires, calling `cover()` again - which retoggles `.o_transform_removal` and restarts the same interrupted transition, forever. This produced a continuous DOM mutation loop that starved the tour engine's debounced trigger check, making website tour steps (e.g. changing a header's visibility option) time out on affected Chrome versions. This commit suppresses transitions on the target for the duration of the toggle (reusing the existing `o_we_force_no_transition` class), and splits the two-class removal into two steps with a forced style flush in between - removing both at once would still let the browser treat the restored `transform` as eligible for the transition being simultaneously re-enabled in the same update. runbot-947139 Reference: - https://chromium.googlesource.com/chromium/src/+/89cc7bb57534eef1f18dce88dd66bf0552bbe708
This fix ensures employee information stays matched to the correct person when exporting large sets of HR-related records. It prevents previously cached employee data from being mixed up across export batches, improving data accuracy for HR reports and exports.
Original PR description
Currently, `_copy_cache_from` is given matching private and public employee recordsets. Its goal is to take the public cache and copy the public record's value to the private cache using update_raw.…
Currently, `_copy_cache_from` is given matching private and public employee recordsets. Its goal is to take the public cache and copy the public record's value to the private cache using update_raw.
https://github.com/odoo/odoo/blob/4b94f02c0a60ec83a4c21e0c6bf31aa11c3f3d20/addons/hr/models/hr_employee.py#L256-L264
`update_raw` zips the recordset and values. This means the two lists need to be aligned; otherwise, `update_raw` will overwrite a private record's value with the value of a non-associated public record.
https://github.com/odoo/odoo/blob/4b94f02c0a60ec83a4c21e0c6bf31aa11c3f3d20/odoo/api.py#L1080-L1101
**Steps to reproduce:**
1. Have a list of records with a related employee field
Example: Departments each with a manager (employee)
2. Have the record size be over the export batch size (1000)
3. Ensure some managers from the first batch are included in the second
4. Export records
Issue:
After the first batch, the employee data is cached. When the second
batch is run, some employees are cached (seen managers), but some
are not. This causes the misalignment in _copy_cache_from.
**Fix:**
Fetch the values while keeping track of which private record each one is associated with.
opw-6289990