Wednesday, August 12, 2026
5 changes · 17.0
Resolved issues and error corrections
This fix prevents Swiss payroll settings from automatically assigning a Swiss contract type to employees outside Switzerland. It avoids incorrect contract labels and helps keep automated HR/payroll checks reliable across localized setups.
Original PR description
[FIX] l10n_ch: fix default contract type This task is runbot error fix that occured from 19.0 to 19.2 Bug reproduction: 1 - Go to version 19.0, install l10n_ch_hr_payroll_account 2 - Execute…
[FIX] l10n_ch: fix default contract type
This task is runbot error fix that occured from 19.0 to 19.2
Bug reproduction:
1 - Go to version 19.0, install l10n_ch_hr_payroll_account 2 - Execute test_version_timeline_auto_save_tour tour test 3 - It fails in .o_arrow_button_wrapper[data-tooltip^='Contract:'] step
Bug cause:
1 - When l10n_ch_hr_payroll_account is installed:
1.1 - contract type becomes "Permanent contract with monthly salary"
1.2 - the employee is not swiss but it has this CH contract type
2 - data-tooltip starts with Permanent contract instead of contract
2.1 - Tour fails
3 - contract_type_id is overwritten in swiss modules
3.1 - Default is assigned without looking to the country of self.env
Bug solution:
1 - If the country is not swiss, the default is assigned as False
1.1 instead of assigning swiss contract type to the non-swiss emp.
Note: I started to fix it from 17.0 BUT:
. in above versions field overwrite might be in different CH modules . fix all in the above versions
task-6392040
runbot error: https://runbot.odoo.com/odoo/runbot.build.error/941358### Issue: When a company is not connected to the French Electronic Invoicing PDP proxy, the generated XML is missing required notes: `PMT`, `PMD` and `AAB` These notes are required by Factur-X rule `BR-FR-05/BT-22` and their absence causes validation errors on the FNFE validator ### Cause: `_l10n_fr_pdp_get_default_notes` only added the notes when the company was using a PDP proxy type Non-PDP users sending invoices via other means were excluded, which contradicts the French e-invoicing
Original PR description
### Issue: When a company is not connected to the French Electronic Invoicing PDP proxy, the generated XML is missing required notes: `PMT`, `PMD` and `AAB` These notes are required by Factur-X rule `BR-FR-05/BT-22` and their absence causes validation errors on the FNFE validator ### Cause: `_l10n_fr_pdp_get_default_notes` only added the notes when the company was using a PDP proxy type Non-PDP users sending invoices via other means were excluded, which contradicts the French e-invoicing requirements ### Steps to reproduce: - Install `l10n_fr_pdp` and switch to the FR company - In Settings, ensure French Electronic Invoicing is not activated - Create and confirm an invoice (any line with tax) - Send the invoice and open the generated XML Before the fix, the `PMT`, `PMD` and `AAB` notes are missing Activating French Electronic Invoicing would include them opw-6392262 opw-6377507
When this happens, simply delegate to the origin record. opw-6425802 For the record, this is a partial backport of https://github.com/odoo/odoo/pull/195203.
Original PR description
When this happens, simply delegate to the origin record. opw-6425802 For the record, this is a partial backport of https://github.com/odoo/odoo/pull/195203.
Automatically update the ruff config to the latest version generated on runbot
Original PR description
Automatically update the ruff config to the latest version generated on runbot
## Issue When filtering projects using the "Timesheets >100%" filter, some projects with negative remaining hours (and with their `is_project_overtime` field set to True) won't be displayed, even though their expected hours are completed. This happens with projects which have tasks set to the "Done" or "Cancelled" state. The timesheets entries in those tasks are not taken into account when searching using the "Timesheets >100%" filter. ## Steps to reproduce 1. Install *Task Logs* (`hr_ti
Original PR description
## Issue When filtering projects using the "Timesheets >100%" filter, some projects with negative remaining hours (and with their `is_project_overtime` field set to True) won't be displayed, even…
## Issue
When filtering projects using the "Timesheets >100%" filter, some projects with negative remaining hours (and with their `is_project_overtime` field set to True) won't be displayed, even though their expected hours are completed.
This happens with projects which have tasks set to the "Done" or "Cancelled" state. The timesheets entries in those tasks are not taken into account when searching using the "Timesheets >100%" filter.
## Steps to reproduce
1. Install *Task Logs* (`hr_timesheet`)
2. Create a Project P (with Timehseets enabled)
3. Set the allocated hours of the project to 3:00 (3 hours)
4. Create two tasks:
- T1: State "In progress", and one timesheet entry of 2:00 (2 hours)
- T2: State "Done", and one timesheet entry of 2:00 (2 hours)
5. Back to the project view, set the filter to "Timesheets >100%"
6. **Project P is not shown, even though the total time spent on the project is 4 hours, completing the allocated hours set on the project.**
## Cause
The `_search_is_project_overtime` method filters out the tasks in "closed" states (Done/Cancelled) when computing the amount of time spent on the project.
https://github.com/odoo/odoo/blob/126b5bdd1e85771549198976f8570cd2ff167608/addons/hr_timesheet/models/project_project.py#L103-L114
This does not match with the behavior of the `_compute_is_project_overtime`, which does not take into account the state of the tasks to determine the value of the field:
https://github.com/odoo/odoo/blob/126b5bdd1e85771549198976f8570cd2ff167608/addons/hr_timesheet/models/project_project.py#L85-L94
This leads to a confusing behavior, where a project can have its `is_project_overtime` field set to True, but will still not be shown when using the "Timsheets >100%", even though that filter is defined as `[("is_project_overtime", "=", True)]`.
The compute method was updated by https://github.com/odoo/odoo/commit/d4252825f52a3172420dcda0ea394e42da9f8853, but the related search method was left unchanged, leading to this slight incoherence between the two methods.
opw-6422173