Odoo Changelog — 2026-05-23

Saturday, May 23, 2026

8 changes · master

Bug Fixes(8)

Resolved issues and error corrections

[IMP] helpdesk: calculate close_hours based on open stages only

EnterprisemasterhelpdeskMEDIUM

This update fixes an issue where ticket close times were inaccurate when tickets were reopened and closed again. Now, the calculation considers only the time spent in currently open stages related to the ticket's team, providing a more precise record of time spent resolving the issue. This ensures more reliable reporting on support team efficiency.

Original PR description

Issue:
When a ticket is reopened and closed again, `close_hours` included time spent in previous closing stages, causing inaccurate total close time.

Before this commit:
The `close_hours` field was computed as the total time from ticket creation to close date.
If a ticket was closed and later reopened, the time spent in the closed stage was still included in the final `close_hours`, which led to inaccurate results.

After this commit:
`close_hours` is now computed by summing the working minutes from `duration_stage_tracking` field, considering only 
  the open stages related to the ticket's team.

task-4133988

#helpdesk#ticket#reporting#time tracking

[FIX] l10n_fr_reports: fix carryover reimbursement move generation

PR #118081

Enterprisemasterl10n_fr_reportsMEDIUM

This update fixes an error in how VAT reimbursement moves are generated when unclaimed tax is carried over to the next month. The previous calculation incorrectly used data from the previous month's tax report, leading to inaccurate reimbursement amounts. This ensures accurate VAT reporting and proper reimbursement processing.

Original PR description

When generating a VAT return with an unclaimed tax amount carried to the next month, the carryover reimbursement move amounts are computed with an incorrect ratio. Steps to reproduce: - Create and…

When generating a VAT return with an unclaimed tax amount carried to the
next month, the carryover reimbursement move amounts are computed with
an incorrect ratio.

Steps to reproduce:
- Create and post a bill in May containing a VAT amount.
- Create and post a bill in June containing a VAT amount.
- Create a VAT return for May to carry over the VAT amount to the next
  month.
- Create a VAT return for June, requesting the full VAT amount to be
  reimbursed.
- Validate and send the June VAT return.
- Check the generated reimbursement move

Issue: Line values does not correspond to anything real/tangible.  It
occurs because when computing the ratio for the move we check the last
tax report entry, where we find the amount of tax from the past months
and a line balancing the last month that should not be taken into
account.  The "Balance tax current account (receivable)" line from the
tax closing entry is mistakenly picked up as a tax carried forward line,
throwing off the amounts.

opw-5961836

Forward-Port-Of: odoo/enterprise#117927
Forward-Port-Of: odoo/enterprise#115451

#VAT#reporting#tax#reimbursement

[FIX] ai: add available menus when using create/update topics

PR #118087

EnterprisemasteraiMEDIUM

This update fixes a bug where the Odoo Agent would repeatedly fail when updating records without the specific 'natural language query' topic. By adding a list of available menus and models to the context, the Agent now correctly identifies and interacts with records, preventing timeouts and improving stability.

Original PR description

Purpose:
--------
The update and create tools can generate a link to show a preview of the created/updated record. However, the list of available menus is only added when the agent has the natural language query topic. Therefore, when using the Odoo Agent (that does not have that topic) to update a record, the LLM loops on the update record tool guessing random menu ids and eventually times out because the tool calls fail since the menu ids guesses do not match the model of the updated record.

The list of available menus is now added in the context if the create or update records topics are available on the agent.
The list of available models has also been added in this case.

Task-6236642

Forward-Port-Of: odoo/enterprise#117998

#ai#agent#update#create

[FIX] website_sale_renting: Add rental product to cart

PR #118029

Enterprisemasterwebsite_sale_rentingMEDIUM

This update fixes a problem where adding rental products to the cart would fail due to mismatched date calculations. The fix ensures that rental product durations are correctly handled, preventing errors when mixing different rental periods and improving the overall rental experience. This resolves a conflict between how dates are stored and processed during the cart addition process.

Original PR description

Steps to reproduce: =================== 1. Go to the shop page and use the rental date picker to select a start and end date with hours. 2. Find a rental product configured with "Days" pricing. 3.…

Steps to reproduce:
===================
1. Go to the shop page and use the rental date picker to select a start and end date with hours.
2. Find a rental product configured with "Days" pricing.
3. Add to card directly from the product card
4. Add a rental product from product image that has date type value date
5. Go to that product details page.
6. Click add to cart

