Odoo Changelog — 2026-04-21

Tuesday, April 21, 2026

211 changes

Branch: saas-19.2

3 changes

Bug Fixes(3)

Resolved issues and error corrections

[FIX] orm: ordered query ids with where_clause

PR #260443

Coresaas-19.2baseorm

This fix ensures that queries with ordered result IDs still look like they have restrictions when other parts of the system check for them. It preserves existing behavior and prevents related code from misreading these queries as unrestricted.

Original PR description

Some code uses `if query.where_clause` to detect if there are any restrictions on the table. When setting ordered result ids, we simply used a JOIN, so there is no detected where clause. To keep existing code working, we add a dummy 1=1 to the where clause.



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

Forward-Port-Of: odoo/odoo#260306

#bugfix#query#compatibility

[FIX] Spreadsheet: neutralize odoo links on freeze

PR #260471

Coresaas-19.2spreadsheetMEDIUM

This change preserves the visual link styling in frozen and shared spreadsheets while still preventing those links from being clicked on public pages. It matters because dashboards keep their intended layout and appearance without exposing usable internal links.

Original PR description

Since https://github.com/odoo/odoo/pull/166843, we remove the odoo links entirely from the spreadsheet on `freeze and share`. While it is true that the link is not usable from a public page (and that we'd somehow leak internal views information in the links), cells with links benefit from a specific style that is not hardcoded on the cell but rather computed based on their content.
By removing the links from teh cells altogether, the greenish link style is lost on those cells and we actually rely on that style for our dashboards layout.

To preserve the intension of https://github.com/odoo/odoo/pull/166843, we introduce a new type of links `neutralized` which allows the cell to be recognized as a link (and benefit from the style) while disabling their behaviour (no click).

Task-6063301

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#260250
Forward-Port-Of: odoo/odoo#256357

#spreadsheet#freeze and share#links#dashboard styling

[FIX] payment_adyen: fix capture issues caused by creating child tx

PR #260491

Coresaas-19.2payment_adyenMEDIUM

This update fixes an issue where Adyen payments could fail when capturing or canceling an authorized payment. It also ensures the related transaction record updates correctly, so payment statuses stay accurate after these operations.

Original PR description

Issue 1:
---
Capturing/voiding transaction is failing with the error:
`The payment provider rejected the request. Original pspReference required for this operation`

Steps to reproduce:
1- Setup Adyen payment provider.
2- Enable `Capture amount manually`.
3- Create a SO and confirm.
4- Generate a payment link and pay.
5- In SO, capture the full amount.

Cause:
---
After https://github.com/odoo/odoo/commit/efc2788dfccd13ee6feb309430ff57e49664ff97, in the payment `_void()`/`_capture()`, a child tx is created.
However the child tx is missing the `provider_reference` required to send the payment provider.


Issue 2:
---
The child tx created for capture/void is always remains in draft state.

Cause:
---
This is reproduced after https://github.com/odoo/odoo/commit/efc2788dfccd13ee6feb309430ff57e49664ff97 which we create a child tx in capture/void. But in `_search_by_reference` which is called by webhook to find the tx, we are returning the source tx. As a result only the state of the source tx is changed.

opw-6120846
opw-6120071

Forward-Port-Of: odoo/odoo#259223

#adyen#payments#capture#void#transaction status

Branch: saas-19.1

5 changes

Bug Fixes(5)

Resolved issues and error corrections

[FIX] account,purchase: prevent error when creating accrual entries

PR #260415

Coresaas-19.1accountpurchaseMEDIUM

This update fixes an error that could appear when users create accrual entries from the Billed Not Received screen after changing the date. It ensures the date is handled correctly so the action completes normally without interrupting accounting work.

Original PR description

**Steps to reproduce:**
- Install the `accountant` and `purchase` modules.
- Create and confirm a Purchase Order (with 1 quantity).
- Create a vendor bill using `auto-complete` from the PO, 
  set the quantity to 1, and `confirm` it.
