Odoo Changelog — 2026-03-05

Thursday, March 5, 2026

207 changes

Branch: saas-19.2

2 changes

Bug Fixes(2)

Resolved issues and error corrections

[FIX] website_helpdesk,*: clarify/fix helpdesk article search behavior

PR #109724

Enterprisesaas-19.2website_helpdesk_knowledge

This update clarifies how Helpdesk articles are searched when a non-root article is selected as the main article. Previously, searching didn't include descendant articles. Additionally, a minor issue with the dropdown functionality has been addressed to prevent empty dropdowns. The team has opted to provide clearer guidance on this behavior rather than attempting a complex domain fix.

Original PR description

*: website_helpdesk_knowledge **Steps to reproduce:** - Install Helpdesk/Knowledge/Website apps - Go to Knowledge - Set up a Knowledge workspace root article with some child articles to it - Go to…

*: website_helpdesk_knowledge

**Steps to reproduce:**
- Install Helpdesk/Knowledge/Website apps
- Go to Knowledge
- Set up a Knowledge workspace root article with some child articles to it
- Go to Helpdesk > Configuration > Helpdesk Teams
- Open a Helpdesk team, and go to its Help Center config
- Check Knowledge and set a non-root article as main Article
- Go to Website > Help

First issue (non-root main article):
- Type a word which is present in both the article and one of its child articles
- Only the given article match the word
- If you use the root article it will match in any descendant

Second issue (in every case):
- Type a word in the search bar
- Wait for the dropdown to appear
- Click elsewhere, dropdown is properly hidden
- Try to change the search > Traceback

**Issue:**
The domain used to find the articles to match the search uses the current id as the `root_article_id`:
`['|', ('id', '=', team_article.id), ('root_article_id', '=', team_article.id)],` which was previously working in every case as it was not possible to set a non-root article in the team setting.

This was later changed to allow any article as the default website page. As a result, when a non-root article is selected, the search domain only applies to that specific article and no longer includes its descendants.

The other issue is related to the added boostrap attribute `data-bs-toggle="dropdown"` which is not properly reset when the dropdown is removed, and triggers the creation of an empty dropdown.

