Tuesday, August 11, 2026
14 changes · master
Resolved issues and error corrections
Overtime time-off entries in Belgian payroll will no longer be incorrectly marked as sickness relapses after a recent sick leave. The relapse check now only considers actual sickness leave types, improving payroll accuracy and reducing manual corrections.
Original PR description
Before this commit, "_compute_can_relapse" scoped its computation to any Belgian, HR-validated leave, regardless of its work entry type. As a result, creating an overtime time-off entry shortly after a validated sick leave would incorrectly trigger the "Sickness relapse" field on the overtime entry, since it fell within the legal relapse window of the previous sick leave. Add a check on `work_entry_type_id.code` to the initial filter so only actual sickness leaves (LEAVE110, LEAVE214, LEAVE280) are considered for the relapse computation. Task: 6415930
This update corrects demo payroll data so Belgian employee records are linked to the right company instead of defaulting to a US company. It also ensures required languages and payroll warning checks are handled correctly, reducing access errors during demo payslip generation.
Original PR description
Task #6453043
Fixed an issue in Belgian payroll where voluntary overtime could fail when an employee had overtime across multiple work days. This helps payroll processing complete reliably and reduces manual corrections for affected payslips.
Original PR description
Forward-Port-Of: odoo/enterprise#127407 Forward-Port-Of: odoo/enterprise#127378
This fix prevents Philippine payroll validation from failing when older or test dates do not have a matching tax office rule parameter. Regular payroll use remains unchanged, while unusual historical data or automated tests can proceed without unnecessary errors.
Original PR description
While in regular usage the current solution works; the constrains may break if during tests and other flows where the date could be far in the past. To avoid such issues; we will not raise if the rule param is not found and instead simply return early. Runbot error 945678
Belgian payroll declarations without XML no longer trigger an online schema download during validation. This prevents database setup from failing on systems without internet access while keeping normal validation for declarations that do include XML.
Original PR description
Before this commit, the validation state compute downloaded the XSD from socialsecurity.be even for a declaration with no XML to validate, so the database initialisation crashed on a host without internet. The download came with odoo/enterprise#104908 and only shows up once the test_l10n_be_hr_payroll_account demo data is installed, since that demo creates a DMFA without any XML. After this commit, the schema is fetched only when there is an XML, and empty declarations are just marked as normal. task-6460394
The Belgian payroll configuration has been adjusted so a related action appears in the payroll configuration area instead of the general settings area. This helps payroll users find the relevant option in the expected place and reduces confusion during setup.
Original PR description
Task: 6461789
This fix ensures Indian payroll calculations are only applied to employees using the Indian localization. It prevents irrelevant Indian payroll fields from appearing in change logs for employees managed under other country rules, such as Belgium.
Original PR description
[FIX] l10n_in: fix some l10n_in fields computed for other localizations
Bug reproduction:
1 - in localhost install below modules:
→ l10n_in_hr_payroll,l10n_be_hr_payroll,l10n_be_hr_contract_salary
2 - Select BE, IN localizations, but as active one select Belgium. 3 - Go to employee, Laura.
4 - Change her wage to 8000
5 - In the chatter, you will see some indian fields are tracked.
→ Shouldn't be, Laura is Belgium, only BE fields should be tracked
Bug cause:
1 - In the hr.version of l10n_in_hr_payroll:
→ there isn't enough caution in compute methods for other l18ns.
→ e.g., _l10n_in_get_montly_wage returns self.wage
→ self.wage is 8000 and that function leads to positive computations
Bug solution:
1 - Non-indian versions are carefully handled in compute methods
task-6411960
Forward-Port-Of: odoo/enterprise#125350System administrators can once again delete any equity transaction, even when they are not listed as the seller or subscriber. This restores the intended administrative control and prevents support issues caused by blocked cleanup or correction tasks.
Original PR description
Before this PR https://github.com/odoo/enterprise/pull/120158 system admin had the access to delete any transaction (which was intended). The PR however made admins no longer able to delete a transaction that they don't belong to as seller or subscriber. This PR fixes this issue by allowing admins to delete any transaction. opw-6413350 Forward-Port-Of: odoo/enterprise#126672
Bank reconciliation now safely handles imported statement lines whose payment reference contains only spaces. This prevents an unexpected error when setting accounts and keeps reconciliation workflows running smoothly even with imperfect imported data.
Original PR description
When reconciling bank statements with an account, the system will look for past statement lines already reconciled with that account and create a reconciliation model based on common substring in…
When reconciling bank statements with an account, the system will look for past statement lines already reconciled with that account and create a reconciliation model based on common substring in payment_ref. If this payment refs contains only spaces (eg. ' '), it will trigger an index out of range traceback. This is explained by the fact that spaces are striped then '' is considered as False in some filtering leaving the list empty. From the UI, putting ' ' is not supposed to be possible because spaces are striped before write but there is many ways to import statement lines which may lead to this hence the decision of handling this scenario to make the code more robust. Steps to reproduce: 1/ Create two statement lines with payment_ref as ' ' (you can force it using a write) 2/ Click "Set account" on first one and pick 100000 Issued Capital 3/ Do the same for the second statement line => Traceback In this commit, we do not check for common substring if there is less than two labels. opw-6379977 Forward-Port-Of: odoo/enterprise#126729 Forward-Port-Of: odoo/enterprise#125779
This fix makes an automated product merge test consistently choose the intended main product before merging. It prevents random test failures caused by unreliable creation-date ordering, improving build stability without changing customer-facing behavior.
Original PR description
Version: - saas-19.4 Steps to reproduce: - Run the test_merge_success_single_variant test case multiple times with different products created each time. Issue: The master record is selected based on its creation date, but that ordering is not always reliable. As a result, the wrong product may be chosen as the master,causing the incorrect product to be archived and the runbot test to fail. Fix: Before merging, we now manually set product 1 as the master. This makes the test predictable and stops the failures. Build error - 941476 Forward-Port-Of: odoo/enterprise#125180
This fix clears cached routing information so barcode-related test overrides are correctly applied when larger test suites run. It helps prevent false test failures in inventory and picking barcode workflows, improving release stability without changing day-to-day user behavior.
Original PR description
test_barcode_create_serials_in_batch_with_single_scan keeps failing on master and 19.4 as call_count !=2, but instead = 0 This does not happen when running only the tests in stock_barcode but instead when you run a larger suite of tests such as the following: https://runbot.odoo.com/runbot/build/119533820 Once a route is hit it is stored in the cache, causing the later override to be missed. [Runbot-238760](https://runbot.odoo.com/odoo/error/238760) Forward-Port-Of: odoo/enterprise#126122
The accounting reconciliation process now uses an existing optimized database lookup more reliably. This should improve performance when matching unreconciled accounting entries, especially for larger accounting datasets, without changing user-facing workflows.
Original PR description
We have a very efficient index for searching unreconciled lines on known accounts. Let's use it.
```python
_unreconciled_index = models.Index("(account_id, partner_id) WHERE reconciled IS NOT TRUE")
```
Before this change, the query planner didn't recognize the index because of its definition being slightly different wrt the null values.
Forward-Port-Of: odoo/enterprise#127093This fix prevents a restaurant appointment test from ending with unsaved changes left open. It makes automated checks more reliable and reduces random test failures without changing customer-facing behavior.
Original PR description
The `test_appointment_kanban_view` tour test was randomly failing with the following error: `AssertionError: Tour finished with a dirty form view being open.` This occurred because the tour ended right after clearing a date field on a form, leaving the form in a "dirty" (unsaved changes) state. This commit fixes the issue by adding a final step to the tour that clicks the cancel/discard button. Forward-Port-Of: odoo/enterprise#109633
A bug prevented the helpful tip in the timesheet leaderboard from being shown to users. This fix restores the tip so employees can see the intended guidance while using the leaderboard.
Original PR description
The tip inside the timesheet leaderboard was never visible due to incorrect function arguments assignment. This commit fixes the issue. task-6448478 Forward-Port-Of: odoo/enterprise#126792