-> Invalid operation, You cannot mix different rental periods...

Cause:
======
When adding a product from the shop list view, the system uses the default start/end dates (from the rental period) exactly as first added.

However, the "Add to Cart" logic on the product details page attempts to adapt the selected dates to the product's specific rental unit (e.g., normalizing the time component for 'Day' pricing).

This re-calculation creates a timestamp mismatch between the item already in the cart (from the shop view) and the new item being added (from the details page).

Solution:
=========
The add-to-cart flow has been updated to correctly utilize the default duration values (the globally selected dates) if they exist.

opw-5450576

Forward-Port-Of: odoo/enterprise#117946
Forward-Port-Of: odoo/enterprise#103373

#rental#cart#pricing

[FIX] account_asset: change 'Set to Draft' visibility condition

PR #118072

EnterprisemasteraccountMEDIUM

This update fixes an issue where users could attempt to change assets to draft after setting lock dates in the accounting system. This prevented users from modifying finalized accounting records, ensuring data integrity and compliance with accounting standards. The change restricts draft status for assets after lock dates are applied.

Original PR description

Steps to reproduce:
1- Install Accounting
2- Go to [Accounting -> Assets] and create a new asset with start date 1/1/2025
3- Specify the fixed asset account and confirm the asset
4- Open [Accounting -> Lock Dates]
5- Set a Lock date on everything with the date 31/12/2025 and save
6- Cancel the asset, set to draft and confirm again

Issue:
`Invalid Operation: The remaining value on the last depreciation line must be 0`

Expected behavior:
Should not be able to set to draft once the asset is cancelled

Why this happens:
Commit 66db1d5 introduced a new condition on the `Set to Draft` button which results in the button being visible when it should not be. If a Lock Date is set after an asset is confirmed, the acquisition and any depreciation entries are effectively finalized in the accounting history. Allowing a user to "Set to Draft" at that point would involve deleting or modifying entries in a closed period, which violates accounting integrity.

opw-6152777

Forward-Port-Of: odoo/enterprise#116900

#accounting#asset management#data integrity

[FIX] hr_payroll: hide button crash on in-memory payrun warnings

PR #118013

Enterprisemasterhr_payrollMEDIUM

This update resolves a crash that occurred when users clicked the 'hide' button on the payroll dashboard due to an error in how in-memory payrun warnings were handled. The fix ensures warnings are correctly identified and processed, preventing the database error and improving dashboard stability. This change impacts the payroll dashboard functionality.

Original PR description

Closing date payrun warnings are created as in-memory records (.new()), giving them a NewId instead of a real integer DB id. When the user clicked the hide button, this NewId string was passed to action_snooze/action_archive, causing a psycopg2.errors.InvalidTextRepresentation SQL error.

Fix by sending False as the id for in-memory warnings in get_payroll_dashboard_warning_cards, and suppressing the hide button on the dashboard when warning.id is falsy.

task-6205849

Forward-Port-Of: odoo/enterprise#117854

#payroll#dashboard#warning

[FIX] pos_avatax: only use AvaTax FP if activated in POS

PR #118084

Enterprisemasterpos_avataxMEDIUM

This update fixes an issue where the POS incorrectly applied AvaTax fiscal positions even when AvaTax wasn't activated in the POS settings. The system now prioritizes AvaTax fiscal positions only when AvaTax is enabled in the accounting settings, ensuring accurate tax calculations for POS transactions. This improves the reliability of the Point of Sale tax functionality.

Original PR description

**Steps to reproduce:** - Install Accounting and Point of Sale - In Accounting settings, activate "AvaTax" - Configure the AvaTax fiscal position and activate "Detect Automatically" option - Make…

**Steps to reproduce:**
- Install Accounting and Point of Sale

- In Accounting settings, activate "AvaTax"
- Configure the AvaTax fiscal position and activate "Detect Automatically" option
- Make sure that the other fiscal positions don't have that option set or that they are ordered after the AvaTax one

- Go to the settings of a point of Sale
- Activate "Flexible Taxes" and configure "Default" and "Allowed"
- Make sure that AvaTax fiscal position is not allowed
- Do not activate "AvaTax PoS Integration"