**Fix:**
Doesn't seem easy to fix to allow the search on all the descendants of the given article as we can't use the article `root_article_id` and filter out the unwanted results in a clean way (and it doesn't seem doable with a direct domain). Instead clarify the situation in the help of the article.

Also manually reset the attribute for `_onFocusOut`.

related: https://github.com/odoo/enterprise/commit/ed971d4d02624f8b864ab6c37c6e7db8ba3dfe11

opw-5258607

Forward-Port-Of: odoo/enterprise#109612
Forward-Port-Of: odoo/enterprise#107438

#helpdesk#knowledge base#search

[FIX] l10n_mx_edi_pos: fix tour test_mx_pos_invoice_order_and_refund

PR #109362

Enterprisesaas-19.2l10n_mx_edi_pos

This update resolves a tour test failure caused by a delay in order synchronization. The fix adds a waiting step to ensure the order is fully processed before initiating refunds, preventing a constraint error related to negative order amounts. This ensures refunds are handled correctly within the system.

Original PR description

In this commit:
===============
- Fix the tour `test_mx_pos_invoice_order_and_refund` failing with **WARNING**:
`The amount of the order must be positive for a sale and negative for a refund`.
caused by an order sync issue with the backend.

Cause:
======
- The tour started the refund immediately after validating the order, while the
original order was still syncing with the backend.
- Because of this, the constraint `_l10n_mx_edi_constrains_amount_total`
was triggered since the order had  `amount_total < 0` but `refunded_order_id`
was not set yet.

Fix:
====
- Add a waiting step in the tour to make sure the order is fully synced before
starting the refund flow.

Task: 5993576
Error: 237980

#refund#pos#mexico#edi

Branch: master

4 changes

Bug Fixes(4)

Resolved issues and error corrections

[FIX] l10n_mx_edi_pos: Fix check negative refund lines

PR #107825

Enterprisemasterl10n_mx_edi_posMEDIUM

This update fixes an issue where refund calculations in the MX e-receipt module were incorrectly assuming all refund amounts were positive. The change ensures accurate calculations for refunds, particularly those with negative price subtotals, leading to more reliable financial reporting. This improves the accuracy of financial data related to MX e-receipt transactions.

Original PR description

From this version, the price_subtotal of a refund line is by default always positive so we have to inverse the check of this constraint.

#accounting#reporting#MX e-receipt

[FIX] sale_subscription: align checkbox label on the left

PR #109637

Enterprisemastersale

This update aligns the subscription checkbox label to the left within the product template form. This change improves the visual clarity and user experience of the subscription setup process, making it easier for users to understand and complete their subscriptions.

Original PR description

task-6007762

#subscription#UI#form layout

[FIX] hr_holidays_gantt: fix traceback in Time Off Overview

PR #109337

Enterprisemasterhr

This update fixes a potential error in the Time Off Overview feature that could cause the system to crash if a user lacked specific permissions. The change uses 'optional chaining' to prevent errors when accessing data, ensuring a more stable and reliable user experience.

Original PR description

In hr.leave.report.calendar the work_entry_type_id field has a group group_hr_holidays_user and if the user doesn't have access this group it would lead to a traceback because work_entry_type_id in hr_holidays_gantt_popover will be undefined and we try to access one of its properties. This commit adds optional chaining to protect against this scenario.

task-5940200

#optional#hr_holidays#error_correction

[FIX] {website_}appointment{_hr}: fix URLs for SEO

PR #102105

Enterprisemasterwebsite_appointmentMEDIUM

This update fixes a bug preventing custom URLs for appointment types from being correctly reflected in the website's SEO settings. Now, users can set a custom URL for their appointment types, improving their visibility in search results. This change ensures better SEO performance for appointment pages.

Original PR description

Previously, appointment types URLs were not replaced by the value entered in the Cutsom Url field of the Optimize SEO form, this is not longer the case. This PR replaces the appointment type's id by the slug of this one in the appointment URLs. This allows users to change the slug of the appointment types and to get a better SEO for the appointment pages. This change has not been done for URLs that users are not supposed to access in order to prevent them from competing with URLs that need to be indexed.

The model is not used in the backend URLs' patterns since URLs can be shared with users that may not have access to the appointment model triggering an AccessError. For this reason, the routes expect the slug to be a string, which is unslugged in the controller method to get the appointment's id and then fetch the appointment's record with it.

Reproduce:
On the page of an appointment type, submit a custom URL in the "Search Engine Optimization" form which is displayed when clicking on "Optimize SEO", in the "Site" menu shown when the website editor is enabled. The user should be redirected to the new URL which is not the case.

After the fix:
The slug of the appointment type must be replaced by the value submitted in the "Search Engine Optimization".

Community PR: https://github.com/odoo/odoo/pull/249487

Task-5114394

#SEO#website#appointments

Branch: 19.0

1 change

Bug Fixes(1)

Resolved issues and error corrections

[FIX] mrp_workorder: hide pre-filled lines for by-products in shopfloor

PR #109689

Enterprise19.0mrp_workorderMEDIUM

This update resolves an issue where by-products tracked by serial numbers were incorrectly showing extra lines in the shop floor manufacturing order view. The change ensures that by-products only display lines that have been manually added, aligning with the intended workflow. This improves the clarity and accuracy of shop floor data.

Original PR description

When the "pre fill lot/serial numbers in shopfloor" setting is enabled on the manufacturing operation type, by-products tracked by serial number were incorrectly showing extra empty lines in…

Steps to reproduce:
1. Create a bill of materials for a final product
2. Add a consumable component
3. Create an operation without steps
4. Add a by-product tracked by serial number
5. Specify that the by-product is produced in the operation above
6. In Inventory > Configuration > Operations Types, open the Manufacturing operation type, go to the Traceability section and enable "Pre fill lot/serial numbers in shop floor moves"
7. Create a manufacturing order for the BOM and confirm it
8. Open the Shop Floor view from the MO
9. Observe the extra line for the by-product in both overview and work center views

Root cause:
The visibleMoveLines getter in stock_move.js was showing ALL move lines (including unpicked ones) when picking_type_prefill_shop_floor_lots was enabled, without distinguishing between raw materials/components and by-products. By-products should never show pre-filled lines since users must register them manually by clicking the + button.

Solution:
Modified the visibleMoveLines getter to always filter by-products to show only picked move lines, regardless of the prefill_shop_floor_lots setting. This ensures by-products only display lines that have been explicitly registered by the user, while regular components continue to show pre-filled lines when the setting is enabled.

Task-5431295

Forward-Port-Of: odoo/enterprise#109574
Forward-Port-Of: odoo/enterprise#103260

#manufacturing#shopfloor#inventory

Rows:Rows per page:

10 25 50 100

3 / 3Page 3 of 3 · 207 days total

*: website_helpdesk_knowledge **Steps to reproduce:** - Install Helpdesk/Knowledge/Website apps - Go to Knowledge - Set up a Knowledge workspace root article with some child articles to it - Go to Helpdesk > Configuration > Helpdesk Teams - Open a Helpdesk team, and go to its Help Center config - Check Knowledge and set a non-root article as main Article - Go to Website > Help First issue (non-root main article): - Type a word which is present in both the article and one of its child articles - Only the given article match the word - If you use the root article it will match in any descendant Second issue (in every case): - Type a word in the search bar - Wait for the dropdown to appear - Click elsewhere, dropdown is properly hidden - Try to change the search > Traceback **Issue:** The domain used to find the articles to match the search uses the current id as the `root_article_id`: `['|', ('id', '=', team_article.id), ('root_article_id', '=', team_article.id)],` which was previously working in every case as it was not possible to set a non-root article in the team setting. This was later changed to allow any article as the default website page. As a result, when a non-root article is selected, the search domain only applies to that specific article and no longer includes its descendants. The other issue is related to the added boostrap attribute `data-bs-toggle="dropdown"` which is not properly reset when the dropdown is removed, and triggers the creation of an empty dropdown. **Fix:** Doesn't seem easy to fix to allow the search on all the descendants of the given article as we can't use the article `root_article_id` and filter out the unwanted results in a clean way (and it doesn't seem doable with a direct domain). Instead clarify the situation in the help of the article. Also manually reset the attribute for `_onFocusOut`. related: https://github.com/odoo/enterprise/commit/ed971d4d02624f8b864ab6c37c6e7db8ba3dfe11 opw-5258607 Forward-Port-Of: odoo/enterprise#109612 Forward-Port-Of: odoo/enterprise#107438

In this commit: =============== - Fix the tour `test_mx_pos_invoice_order_and_refund` failing with **WARNING**: `The amount of the order must be positive for a sale and negative for a refund`. caused by an order sync issue with the backend. Cause: ====== - The tour started the refund immediately after validating the order, while the original order was still syncing with the backend. - Because of this, the constraint `_l10n_mx_edi_constrains_amount_total` was triggered since the order had `amount_total < 0` but `refunded_order_id` was not set yet. Fix: ==== - Add a waiting step in the tour to make sure the order is fully synced before starting the refund flow. Task: 5993576 Error: 237980

In hr.leave.report.calendar the work_entry_type_id field has a group group_hr_holidays_user and if the user doesn't have access this group it would lead to a traceback because work_entry_type_id in hr_holidays_gantt_popover will be undefined and we try to access one of its properties. This commit adds optional chaining to protect against this scenario. task-5940200

Previously, appointment types URLs were not replaced by the value entered in the Cutsom Url field of the Optimize SEO form, this is not longer the case. This PR replaces the appointment type's id by the slug of this one in the appointment URLs. This allows users to change the slug of the appointment types and to get a better SEO for the appointment pages. This change has not been done for URLs that users are not supposed to access in order to prevent them from competing with URLs that need to be indexed. The model is not used in the backend URLs' patterns since URLs can be shared with users that may not have access to the appointment model triggering an AccessError. For this reason, the routes expect the slug to be a string, which is unslugged in the controller method to get the appointment's id and then fetch the appointment's record with it. Reproduce: On the page of an appointment type, submit a custom URL in the "Search Engine Optimization" form which is displayed when clicking on "Optimize SEO", in the "Site" menu shown when the website editor is enabled. The user should be redirected to the new URL which is not the case. After the fix: The slug of the appointment type must be replaced by the value submitted in the "Search Engine Optimization". Community PR: https://github.com/odoo/odoo/pull/249487 Task-5114394

When the "pre fill lot/serial numbers in shopfloor" setting is enabled on the manufacturing operation type, by-products tracked by serial number were incorrectly showing extra empty lines in shopfloor MO cards (both in overview and work center views). Steps to reproduce: 1. Create a bill of materials for a final product 2. Add a consumable component 3. Create an operation without steps 4. Add a by-product tracked by serial number 5. Specify that the by-product is produced in the operation above 6. In Inventory > Configuration > Operations Types, open the Manufacturing operation type, go to the Traceability section and enable "Pre fill lot/serial numbers in shop floor moves" 7. Create a manufacturing order for the BOM and confirm it 8. Open the Shop Floor view from the MO 9. Observe the extra line for the by-product in both overview and work center views Root cause: The visibleMoveLines getter in stock_move.js was showing ALL move lines (including unpicked ones) when picking_type_prefill_shop_floor_lots was enabled, without distinguishing between raw materials/components and by-products. By-products should never show pre-filled lines since users must register them manually by clicking the + button. Solution: Modified the visibleMoveLines getter to always filter by-products to show only picked move lines, regardless of the prefill_shop_floor_lots setting. This ensures by-products only display lines that have been explicitly registered by the user, while regular components continue to show pre-filled lines when the setting is enabled. Task-5431295 Forward-Port-Of: odoo/enterprise#109574 Forward-Port-Of: odoo/enterprise#103260