- Navigate to Accounting > Review > `Billed Not Received`.
- Change the `date` from the top left.
- Select a record and click `Create Accrual Entries`.

**Error:**
`TypeError: '<=' not supported between instances of 'datetime.date' and 'str'`

**Root cause:**
At [1], the `accrual_entry_date` is set in the context as a `string`. 
Later, at [2], this value is retrieved from the context and used 
directly in a comparison with `ivl.date`, which is a `datetime.date`.

**Fix:**
This commit converts `accrual_entry_date` to a `datetime.date` object at [2], 
allowing users to create accrual entries without errors.

[1]:
https://github.com/odoo/enterprise/blob/3ab460a935c6caf013202ec6be1c3708178c8d7d/account_reports/static/src/views/accrual_list_controller.js#L61-L76

[2]:
https://github.com/odoo/odoo/blob/7e17c788babc2715e85456467db9172bb0b8e42d/addons/account/wizard/accrued_orders.py#L166-L188

opw-6110907

Forward-Port-Of: odoo/odoo#259047

#accrual entries#vendor bills#date handling#accounting

[FIX] Spreadsheet: neutralize odoo links on freeze

PR #260425

Coresaas-19.1spreadsheetMEDIUM

This update preserves the visual formatting of spreadsheet cells that contain Odoo links when a dashboard is frozen and shared. The links are made non-clickable for public viewers, while keeping the same link-like appearance needed for layout consistency.

Original PR description

Since https://github.com/odoo/odoo/pull/166843, we remove the odoo links entirely from the spreadsheet on `freeze and share`. While it is true that the link is not usable from a public page (and that we'd somehow leak internal views information in the links), cells with links benefit from a specific style that is not hardcoded on the cell but rather computed based on their content.
By removing the links from teh cells altogether, the greenish link style is lost on those cells and we actually rely on that style for our dashboards layout.

To preserve the intension of https://github.com/odoo/odoo/pull/166843, we introduce a new type of links `neutralized` which allows the cell to be recognized as a link (and benefit from the style) while disabling their behaviour (no click).

Task-6063301

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#260250
Forward-Port-Of: odoo/odoo#256357

#freeze and share#dashboard#link styling#public spreadsheet

[FIX] account_edi_ubl_cii: fix test ensure_installed module

PR #260450

Coresaas-19.1account_edi_ubl_cii

This change fixes a test that could fail during setup because it checked access groups before confirming the related module was installed. It helps keep automated tests stable and prevents unnecessary errors in the electronic invoicing area.

Original PR description

The `get_default_groups` call happens during super.setUpClass(), therefore we have not checked (yet) if the module in which the security group is in is installed, and we end up with an Exception.

task-none

Forward-Port-Of: odoo/odoo#260230

#testing#stability#electronic-invoicing

[FIX] payment_adyen: fix capture issues caused by creating child tx

PR #260454

Coresaas-19.1payment_adyenMEDIUM

This change fixes a problem where manual capture and void actions could fail in Adyen payments, and ensures the related payment records are updated correctly. As a result, businesses can complete payment operations more reliably without transactions getting stuck or rejected.

Original PR description

Issue 1:
---
Capturing/voiding transaction is failing with the error:
`The payment provider rejected the request. Original pspReference required for this operation`

Steps to reproduce:
1- Setup Adyen payment provider.
2- Enable `Capture amount manually`.
3- Create a SO and confirm.
4- Generate a payment link and pay.
5- In SO, capture the full amount.

Cause:
---
After https://github.com/odoo/odoo/commit/efc2788dfccd13ee6feb309430ff57e49664ff97, in the payment `_void()`/`_capture()`, a child tx is created.
However the child tx is missing the `provider_reference` required to send the payment provider.


Issue 2:
---
The child tx created for capture/void is always remains in draft state.

