Wednesday, April 8, 2026
41 changes · saas-19.1
Resolved issues and error corrections
This update adjusts the VAT number used in the 'L10nThaiTaxReportTest' test case to align with recent changes in how companies and individuals are created within Odoo. This ensures accurate reporting for Thai tax purposes and maintains consistency with updated business processes.
Original PR description
in this commit:- - We're changing partner's vat in 'L10nThaiTaxReportTest' and adopting new vat as per new way of creating company and individual. as `branch name` is depend upon 'is_company'. - see https://github.com/odoo/odoo/commit/f6e431c813787958897526a4d6570124048b428a task-6002111
This update fixes an issue where the helpdesk website displayed all published knowledge articles, regardless of which team the helpdesk was associated with. Now, the website only shows articles linked to the specific helpdesk team or its related teams, improving the user experience and ensuring relevant information is presented.
Original PR description
To reproduce: ============= - create multiple published knowledge articles - link one of them to a helpdesk team - check the help page on website -> all public articles are listed Problem: ======== when fetching the articles to list, we don't take into account the team configuration and we list all the published articles. Solution: ========= fetch only the article linked to the team or its children. opw-5913355 Forward-Port-Of: odoo/enterprise#113025 Forward-Port-Of: odoo/enterprise#109361
This update resolves a technical issue preventing the accurate registration of super payments in the Australian payroll system. The fix initializes an error message to avoid returning NULL values, ensuring data integrity. New tests have been added to verify the corrected functionality.
Original PR description
. Initialize the error message with an empty string to avoid returning NULL. . Add corresponding tests task-6091444 Forward-Port-Of: odoo/enterprise#112930
This update resolves a crash in the Gantt view that occurred when opening the view on days with Daylight Saving Time transitions. The fix addresses an issue where incorrect time calculations led to a data error, preventing users from accessing the Gantt chart. This ensures the Gantt view remains stable across different time zones.
Original PR description
Steps to reproduce 1. Set your timezone to Asia/Beirut 2. Open a Gantt view (e.g. Planning) in week scale on the last Sunday of March (DST spring-forward day) Issue Beirut's DST spring-forward makes that day only 23 hours long. luxon's .diff() works in absolute time, so diffColumn() returned a float (e.g. 6.958 instead of 7 for a full week). Array(6.958) throws RangeError: Invalid array length, crashing the entire gantt view. Forward-Port-Of: odoo/enterprise#112840
This update resolves a technical issue in the UrbanPiper Test Order wizard where clicking an 'open product' icon caused a system error. The fix disables the product form opening functionality within this specific wizard, preventing the error and improving stability. This ensures the test order process functions correctly.
Original PR description
Steps to Reproduce ---------- - Make an UrbanPiper Test Order - Select a product - Click the external-link (open) icon - POS traceback appears Issue ----------- Clicking the “open product” icon triggered a traceback because the POS attempted to load the missing hr_expense_product_form view. Fix -------------- Disable form open/create for the product field to remove the quick-open product icon, as there is no need to open the product form from this wizard. Task-6089707
This update fixes an issue related to how dates and times are displayed in the Enterprise version of Odoo. The system now correctly shows seconds when requested, and previously hidden formatting options have been removed for clarity. This ensures consistent and accurate time representation across the application.
Original PR description
In this [commit] the short format has been removed from misc methods because there was no more _short format fields in res.lang. But the short format was used to remove seconds from the res.lang format. Now, this behaviour has been restored with the new datetime format system and the unused format 'long' and 'full' has been removed from the doc string to avoid misunderstanding. The formatDateTime from the JS use the format from the res.lang too. So the same behaviour has been implemented there to be able to show seconds through the option 'showSeconds'. It's also fix the fact that this option didn't have any effect when the datetime was shown in numeric mode. [commit]: odoo/odoo@062b140 opw-6030342 Forward-Port-Of: odoo/enterprise#112505
This update resolves an issue where manufacturing orders weren't correctly incorporating component variants during intercompany purchases. The fix ensures that the correct variant information is retrieved from the purchase order, allowing for accurate production scheduling and fulfilling intercompany transactions properly. This improves the reliability of intercompany order fulfillment.
Original PR description
In a multicompany setting, when buying product with intercompany rule, the never variant attribute was lost. Steps to reproduce: ------------------- * Enable intercompany transaction * Enable variant…
In a multicompany setting, when buying product with intercompany rule, the never variant attribute was lost.
Steps to reproduce:
-------------------
* Enable intercompany transaction
* Enable variant grid entry
* Enable multistep routes
* Unarchive MTO
* Settings>Users & Companies>Companies
* Enable Generate Sales Orders in company A
* Create a product:
- Never variant with at least two values
- MTO and manufacture
* Create a bom,
- Company : company B
- Add a component with apply on variant: choose one of the variants
* Create and confirm a purchase order, for a never variant of the product, in company A with vendor as company B
* Confirm the sales order in company B
-> The manufacture order does not include the components that are applied on variant
Observation:
-------------
When creating a sale order for an intercompany rule, button_approve is overwritten and it calls the function "inter_company_create_sale_order.
That function will create the sale order from the data of the purchase order:
https://github.com/odoo/enterprise/blob/273528ba462f2f2b5768bf29dbdb697713a8e619/sale_purchase_inter_company_rules/models/purchase_order.py#L63-L64
When preparing the value for each order line, the attribute value for the never variant will not be retrieved:
https://github.com/odoo/enterprise/blob/273528ba462f2f2b5768bf29dbdb697713a8e619/sale_purchase_inter_company_rules/models/purchase_order.py#L63-L64
Since the attribute value is lost, it will not be retrived by the mto since it should get the value from the PO.
opw-5438723
Forward-Port-Of: odoo/enterprise#107122This update fixes an issue where users couldn't validate delivery orders when using the 'To Pickup' button in the industry_fsm_stock module. The fix removes a technical restriction that prevented the form view from opening, now enabling users to properly complete the delivery order process.
Original PR description
Steps to reproduce: - Install `industry_fsm_stock` - Create a task and add a product - Click on the "Sale Order" button - Add another product with the Invoicing Policy set to "Delivered quantities" - Click on the "To Pickup" button Issue: Users are unable to validate the delivery order from the products pick up button. Cause: In pr https://github.com/odoo/odoo/pull/227630 the parent view is set with `editable="bottom"`, which prevents opening the form view from the list. Fix: Allow opening the form view from the list view so users can validate the delivery order. Task-5969303 Forward-Port-Of: odoo/enterprise#110125
This update resolves a display issue in the Danish balance sheet and profit & loss reports. The changes simplify the report format by using account names directly, and ensure accurate Danish translations for both the report and its English counterpart. This improves the clarity and usability of financial reports for Danish users.
Original PR description
We updated the Danish balance sheet and profit and loss reports to reflect the changes in the Danish chart of accounts and common practice in Danish accounting. We also simplified the reports to use the accounts themselves as sublines instead of having a separate report line for each account. Finally we made sure we use the official Danish translations and updated the English translations as well. task-5929517 Related: https://github.com/odoo/odoo/pull/256541 Forward-Port-Of: odoo/enterprise#113097 Forward-Port-Of: odoo/enterprise#112430
This update fixes an issue where rental order confirmations didn't properly update the shift status in Planning. Now, shifts are automatically marked as 'published' when a rental order is created, ensuring accurate status tracking. Additionally, access to certain buttons has been restricted for users without sales permissions to prevent access errors.
Original PR description
sale_renting_planning: fix shift state after creating rental order -------- **Steps to Reproduce:** Create a shift in Planning. Click New Order. Save and confirm the rental order. Check the shift in…
sale_renting_planning: fix shift state after creating rental order -------- **Steps to Reproduce:** Create a shift in Planning. Click New Order. Save and confirm the rental order. Check the shift in Planning it is still in draft. **Issue:** The shift stays in draft even after the rental order is confirmed. **Cause** When creating a rental order from a shift, the shift is not marked as planned. It only gets linked to the order after saving, so it never updates its status. **Fix:** Mark the shift as published when confirming a new rental order. This makes the shift show the correct status right away and keeps it consistent with the “Add to Last Order” button. sale_renting_planning: fix access error on clicking new order button ---------------- steps to reproduce: user has no sale access (only planning access) create a new shift click on 'New Order' or 'ADD to Last Order' button access error occurs cause: the 'New Order' and 'Add to Last Order' buttons were visible to users without sales access rights. issue: The buttons open the sale order form view, but users without sales access cannot read sale orders data, resulting in access errors. fix: Hide both buttons for users who do not have sale access rights. task-5075839 Forward-Port-Of: odoo/enterprise#112373 Forward-Port-Of: odoo/enterprise#99642
This update corrects a test within the Odoo Enterprise web_studio module to reflect a recent change in the user interface label for a text formatting option. Specifically, the test now correctly identifies the new label 'Select text style' instead of the previous 'Select font style'. This ensures the test accurately validates the functionality after the label update.
Original PR description
#### Description of the change: - Update the expected test string from "Select font style" to "Select text style" after the label change. community-https://github.com/odoo/odoo/pull/236904 task-5155813
This update resolves an issue where the breadcrumb navigation within the Barcode app was sometimes showing a blank entry instead of the originating document's name. Now, when navigating from Barcode actions to related records, the breadcrumb correctly displays the document name, improving user clarity and ease of navigation. This ensures users can quickly understand the context of their work.
Original PR description
*: stock_barcode_mrp, stock_barcode_picking_batch ## Issue Before This PR: When navigating from the Barcode client action (e.g. picking, inventory, etc.) to related form views (such as lot, product,…
*: stock_barcode_mrp, stock_barcode_picking_batch
## Issue Before This PR:
When navigating from the Barcode client action
(e.g. picking, inventory, etc.) to related form views
(such as lot, product, or company), the breadcrumb
would sometimes display an unnamed entry instead
of the originating document name.
This caused confusion for users, as they could not
easily identify which document they were coming from
when navigating to related records from the Barcode interface.
## Steps to Reproduce:
- Install the Barcode module.
- Open the Barcode app and navigate to:
- Delivery Orders.
- Manufacturing Orders
- Batch Pickings
- Inventory Count
- From any of these open a record
(e.g. picking, MO, batch, inventory line)
- Click on document name or edit button on the line.
- Click on an external link (e.g. product, lot, company).
- Observe that the breadcrumb shows an unnamed entry.
## Cause of the Issue:
- When switching views inside the Barcode client action,
the FormController calls `setDisplayName(this.displayName())`.
In some cases, this returns an empty string, overwriting the
previously set breadcrumb name.
- In several form views, the `display_name` field was not present,
preventing the controller from retrieving a proper name.
## With This PR:
The Barcode views now display the correct document names in the
breadcrumb when navigating to external links, allowing users to easily
identify the originating document when opening related records from
the Barcode app.
TaskID: 4978997
Forward-Port-Of: odoo/enterprise#112988
Forward-Port-Of: odoo/enterprise#99165This update fixes a layout issue in the Italian Libro Giornale PDF report. When accounts with long names are used, the report's formatting was broken, causing excessive column expansion and gaps. The fix adds a CSS class to handle long account names, resulting in a cleaner and more readable report.
Original PR description
When generating the Libro Giornale (IT) PDF report with an account that has a very long name, the column expands excessively and break the layout. Steps to reproduce: - With an IT company setup - Have an account with a very long name - Create an invoice using the account - Open Accounting / Reporting / Audit Reports / Journal Audit - Select variant "Libro Giornale (IT)" - Print PDF Issue: The long account name makes the column excessively large. As a result, the font shrinks to fit the page width, leaving wide gaps between lines. **before patch** <img width="794" height="493" alt="screenshot_047" src="https://github.com/user-attachments/assets/6faa5b57-9c60-41cb-9200-003a50019180" /> **after patch** <img width="793" height="553" alt="screenshot_046" src="https://github.com/user-attachments/assets/e97c8948-410b-4201-83c3-04173220d9ce" /> opw-5457103 Forward-Port-Of: odoo/enterprise#112743
This update resolves an issue preventing the correct generation of Intrastat reports when using French language settings that utilize commas as decimal separators. The fix also addresses a previous error related to product weights, ensuring smoother report processing. This improvement enhances the reliability of Intrastat reporting for French-speaking users.
Original PR description
Before this commit, in 19.0+, languages that use commas instead of periods for decimals could not download the intrastat report. Simply attempting to change a string to a float was not enough. Also, when a product had a NoneType weight assigned to it another trace back would occur. This also adds a more descriptive and helpful error message. opw-6026730 Forward-Port-Of: odoo/enterprise#112627
This update fixes how default customer partners are assigned when creating orders in our Point of Sale (POS) system for specific countries (Chile, Colombia, Ecuador, and Guatemala). The change centralizes partner assignment, ensuring consistent and accurate order creation across these localized versions. This improves order processing reliability and data accuracy.
Original PR description
Replace the `createNewOrder()` override with `getDefaultPartnerId()` in l10n_cl_edi_pos, l10n_co_edi_pos, l10n_ec_edi_pos and l10n_gt_edi_pos. The default partner assignment is now handled centrally in `point_of_sale`'s `createNewOrder()`. opw-6077656 Forward-Port-Of: odoo/enterprise#112467
This update adds a required empty field to Milestone actions within Odoo. This change ensures the system's database remains stable during upgrades by adhering to a technical constraint that prevents conflicting action definitions. It’s a routine maintenance update to maintain data integrity.
Original PR description
Add an empty `python_method` field to the Milestones embedded actions. This is necessary to satisfy the `_check_only_one_action_defined` constraint during database upgrades. The `ir.embedded.actions` model enforces an XOR constraint between `action_id` and `python_method`, preventing both fields from being set simultaneously. Related PR: https://github.com/odoo/odoo/pull/254102 task-5993183 Forward-Port-Of: odoo/odoo#254106
This update fixes an issue where the animation intensity slider disappeared after switching animation modes on the website. The problem stemmed from a code change that consistently added a styling class, preventing the slider from reappearing until the same effect was selected again. This ensures a consistent and expected user experience when customizing website animations.
Original PR description
Steps to reproduce: 1. Go to the website and enter edit mode. 2. Click any text in the footer. 3. Change the animation mode from _none_ to _on appearance._ 4. Select the _zoom out_ effect; the intensity slider is visible. 5. Change the animation mode to _on scroll_. Issue: The animation intensity slider is no longer visible. It only reappears after reselecting the same effect. Reason: The `apply` method of `SetAnimationModeAction` always adds the "**o_anim_fade_in**" class, even when an animation effect is already selected. When switching the animation mode, this additional class prevents the intensity slider from being displayed. task-5896549 Forward-Port-Of: odoo/odoo#246921
A minor bug that caused a traceback when deleting a toggle list item has been resolved. The fix prevents an error when there isn't a subsequent item in the toggle list, ensuring the delete function works correctly. This improves the stability and reliability of the To-Do module.
Original PR description
Steps to Reproduce: - Go to To-Do → Create New - Create a toggle list - Type something in the title - Press the delete button Description of the issue: - A traceback occurs. Cause: - In `handleDeleteForwardTitleEnd`, there is a check to verify whether the toggle title’s next sibling matches the toggle selector. However, when there is no next sibling, calling `matches()` results in a traceback. Solution: - Only check `matches()` if the next sibling exists. task-6040479 Forward-Port-Of: odoo/odoo#257157 Forward-Port-Of: odoo/odoo#254557
This update fixes a misleading error message users saw when trying to add property fields to records without a parent (like categories). The message has been replaced with a clearer instruction: "A <parentFieldLabel> is needed to add property fields." This ensures users understand the requirement and can easily correct the issue.
Original PR description
Issue: ------------------------------------------ - When using property fields (e.g., products since 18.1 where categories are optional), users trying to add a property field without a parent…
Issue: ------------------------------------------ - When using property fields (e.g., products since 18.1 where categories are optional), users trying to add a property field without a parent document receive a generic warning: "You need edit access on the parent document to update these property fields". - This message is misleading and does not explain the actual dependency. How to reproduce: ------------------------------------------ 1. Create or edit a record (e.g., product) without setting its parent (e.g., category). 2. Try to add a property field. Cause of the issue: ------------------------------------------ - In `checkDefinitionWriteAccess`, when `definitionRecordId` is missing, the method returns `false`, triggering a generic access-rights warning. Solution: ------------------------------------------ - Added a check at the beginning of `onPropertyCreate` verify if `definitionRecordId` exists. - If missing, following error is raised using the parent field label: "You must set the '%s' field to create a property field." task-4589393 Forward-Port-Of: odoo/odoo#257875 Forward-Port-Of: odoo/odoo#205107
This update resolves an issue with the Windows IoT installer by correcting file paths and adjusting logging levels. The change ensures the installer functions correctly and provides more detailed information for troubleshooting, improving stability and reliability.
Original PR description
this commit fixes incorrect paths for the Windows IoT installer and updates log levels to INFO instead of WARNING.
This update corrects a visual issue where the display name within avatars appeared extremely narrow. The fix adjusts the width of the avatar component, ensuring names are displayed correctly and consistently. This improves the overall user experience and presentation of user profiles.
Original PR description
This commit fix the width of the displayName option of the Avatar component which was fixed to zero (bootstrap class 'w-0') Task-5122979 Forward-Port-Of: odoo/odoo#257869 Forward-Port-Of: odoo/odoo#257587
This update resolves an issue where the search panel displayed an error message ('Too many items to display') when dealing with large datasets. By adding a filter to limit the number of records shown, the search panel now correctly displays data without the error, improving the user experience. This ensures a smoother and more reliable search experience, especially with extensive data.
Original PR description
Have a search view with searchpanel having a filter or a category with a limit. For exemple in sale.order:
```
<searchpanel>
<field name="partner_id" icon="fa-filter" groupby="parent_id" limit="80" enable_counters="True"/>
</searchpanel>
```
On a database with a lot of data, in the category partner of search panel, there is an error 'Too many items to display.'.
Now in the search view, add a filter to restrict the number of records, and hence the number of partners in the search panel below the limit.
Before this commit, the error was still displayed. Now, it isn't, and the data are properly displayed.
Closes #257749
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#257908
Forward-Port-Of: odoo/odoo#257821This update fixes an issue where kiosk orders were automatically replaced with generic names like 'Table tracker X'. Now, customers can consistently use the custom order name they initially entered, ensuring accurate order tracking and a better customer experience. This change improves order clarity and reduces potential errors.
Original PR description
Before this commit, when a customer placed an order from a kiosk and provided a custom name, it was systematically overwritten by the backend with a generic "Table tracker X" or the tracking number. task-id: 6014281 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue with how dates and times were displayed, specifically regarding the inclusion of seconds. The change restores the original behavior of showing seconds when requested, and clarifies documentation to avoid confusion. This ensures consistent and accurate time formatting across Odoo.
Original PR description
In this [commit] the short format has been removed from misc methods because there was no more _short format fields in res.lang. But the short format was used to remove seconds from the res.lang format. Now, this behaviour has been restored with the new datetime format system and the unused format 'long' and 'full' has been removed from the doc string to avoid misunderstanding. The formatDateTime from the JS use the format from the res.lang too. So the same behaviour has been implemented there to be able to show seconds through the option 'showSeconds'. It's also fix the fact that this option didn't have any effect when the datetime was shown in numeric mode. [commit]: odoo@062b140#diff-61162ac65633a1c7b054fc83ce1813f1a7984e3169ff36021713ef441f62a208 opw-6030342 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255004
This update ensures that stock landed costs accurately reflect the currency rate used when the invoice was created, regardless of subsequent currency rate changes. Previously, the system used the current date's rate, leading to incorrect cost calculations. This fix updates the calculation to use the invoice's currency rate, improving financial accuracy.
Original PR description
**Issue**: Even if the currency rate is changed on the invoice, the today currency rate is used while generating stock landed cost. **Steps to reproduce**: - Enable two currencies (ex: Dollar and…
**Issue**: Even if the currency rate is changed on the invoice, the today currency rate is used while generating stock landed cost. **Steps to reproduce**: - Enable two currencies (ex: Dollar and Euro) - Enable Landed Costs on the settings - Create a service product - Create a bill for that product for 100 dollar and click the Landed Costs check box - Change the currency rating (ex: 1 USD = 0.5 euro) and confirm the bill - Click on "Create Landed Costs" -> The cost is not 200 **Cause**: While creating the landed cost: https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/stock_landed_costs/models/account_move.py#L21 it uses `_convert` from the currency: https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/stock_landed_costs/models/account_move.py#L35 which gets the `conversion_rate` defined on the currency, regardless whether `is_invoicing` is true: https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/odoo/addons/base/models/res_currency.py#L294 https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/account/models/account_move.py#L6350-L6351 **Solution** It is safe to replace the `convert` calls by the `currency_rate` of the `Account.move.line` since: https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/account/models/account_move_line.py#L735-L747 `currency_rate` will be set as `_get_conversion_rate` when not invoicing. Also add rounding since `_convert` is called with `round=True` by default. opw-6047031 Forward-Port-Of: odoo/odoo#256394