Odoo Changelog — 2026-07-09

Thursday, July 9, 2026

5 changes · 18.0

Bug Fixes(5)

Resolved issues and error corrections

[FIX] l10n_ca_payment_cpa005: populate Item Trace Number with payment id

Enterprise18.0l10n_ca_payment_cpa005Medium

Canadian EFT payment export files now use each payment's identifier as the Item Trace Number instead of filling it with zeros. This helps ensure exported payment files meet CPA-005 requirements and avoids bank rejections for invalid trace numbers.

Original PR description

According to CPA-005 standards on the Item Trace Number:
"The data elements (b), (c) and (d) each must be greater than zero or the TRANSACTION WILL BE REJECTED" (page 36).
https://www.payments.ca/sites/default/files/standard005eng.pdf

Steps to reproduce:
1. Install the module l10n_ca_payment_cpa005
2. Go into "CA Company"
3. In the configuration for "CA Company", add something to the fields "Short Name used in Canadian EFT" and "Company ID" i.e. "CCC"
4. Set all the fields in the "Canadian EFT/CPA Configuration" section of the bank journal
5. Set the bank record on the bank journal. Set the field "Financial Institution ID Number" field of the "Account Number" record of the bank journal to any numerical sequence
6. Create a bank account on "Azure Interior" and make sure to check the field to trust the bank account that you created (otherwise there will be an error)
7. Create two payments with the vendor of "Azure Interior" using the payment method of "Canadian EFT"
8. Create a batch payment for both payments created
9. Validate the batch payment and the export file should show up in the chatter
10. Note that in the export file, the Item Trace Number for each payment is set to be all zeros, whereas it should be a nonzero identification sequence

Solution:
Set the Item Trace Number to be the payment's id

opw-6323432

#canadian-eft#payments#compliance

[FIX] l10n_lu_hr_payroll: add missing indices for 2025 and 2026

PR #122147

Enterprise18.0l10n_lu_hr_payrolll10n_lu_hr_payroll_accountMedium

Luxembourg payroll now uses the correct official salary index values for contracts starting from May 2025 and June 2026. This prevents incorrect contract signature index values and helps ensure related payroll calculations remain aligned with legal indexation updates.

Original PR description

## Issue When creating or browsing an existing contract in a Luxembourgish company, the current index shown is the one from September 2023 (which was up-to-date until Mai 2025). If the contract is…

## Issue
When creating or browsing an existing contract in a Luxembourgish company, the current index shown is the one from September 2023 (which was up-to-date until Mai 2025). If the contract is created after Mai 2025, the "Index on Contract Signature" field is also wrong.

## Steps to reproduce
1. Install *Luxembourg - Payroll* (`l10n_lu_hr_payroll`)
2. Using a Luxembourgish company, create a new contract for an employee
    - *Contract Start Date*: Any date after 05/01/2025 (Mai 1st 2025)
3. __The *Index on Contract Signature* shows `944.43`, which is the index from September 2023. It does not match with the most recent indices.__