Cause:
---
This is reproduced after https://github.com/odoo/odoo/commit/efc2788dfccd13ee6feb309430ff57e49664ff97 which we create a child tx in capture/void. But in `_search_by_reference` which is called by webhook to find the tx, we are returning the source tx. As a result only the state of the source tx is changed.

opw-6120846
opw-6120071

Forward-Port-Of: odoo/odoo#259223

#adyen#payments#capture#void#transaction state

[FIX] sale_mrp: fix no COGS entry when kit component deleted in delivery

PR #259875

Coresaas-19.1sale_mrpMEDIUM

This change fixes an issue where invoicing a kit could miss the cost-of-goods-sold entry if one of its components had been removed from the delivery. It also improves the calculation so the cost entry reflects only the components actually delivered, which makes accounting more accurate.

Original PR description

Steps to reproduce:
- Create a kit with 3 or more components
- Create a sales order with the kit and confirm it
- Remove at least one of the kit's components from the delivery and validate it
- Create the invoice from the sales order and confirm the invoice
- Check the journal entries included in the invoice form

Current behavior:
- There is no COGS entry

Expected behavior:
- There should be a COGS entry

Context:
In versions <19, you will get a COGS entry that amounts to the total cost of the kit despite deleting a component from the delivery. With our current code in versions 19+, we can actually improve upon this by only counting the remaining components' costs for the COGS entry's amount.

opw-6082565

Forward-Port-Of: odoo/odoo#258982

#accounting#inventory#invoice#kit#cogs

Branch: saas-18.3

1 change

Bug Fixes(1)

Resolved issues and error corrections

[FIX] l10n_pe_reports_lib: prevent error in general ledger export

PR #114521

Enterprisesaas-18.3l10n_pe_reports_libMEDIUM

This fix prevents an error when exporting the General Ledger in a Peru company if draft invoices or other draft entries are included. Users can now complete the export without the report breaking, improving reliability for accounting work.

Original PR description

**Steps to reproduce:**
- Install the `l10n_pe_reports_lib` module and switch to a `PE company`.
- Create a draft invoice.
- Navigate to Reporting > General Ledger.
- Click the gear icon and select `Inventory and Balance`.

**Error:**
AttributeError: 'NoneType' object has no attribute 'replace'

**Root Cause:**
For draft entries, `move_name` is `None`, and calling `.replace()` on it 
causes an error at [1].

**Fix:**
This commit prevents errors and ensures users can export the general ledger 
even when draft entries are included.

[1]:
https://github.com/odoo/enterprise/blob/5babcb5cb951e0e7beebdbef0781a20a7a19c319/l10n_pe_reports_lib/models/account_general_ledger.py#L168

opw-6104117

Forward-Port-Of: odoo/enterprise#113405

#accounting#general-ledger#export#peru#draft-entries

Branch: saas-18.2

1 change

Bug Fixes(1)

Resolved issues and error corrections

[FIX] l10n_us_hr_payroll: prevent error when generating csv

PR #114294

Enterprisesaas-18.2l10n_us_hr_payroll

This change prevents an error when generating a W-2 CSV report if no end date is entered. The system now uses the current year for the file name in that case, so users can complete the export without interruption.

Original PR description

Currently, an error occurs when user tries to create a csv for w2 form with no end date defined. Steps to replicate: - Install `l10n_us_hr_payroll`. - Open Payroll > Reporting > W2 Report. - Click…

Currently, an error occurs when user tries to create a csv for w2 form with no end date defined.

Steps to replicate:
- Install `l10n_us_hr_payroll`.
- Open Payroll > Reporting > W2 Report.
- Click `New` > Remove value from `End Date` and click Generate.

Error:
```
  File '/home/odoo/odoo19/enterprise/l10n_us_hr_payroll/models/l10n_us_w2.py', line 249, in action_generate_csv
    self.csv_filename = f'form_w2_{self.date_end.year or date.today().year}.csv'
                                   ^^^^^^^^^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'year'
```