- Open a POS session
- Select a customer with an address in the US and without fiscal position
- Check the fiscal position

**Issue:**
The selected fiscal position is the AvaTax one even though AvaTax is not activated in the POS.

**Cause:**
We force the use of a fiscal position if it is configured on a customer.
In this case, as no fiscal position is configured on the customer, we try to retrieve one that matches the condition and the AvaTax one is selected.

**Solution:**
When searching for the fiscal position of a customer, if AvaTax is not configured in the POS and if its fiscal positions are not allowed in POS, we ignore the fiscal positions using AvaTax.

opw-6154089

Forward-Port-Of: odoo/enterprise#116626

#tax#pos#avatax

[FIX] stock_barcode_mrp: barcode setting for MO

PR #118095

Enterprisemasterstock_barcode_mrpMEDIUM

This update fixes inconsistencies in how barcode settings are applied to Manufacturing Orders. Previously, mandatory scan requirements weren't consistently enforced, allowing users to bypass them. Now, the system correctly utilizes MRP operation type configurations, ensuring accurate barcode tracking during production processes.

Original PR description

Before this commit, the "Allow full order validation" were partially ignored in the Barcode app when used for Manufacturing Orders, and the "Mandatory scan" settings didn't work very well. For…

Before this commit, the "Allow full order validation" were partially ignored in the Barcode app when used for Manufacturing Orders, and the "Mandatory scan" settings didn't work very well.

For example, setting the scan of lot/serial as mandatory didn't prevent the user to set automatically a SN on consummed component by generating a lot/serial on the produced product or by clicking on "Produce All" button.

This commit adds some conditions to avoid to update barcode lines in case they should depending of the config.

This commit also fixes a related issue where the MRP operation type's config wasn't used at all when a MO is created directly from the Barcode app.
As the config is get from the MO's picking type and no MO exists when a new one is created from the Barcode app, there is no MO's config returned in the data send by the server.
To fix that, the config is now updated clientside when the data are fetched after a save.