## Cause
The two most recent indices are missing from the [`rule_parameter_lu_index`](https://github.com/odoo/enterprise/blob/885edbc270a86ab76e0a6eff4acb5767c0fe29d1/l10n_lu_hr_payroll/data/rule_parameters/general_rules_data.xml#L4-L58). These indices are:
- `968.04` from 2025-05-01 (Mai 1st 2025)
- `992.24` from 2026-06-01 (June 1st 2026)

These values were taken from [here](https://salary.lu/en/tools/social-parameters/indexation-of-salaries) and double-checked [here](https://lustat.statec.lu/?lc=en&tm=DF_C1201&pg=0&snb=1).

## Tests modification
Updating the latest index had an impact on the tests from the `l10n_lu_hr_payroll_account` (testing the salary rules). In fact, the current index (`l10n_lu_current_index`) is [used to compute the indexed wage](https://github.com/odoo/enterprise/blob/7892d035ddb968d67a3e8da0daf91292bd8fb499/l10n_lu_hr_payroll/models/hr_contract.py#L24-L33) (`l10n_lu_indexed_wage`), which is then used to compute most lines in the payslip (e.g., the `WAGE_SUPPLEMENT_70`).

https://github.com/odoo/enterprise/blob/7892d035ddb968d67a3e8da0daf91292bd8fb499/l10n_lu_hr_payroll/data/salary_rules/hr_salary_rule_data.xml#L70-L74

Since the latest index is not the same as when those tests were written, the values are not correct anymore. To prevent this, time was frozen to 01/01/2024 to use the expected index (944.43, from September 2023).

opw-6330790

[FIX] project: update follower preferences when moving tasks between projects.

PR #275067

Core18.0projectMedium

When a task is moved to another project, follower notification preferences are now updated to match the new project’s settings. This prevents people from missing important task updates after a task is reassigned between projects.

Original PR description

Steps to reproduce:
-
 1. Create projects A and B.
 2. Add a user as a follower of project B and select specific notification subtypes (e.g., 'Stage Changed').
 3. Create a task in project A and add the same user as a follower(defaulting to 'Discussions').
 4. Move the task from project A to project B.

Issue:
-
The follower's subscription preferences on the task do not reflect their project-level settings after the move. In the example above, the user remains subscribed only to 'Discussions' and misses 'Stage Changed' updates.

Cause:
-
The default auto-subscription logic skips existing followers. When moving a task, this prevents the system from adding the new project's notification preferences to users who were already following the task.

Fix:
-
Override `_message_auto_subscribe` in project.task to the `update` policy when the `project_id` is changed.

task-5877507

Forward-Port-Of: odoo/odoo#248224

#followers#notifications#tasks#projects

[FIX] sale_project: display only project related SOLs in the dashboard

PR #269816

Core18.0sale_projectMedium

This change ensures each project dashboard only shows the sales order lines that belong to that specific project. It prevents sales and profitability figures from being inflated by lines from other projects, so the dashboard data is more accurate.

Original PR description

Steps to reproduce:
-------------------------
1. Install sale_project and accounting
2. Create two billable projects with specific analytic accounts
3. Create two service products with "prepaid/fixed price", set
  "create on order" to "Task" and assign each product to its
  respective project in the project column
4. Create a SO with these products and confirm it
5. Click on the projects stat button (it shows two projects)

Observation:
------------------
Both project dashboards display both SOLs even though each SOL belongs to a different project's analytic account, leading to incorrect SOL count and profitability calculation.

Cause:
---------
https://github.com/odoo/odoo/blob/281658e86971687656f3235ac1ff8afcb52f2908/addons/sale_project/models/project_project.py#L420-L427 The domain matched SOLs via `order_id,` which pulled all SOLs from a matched order regardless of which project they belonged to.

Solution:
-----------
Add an additional filter on analytic_distribution to ensure SOLs with no `project_id` are only included when their analytic account matches the project's analytic account, preventing cross-project SOL leakage.

opw-6205750


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

[FIX] base: use 24-hour format for read_group hour labels

PR #275147

Core18.0baseMedium

Grouped date-and-time views now show hour labels in 24-hour format instead of an ambiguous 12-hour format. This means afternoon and evening records are displayed clearly, avoiding confusion between AM and PM times.

Original PR description

Description of the issue/feature this PR addresses:
When grouping datetime fields by hour, `read_group` formats the group display label using `hh:00 dd MMM`.

In Babel/LDML formatting, `hh` represents a 12-hour clock. Since the format does not include an AM/PM marker, afternoon/evening hours are displayed ambiguously in grouped views.

Current behavior before PR:
A datetime value in the afternoon is grouped under a 12-hour label without AM/PM.

For example, records around `13:50` are displayed under:

    01:00 20 Mar

Similarly, a datetime value around `16:20` may be grouped under:

    04:00 26 Mar

This is ambiguous because the group header does not indicate whether the hour is AM or PM.

Example screenshot showing records around 13:xx grouped under `01:00`:
<img width="310" height="240" alt="image" src="https://github.com/user-attachments/assets/8768f2e8-9aaa-436b-af9f-40055a6032e9" />


Desired behavior after PR is merged:
Hour-based datetime group labels should be unambiguous.

The hour grouping format now uses `HH:00 dd MMM`, so grouped datetime labels render using a 24-hour clock.

For example:

    13:00 20 Mar
    16:00 26 Mar

This fixes the datetime hour grouping label shown in grouped list views and other `read_group` consumers.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#274724

Issue: The Item Trace Number according to CPA-005 standard should be a nonzero sequence that serves as unique reference ID for payments. Currently, Odoo sets the Item Trace Number of all payments as a zero-filled sequence According to CPA-005 standards on the Item Trace Number: "The data elements (b), (c) and (d) each must be greater than zero or the TRANSACTION WILL BE REJECTED" (page 36). https://www.payments.ca/sites/default/files/standard005eng.pdf Steps to reproduce: 1. Install the module l10n_ca_payment_cpa005 2. Go into "CA Company" 3. In the configuration for "CA Company", add something to the fields "Short Name used in Canadian EFT" and "Company ID" i.e. "CCC" 4. Set all the fields in the "Canadian EFT/CPA Configuration" section of the bank journal 5. Set the bank record on the bank journal. Set the field "Financial Institution ID Number" field of the "Account Number" record of the bank journal to any numerical sequence 6. Create a bank account on "Azure Interior" and make sure to check the field to trust the bank account that you created (otherwise there will be an error) 7. Create two payments with the vendor of "Azure Interior" using the payment method of "Canadian EFT" 8. Create a batch payment for both payments created 9. Validate the batch payment and the export file should show up in the chatter 10. Note that in the export file, the Item Trace Number for each payment is set to be all zeros, whereas it should be a nonzero identification sequence Solution: Set the Item Trace Number to be the payment's id opw-6323432

## Issue When creating or browsing an existing contract in a Luxembourgish company, the current index shown is the one from September 2023 (which was up-to-date until Mai 2025). If the contract is created after Mai 2025, the "Index on Contract Signature" field is also wrong. ## Steps to reproduce 1. Install *Luxembourg - Payroll* (`l10n_lu_hr_payroll`) 2. Using a Luxembourgish company, create a new contract for an employee - *Contract Start Date*: Any date after 05/01/2025 (Mai 1st 2025) 3. __The *Index on Contract Signature* shows `944.43`, which is the index from September 2023. It does not match with the most recent indices.__ ## Cause The two most recent indices are missing from the [`rule_parameter_lu_index`](https://github.com/odoo/enterprise/blob/885edbc270a86ab76e0a6eff4acb5767c0fe29d1/l10n_lu_hr_payroll/data/rule_parameters/general_rules_data.xml#L4-L58). These indices are: - `968.04` from 2025-05-01 (Mai 1st 2025) - `992.24` from 2026-06-01 (June 1st 2026) These values were taken from [here](https://salary.lu/en/tools/social-parameters/indexation-of-salaries) and double-checked [here](https://lustat.statec.lu/?lc=en&tm=DF_C1201&pg=0&snb=1). ## Tests modification Updating the latest index had an impact on the tests from the `l10n_lu_hr_payroll_account` (testing the salary rules). In fact, the current index (`l10n_lu_current_index`) is [used to compute the indexed wage](https://github.com/odoo/enterprise/blob/7892d035ddb968d67a3e8da0daf91292bd8fb499/l10n_lu_hr_payroll/models/hr_contract.py#L24-L33) (`l10n_lu_indexed_wage`), which is then used to compute most lines in the payslip (e.g., the `WAGE_SUPPLEMENT_70`). https://github.com/odoo/enterprise/blob/7892d035ddb968d67a3e8da0daf91292bd8fb499/l10n_lu_hr_payroll/data/salary_rules/hr_salary_rule_data.xml#L70-L74 Since the latest index is not the same as when those tests were written, the values are not correct anymore. To prevent this, time was frozen to 01/01/2024 to use the expected index (944.43, from September 2023). opw-6330790

Steps to reproduce: - 1. Create projects A and B. 2. Add a user as a follower of project B and select specific notification subtypes (e.g., 'Stage Changed'). 3. Create a task in project A and add the same user as a follower(defaulting to 'Discussions'). 4. Move the task from project A to project B. Issue: - The follower's subscription preferences on the task do not reflect their project-level settings after the move. In the example above, the user remains subscribed only to 'Discussions' and misses 'Stage Changed' updates. Cause: - The default auto-subscription logic skips existing followers. When moving a task, this prevents the system from adding the new project's notification preferences to users who were already following the task. Fix: - Override `_message_auto_subscribe` in project.task to the `update` policy when the `project_id` is changed. task-5877507 Forward-Port-Of: odoo/odoo#248224

Steps to reproduce: ------------------------- 1. Install sale_project and accounting 2. Create two billable projects with specific analytic accounts 3. Create two service products with "prepaid/fixed price", set "create on order" to "Task" and assign each product to its respective project in the project column 4. Create a SO with these products and confirm it 5. Click on the projects stat button (it shows two projects) Observation: ------------------ Both project dashboards display both SOLs even though each SOL belongs to a different project's analytic account, leading to incorrect SOL count and profitability calculation. Cause: --------- https://github.com/odoo/odoo/blob/281658e86971687656f3235ac1ff8afcb52f2908/addons/sale_project/models/project_project.py#L420-L427 The domain matched SOLs via `order_id,` which pulled all SOLs from a matched order regardless of which project they belonged to. Solution: ----------- Add an additional filter on analytic_distribution to ensure SOLs with no `project_id` are only included when their analytic account matches the project's analytic account, preventing cross-project SOL leakage. opw-6205750 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Description of the issue/feature this PR addresses: When grouping datetime fields by hour, `read_group` formats the group display label using `hh:00 dd MMM`. In Babel/LDML formatting, `hh` represents a 12-hour clock. Since the format does not include an AM/PM marker, afternoon/evening hours are displayed ambiguously in grouped views. Current behavior before PR: A datetime value in the afternoon is grouped under a 12-hour label without AM/PM. For example, records around `13:50` are displayed under: 01:00 20 Mar Similarly, a datetime value around `16:20` may be grouped under: 04:00 26 Mar This is ambiguous because the group header does not indicate whether the hour is AM or PM. Example screenshot showing records around 13:xx grouped under `01:00`: <img width="310" height="240" alt="image" src="https://github.com/user-attachments/assets/8768f2e8-9aaa-436b-af9f-40055a6032e9" /> Desired behavior after PR is merged: Hour-based datetime group labels should be unambiguous. The hour grouping format now uses `HH:00 dd MMM`, so grouped datetime labels render using a 24-hour clock. For example: 13:00 20 Mar 16:00 26 Mar This fixes the datetime hour grouping label shown in grouped list views and other `read_group` consumers. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274724