Cause:
- As the user did not give any value for `End Date`, False was passed and when the execution flow reached [here] `self.end_date` is False and attempting to access `self.end_date.year` results in this error.

Solution:
- If we do not receive the `self.end_date` while generating the CSV, we will use the current year to generate the CSV file name.

[here]: https://github.com/odoo/enterprise/blob/01be8d6e9384bcb340559847d529b4887e073519/l10n_us_hr_payroll/models/l10n_us_w2.py#L248

No ID

Forward-Port-Of: odoo/enterprise#113408

#payroll#w2#csv#reporting

Branch: 19.0

1 change

Bug Fixes(1)

Resolved issues and error corrections

[FIX] account_reports: fix date format year

PR #114428

Enterprise19.0account_reports

This change corrects the year shown in return names so date ranges display the actual calendar year. It prevents confusing labels like showing Jan 2022 instead of Jan 2023, which improves clarity for users reviewing reports and returns.

Original PR description

Steps to reproduce:
 - Create a return from Jan 2023 to April 2023 -> the dates displayed in the name will be Jan 2022 - Apr 2023

The display is incorrect because we used the wrong date format, and therefore switch from using YYYY to yyyy as the first one is the ISO standard year and the second the calendar year. They might differ on the result here because 01 Jan 2023 falls on a Sunday, but ISO week starts on Monday, so it took the previous year (2022)

#dates#reporting#labels#display

Rows:Rows per page:

10 25 50 100

3 / 3Page 3 of 3 · 211 days total

Some code uses `if query.where_clause` to detect if there are any restrictions on the table. When setting ordered result ids, we simply used a JOIN, so there is no detected where clause. To keep existing code working, we add a dummy 1=1 to the where clause. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260306

Since https://github.com/odoo/odoo/pull/166843, we remove the odoo links entirely from the spreadsheet on `freeze and share`. While it is true that the link is not usable from a public page (and that we'd somehow leak internal views information in the links), cells with links benefit from a specific style that is not hardcoded on the cell but rather computed based on their content. By removing the links from teh cells altogether, the greenish link style is lost on those cells and we actually rely on that style for our dashboards layout. To preserve the intension of https://github.com/odoo/odoo/pull/166843, we introduce a new type of links `neutralized` which allows the cell to be recognized as a link (and benefit from the style) while disabling their behaviour (no click). Task-6063301 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260250 Forward-Port-Of: odoo/odoo#256357

Issue 1: --- Capturing/voiding transaction is failing with the error: `The payment provider rejected the request. Original pspReference required for this operation` Steps to reproduce: 1- Setup Adyen payment provider. 2- Enable `Capture amount manually`. 3- Create a SO and confirm. 4- Generate a payment link and pay. 5- In SO, capture the full amount. Cause: --- After https://github.com/odoo/odoo/commit/efc2788dfccd13ee6feb309430ff57e49664ff97, in the payment `_void()`/`_capture()`, a child tx is created. However the child tx is missing the `provider_reference` required to send the payment provider. Issue 2: --- The child tx created for capture/void is always remains in draft state. Cause: --- This is reproduced after https://github.com/odoo/odoo/commit/efc2788dfccd13ee6feb309430ff57e49664ff97 which we create a child tx in capture/void. But in `_search_by_reference` which is called by webhook to find the tx, we are returning the source tx. As a result only the state of the source tx is changed. opw-6120846 opw-6120071 Forward-Port-Of: odoo/odoo#259223