[Task-5420762](https://www.odoo.com/odoo/project/966/tasks/4655907/project.task/5420762)
[opw-5223507](https://www.odoo.com/odoo/project/49/tasks/5223507)

Forward-Port-Of: odoo/enterprise#117816
Forward-Port-Of: odoo/enterprise#113318

#manufacturing#barcode#MRP

Issue: When a ticket is reopened and closed again, `close_hours` included time spent in previous closing stages, causing inaccurate total close time. Before this commit: The `close_hours` field was computed as the total time from ticket creation to close date. If a ticket was closed and later reopened, the time spent in the closed stage was still included in the final `close_hours`, which led to inaccurate results. After this commit: `close_hours` is now computed by summing the working minutes from `duration_stage_tracking` field, considering only the open stages related to the ticket's team. task-4133988

When generating a VAT return with an unclaimed tax amount carried to the next month, the carryover reimbursement move amounts are computed with an incorrect ratio. Steps to reproduce: - Create and post a bill in May containing a VAT amount. - Create and post a bill in June containing a VAT amount. - Create a VAT return for May to carry over the VAT amount to the next month. - Create a VAT return for June, requesting the full VAT amount to be reimbursed. - Validate and send the June VAT return. - Check the generated reimbursement move Issue: Line values does not correspond to anything real/tangible. It occurs because when computing the ratio for the move we check the last tax report entry, where we find the amount of tax from the past months and a line balancing the last month that should not be taken into account. The "Balance tax current account (receivable)" line from the tax closing entry is mistakenly picked up as a tax carried forward line, throwing off the amounts. opw-5961836 Forward-Port-Of: odoo/enterprise#117927 Forward-Port-Of: odoo/enterprise#115451

Purpose: -------- The update and create tools can generate a link to show a preview of the created/updated record. However, the list of available menus is only added when the agent has the natural language query topic. Therefore, when using the Odoo Agent (that does not have that topic) to update a record, the LLM loops on the update record tool guessing random menu ids and eventually times out because the tool calls fail since the menu ids guesses do not match the model of the updated record. The list of available menus is now added in the context if the create or update records topics are available on the agent. The list of available models has also been added in this case. Task-6236642 Forward-Port-Of: odoo/enterprise#117998

Steps to reproduce: =================== 1. Go to the shop page and use the rental date picker to select a start and end date with hours. 2. Find a rental product configured with "Days" pricing. 3. Add to card directly from the product card 4. Add a rental product from product image that has date type value date 5. Go to that product details page. 6. Click add to cart -> Invalid operation, You cannot mix different rental periods... Cause: ====== When adding a product from the shop list view, the system uses the default start/end dates (from the rental period) exactly as first added. However, the "Add to Cart" logic on the product details page attempts to adapt the selected dates to the product's specific rental unit (e.g., normalizing the time component for 'Day' pricing). This re-calculation creates a timestamp mismatch between the item already in the cart (from the shop view) and the new item being added (from the details page). Solution: ========= The add-to-cart flow has been updated to correctly utilize the default duration values (the globally selected dates) if they exist. opw-5450576 Forward-Port-Of: odoo/enterprise#117946 Forward-Port-Of: odoo/enterprise#103373

Steps to reproduce: 1- Install Accounting 2- Go to [Accounting -> Assets] and create a new asset with start date 1/1/2025 3- Specify the fixed asset account and confirm the asset 4- Open [Accounting -> Lock Dates] 5- Set a Lock date on everything with the date 31/12/2025 and save 6- Cancel the asset, set to draft and confirm again Issue: `Invalid Operation: The remaining value on the last depreciation line must be 0` Expected behavior: Should not be able to set to draft once the asset is cancelled Why this happens: Commit 66db1d5 introduced a new condition on the `Set to Draft` button which results in the button being visible when it should not be. If a Lock Date is set after an asset is confirmed, the acquisition and any depreciation entries are effectively finalized in the accounting history. Allowing a user to "Set to Draft" at that point would involve deleting or modifying entries in a closed period, which violates accounting integrity. opw-6152777 Forward-Port-Of: odoo/enterprise#116900

Closing date payrun warnings are created as in-memory records (.new()), giving them a NewId instead of a real integer DB id. When the user clicked the hide button, this NewId string was passed to action_snooze/action_archive, causing a psycopg2.errors.InvalidTextRepresentation SQL error. Fix by sending False as the id for in-memory warnings in get_payroll_dashboard_warning_cards, and suppressing the hide button on the dashboard when warning.id is falsy. task-6205849 Forward-Port-Of: odoo/enterprise#117854

**Steps to reproduce:** - Install Accounting and Point of Sale - In Accounting settings, activate "AvaTax" - Configure the AvaTax fiscal position and activate "Detect Automatically" option - Make sure that the other fiscal positions don't have that option set or that they are ordered after the AvaTax one - Go to the settings of a point of Sale - Activate "Flexible Taxes" and configure "Default" and "Allowed" - Make sure that AvaTax fiscal position is not allowed - Do not activate "AvaTax PoS Integration" - Open a POS session - Select a customer with an address in the US and without fiscal position - Check the fiscal position **Issue:** The selected fiscal position is the AvaTax one even though AvaTax is not activated in the POS. **Cause:** We force the use of a fiscal position if it is configured on a customer. In this case, as no fiscal position is configured on the customer, we try to retrieve one that matches the condition and the AvaTax one is selected. **Solution:** When searching for the fiscal position of a customer, if AvaTax is not configured in the POS and if its fiscal positions are not allowed in POS, we ignore the fiscal positions using AvaTax. opw-6154089 Forward-Port-Of: odoo/enterprise#116626

Before this commit, the "Allow full order validation" were partially ignored in the Barcode app when used for Manufacturing Orders, and the "Mandatory scan" settings didn't work very well. For example, setting the scan of lot/serial as mandatory didn't prevent the user to set automatically a SN on consummed component by generating a lot/serial on the produced product or by clicking on "Produce All" button. This commit adds some conditions to avoid to update barcode lines in case they should depending of the config. This commit also fixes a related issue where the MRP operation type's config wasn't used at all when a MO is created directly from the Barcode app. As the config is get from the MO's picking type and no MO exists when a new one is created from the Barcode app, there is no MO's config returned in the data send by the server. To fix that, the config is now updated clientside when the data are fetched after a save. [Task-5420762](https://www.odoo.com/odoo/project/966/tasks/4655907/project.task/5420762) [opw-5223507](https://www.odoo.com/odoo/project/49/tasks/5223507) Forward-Port-Of: odoo/enterprise#117816 Forward-Port-Of: odoo/enterprise#113318