**Steps to reproduce:** - Install the `accountant` and `purchase` modules. - Create and confirm a Purchase Order (with 1 quantity). - Create a vendor bill using `auto-complete` from the PO, set the quantity to 1, and `confirm` it. - Navigate to Accounting > Review > `Billed Not Received`. - Change the `date` from the top left. - Select a record and click `Create Accrual Entries`. **Error:** `TypeError: '<=' not supported between instances of 'datetime.date' and 'str'` **Root cause:** At [1], the `accrual_entry_date` is set in the context as a `string`. Later, at [2], this value is retrieved from the context and used directly in a comparison with `ivl.date`, which is a `datetime.date`. **Fix:** This commit converts `accrual_entry_date` to a `datetime.date` object at [2], allowing users to create accrual entries without errors. [1]: https://github.com/odoo/enterprise/blob/3ab460a935c6caf013202ec6be1c3708178c8d7d/account_reports/static/src/views/accrual_list_controller.js#L61-L76 [2]: https://github.com/odoo/odoo/blob/7e17c788babc2715e85456467db9172bb0b8e42d/addons/account/wizard/accrued_orders.py#L166-L188 opw-6110907 Forward-Port-Of: odoo/odoo#259047

The `get_default_groups` call happens during super.setUpClass(), therefore we have not checked (yet) if the module in which the security group is in is installed, and we end up with an Exception. task-none Forward-Port-Of: odoo/odoo#260230

Steps to reproduce: - Create a kit with 3 or more components - Create a sales order with the kit and confirm it - Remove at least one of the kit's components from the delivery and validate it - Create the invoice from the sales order and confirm the invoice - Check the journal entries included in the invoice form Current behavior: - There is no COGS entry Expected behavior: - There should be a COGS entry Context: In versions <19, you will get a COGS entry that amounts to the total cost of the kit despite deleting a component from the delivery. With our current code in versions 19+, we can actually improve upon this by only counting the remaining components' costs for the COGS entry's amount. opw-6082565 Forward-Port-Of: odoo/odoo#258982

**Steps to reproduce:** - Install the `l10n_pe_reports_lib` module and switch to a `PE company`. - Create a draft invoice. - Navigate to Reporting > General Ledger. - Click the gear icon and select `Inventory and Balance`. **Error:** AttributeError: 'NoneType' object has no attribute 'replace' **Root Cause:** For draft entries, `move_name` is `None`, and calling `.replace()` on it causes an error at [1]. **Fix:** This commit prevents errors and ensures users can export the general ledger even when draft entries are included. [1]: https://github.com/odoo/enterprise/blob/5babcb5cb951e0e7beebdbef0781a20a7a19c319/l10n_pe_reports_lib/models/account_general_ledger.py#L168 opw-6104117 Forward-Port-Of: odoo/enterprise#113405

Currently, an error occurs when user tries to create a csv for w2 form with no end date defined. Steps to replicate: - Install `l10n_us_hr_payroll`. - Open Payroll > Reporting > W2 Report. - Click `New` > Remove value from `End Date` and click Generate. Error: ``` File '/home/odoo/odoo19/enterprise/l10n_us_hr_payroll/models/l10n_us_w2.py', line 249, in action_generate_csv self.csv_filename = f'form_w2_{self.date_end.year or date.today().year}.csv' ^^^^^^^^^^^^^^^^^^ AttributeError: 'bool' object has no attribute 'year' ``` Cause: - As the user did not give any value for `End Date`, False was passed and when the execution flow reached [here] `self.end_date` is False and attempting to access `self.end_date.year` results in this error. Solution: - If we do not receive the `self.end_date` while generating the CSV, we will use the current year to generate the CSV file name. [here]: https://github.com/odoo/enterprise/blob/01be8d6e9384bcb340559847d529b4887e073519/l10n_us_hr_payroll/models/l10n_us_w2.py#L248 No ID Forward-Port-Of: odoo/enterprise#113408

Steps to reproduce: - Create a return from Jan 2023 to April 2023 -> the dates displayed in the name will be Jan 2022 - Apr 2023 The display is incorrect because we used the wrong date format, and therefore switch from using YYYY to yyyy as the first one is the ISO standard year and the second the calendar year. They might differ on the result here because 01 Jan 2023 falls on a Sunday, but ISO week starts on Monday, so it took the previous year (2022)