Daily updates from Odoo
Wednesday, April 8, 2026
18 changes · saas-18.3
Resolved issues and error corrections
This update fixes a technical issue preventing users from opening the 'Split Production' view within the MRP module. The problem stemmed from a missing product unit of measure, causing an error. This change ensures the view opens correctly and reliably for all users.
Original PR description
Steps to reproduce: - Install `mrp` module - Active debugger > Open view - Open `Split Production` view Traceback: `AssertionError: precision_rounding must be positive, got 0.0 (saas-18.3) ` `ValueError: Expected singleton: uom.uom() (19.0)` When trying to open the view directly, we do not receive the `product_uom_id` from the wizard in compute method `_compute_num_splits`, which leads to an error. sentry-7379431482
This update resolves a problem where tours weren't running correctly after editing views in Studio. The issue stemmed from a misleading module entry ('studio_customization') being included in the tour process. This fix filters out these invalid entries to ensure tours function reliably.
Original PR description
Step to reproduce: - start a fresh db, install studio and pos - using studio, edit any view (add or remove a field) - run any tour Observation: - we are not able to run any tour Traceback ``` File…
Step to reproduce:
- start a fresh db, install studio and pos
- using studio, edit any view (add or remove a field)
- run any tour
Observation:
- we are not able to run any tour Traceback
```
File "/home/odoo/odoo/codebase/odoo/18.0/odoo/addons/base/models/ir_qweb.py", line 2703, in _get_lazy_bundles_from_js
for fname in glob.iglob('**/static/src/**/*.js', root_dir=modroot, recursive=True):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/glob.py", line 46, in iglob
root_dir = os.fspath(root_dir)
^^^^^^^^^^^^^^^^^^^
TypeError: expected str, bytes or os.PathLike object, not bool
```
Cause:
- `_get_lazy_bundles_from_js` fetches module path for all installed module in addons
https://github.com/odoo/odoo/blob/05d0944a7640e196db989039140ae5ddb12152ac/odoo/addons/base/models/ir_qweb.py#L2686-L2697
- in case we have a view edited, we get the `studio_customization` as installled module, which doesn't have any path in addons. i.e. False
Fix:
- filter out such pseudo-modules from the list
Note: this is not a reported issue, i stumbled across it, hence made a fix
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#257806This 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 an issue where the breadcrumb navigation within the Barcode app was displaying incorrect or blank entries when moving between related records. Now, users can easily identify the originating document when navigating from the Barcode interface, improving usability and reducing confusion.
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#99165This update resolves a crash in the Gantt chart view that occurred when opening the chart on days with Daylight Saving Time transitions. The fix addresses an issue where incorrect time calculations led to a data error, causing the chart to malfunction. This ensures the Gantt chart 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
The search panel was displaying an error message when dealing with large datasets. This update adds a filter to limit the number of results shown, resolving the 'Too many items to display' error and ensuring a smoother user experience when searching for partners. This improves the usability of the search functionality.
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 ensures the category selector in Point of Sale displays consistently across all devices and user experiences. Previously, styling was inconsistent due to conditional application, now both product and category lists are always styled, improving the user interface and overall presentation.
Original PR description
Before this commit: ==================== Previously, the `category-list` class was conditionally applied based on `show_category_images`, which caused inconsistent styling and layout issues. After this commit: ======================= This commit ensures that both `product-list` and `category-list` classes are always present, providing consistent rendering of the category selector. Task-6092404 Forward-Port-Of: odoo/odoo#257251
This update resolves an issue where the invoice generation process would fail if a tax wasn't properly configured on an invoice line. The fix adds a check to prevent the system from attempting to calculate tax when none is defined, ensuring invoices are generated correctly. This improves invoice accuracy and prevents potential errors.
Original PR description
Issue: Attempting to generate facturae document for an invoice without a tax set on one or more line resulted in an IndexError. Solution: adding a check that prevents the function from trying to build tax values when there is no tax on the line. task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256819
This update corrects a flaw in how the digest KPI calculates user connections. Previously, it only considered a user's default company, leading to inaccurate metrics. Now, it correctly accounts for users working across multiple companies, providing a more reliable view of connected users.
Original PR description
**Problem:** Currently, the digest KPI for connected users checks the "company_id" field (as with all other models), but this field corresponds to "Default Company" on res.users, meaning a user can only be considered for one company when computing the digest KPI. This can cause misleading digest KPIs if users work in multiple companies, or mainly in a company that isn't their default company. **Solution:** Instead of always using the "company_id" field, we use the "company_ids" field if present on the model. opw-5404940 Forward-Port-Of: odoo/odoo#247806
This update addresses a situation where outdated, zero-value account entries were sometimes created, causing potential issues. The fix allows users to remove these entries, streamlining account management and improving data accuracy. This change ensures a cleaner and more efficient accounting process.
Original PR description
-added some conditions to allow the user to remove some zero move lines as they may have been created and do not have good information. task-4590580 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#256369 Forward-Port-Of: odoo/odoo#202272
This update ensures that the milestone list view, regardless of whether it's accessed from the Kanban or top bar, displays all relevant sales-related information like 'Quantity (%)'. Previously, the top bar action used a simplified view, leading to incomplete data. This change standardizes the view for a more complete and accurate representation of project milestones.
Original PR description
Steps to reproduce: - 1. Install the sale_project module. 2. Open a project and ensure it is billable. 3. Compare the view opened from the "Milestones" link in the Kanban view with the view opened from the "Milestones" top bar action. Issue: - The milestone list view opened from the top bar action does not display sales-related fields (e.g., "Quantity (%)"). Cause: - The Kanban view calls the `action_get_list_view` python method, which is overridden in sale_project to add a custom list view including sales-related fields. The top bar action was using a static XML action, bypassing this python logic. Fix: - Update the Milestones embedded actions to call the `action_get_list_view` python method instead of using a static XML action, ensuring top bar uses the same view as others. task-5993183
This update corrects a bug in the reconciliation process within Odoo. Previously, creating a reconciliation model without specifying a partner or account would default to a liquidity account, causing errors. Now, the system requires either a partner or account to be set, ensuring accurate reconciliation reporting.
Original PR description
**Steps to reproduce:** - Go to Accounting dashboard - From Bank journal, open Reconciliation Models list - Create a new reconciliation model - Add counterpart line without partner and account - Click on "Automate" **Issue:** The operation fails because the default account of the bank journal is used as there is no user and no account configured for the counterpart. Which results on several lines using a liquidity account (i.e. the cause of the error). Either a partner or an account should be set on a counterpart line. opw-6056737 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where event descriptions in Outlook Calendar downloads were displayed as raw HTML code instead of properly converted. The team added formatting to ensure HTML content is correctly translated to text for Outlook, improving the accuracy of event details when users download and view them.
Original PR description
### Steps to reproduce: - Download Events app. - Pick an event and click "Go to website". - Download the Outlook Calendar. ### Issue: - The HTML content within the event description is displayed as raw code and not converted properly - This happens because outlook takes the description as text and displays it in the ics file without conversion ### Solution: - Since we're working with *Outlook Calendar*, X Alt formatting was added to format HTML to text opw-5237027 Forward-Port-Of: odoo/odoo#246603
This update fixes an issue where the Libro Giornale (IT) PDF report would break its layout when an account with a long name was used. The change adds a CSS class to manage column width, preventing excessive expansion and ensuring a cleaner, more readable report. This improves the user experience for generating financial reports.
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 fixes an issue where payments wouldn't automatically update to 'paid' status after fully reconciling vendor bills, particularly when early payment discounts were involved. The change ensures payments accurately reflect the status of associated bills, improving financial reporting and reducing manual adjustments.
Original PR description
Currently, payments may remain in the 'in_process' state even when the associated vendor bills are fully paid. This occurs primarily when using early payment discounts (EPD) and journals without…
Currently, payments may remain in the 'in_process' state even when the associated vendor bills are fully paid. This occurs primarily when using early payment discounts (EPD) and journals without outstanding accounts. Steps to reproduce: - Create an early payment term. - Create a Vendor Bill with EPD and post it. - Register a payment for this bill (no outstanding account set on journal => no move created). - Create a bank transaction fully paying the bill. - Reconcile the transaction with the bill. Issue: Access the payment of the bill. The payment state remains 'in_process' instead of 'paid'. Analysis: The issue occurs because the reconciliation process misses the trigger to set the payment state to 'paid'. Specifically: - The payment amount does not match the bill total due to the EPD. - The payment compute method does not monitor 'reconciled_bill_ids', causing it to ignore the status of linked vendor bills. This change adds 'reconciled_bill_ids' to the compute dependencies and ensures that if a payment is reconciled with any moves (invoices or bills), their payment_state is considered to determine the final state of the payment. Test in enterprise: https://github.com/odoo/enterprise/pull/112398 opw-5881976
This update resolves a problem where EPD bill payments weren't correctly marked as 'paid' in the accounting system. The fix ensures that payments are accurately reflected after reconciliation, improving the reliability of financial reporting. This was triggered by a specific test scenario involving early payment terms and bank transactions.
Original PR description
Steps to reproduce: - Create an early payment term. - Create a Vendor Bill with EPD and post it. - Register a payment for this bill (no outstanding account set on journal => no move created). - Create a bank transaction fully paying the bill. - Reconcile the transaction with the bill. Issue: Access the payment of the bill. The payment state remains 'in_process' instead of 'paid'. Fix in community: https://github.com/odoo/odoo/pull/256486 opw-5881976
This fix resolves an issue where a save button would fail when using the liquidity account for bank reconciliation. The change prevents automatic reconciliation attempts with this account, avoiding a frustrating popup and ensuring data integrity. This improves the usability of the bank reconciliation process.
Original PR description
# How to reproduce - Create a new Journal - Go to the Configuration of the Journal > Outgoing Payments > Set the Outstanding Payment accounts for the Manual payment Payment Method to the liquidity…
# How to reproduce - Create a new Journal - Go to the Configuration of the Journal > Outgoing Payments > Set the Outstanding Payment accounts for the Manual payment Payment Method to the liquidity account - Go to the Transactions of the Journal - Add a new Transaction for partner X and amount Y - Add a second Transaction also for partner X and amount Y # The issue A popup appears that can never be saved # Cause When we click on "Add & New" or "Add & Close", we run the `validate()` function : https://github.com/odoo/enterprise/blob/9abb50b9b29e01897b4fb90ae228beecbdfcd5af/account_accountant/static/src/components/bank_reconciliation/quick_create/quick_create.xml#L14-L16 Which tries to do a model save, but it fails so it show the Form dialog : https://github.com/odoo/odoo/blob/6e77d840a2876e45544b21a911be05b2f32b8afb/addons/web/static/src/views/kanban/kanban_record_quick_create.js#L159-L163 The save fails because : This commit (https://github.com/odoo/enterprise/commit/e2b3439dcda26f84b9a290c8d5fb819dd3250825) changed the the logic behind auto-reconcilation with an outstanding account. When there is an outstanding account, we try to auto-reconcile the bank statement with that account and succesfully do so : https://github.com/odoo/enterprise/blob/e2b3439dcda26f84b9a290c8d5fb819dd3250825/account_accountant/models/account_bank_statement.py#L381-L385 https://github.com/odoo/enterprise/blob/e2b3439dcda26f84b9a290c8d5fb819dd3250825/account_accountant/models/account_bank_statement.py#L245 But this should not happen when the outstanding account is the liquidity account, because it will end up throwing an error when the amount is matched more than once: https://github.com/odoo/odoo/blob/6e77d840a2876e45544b21a911be05b2f32b8afb/addons/account/models/account_bank_statement_line.py#L727-L737 opw-6063654
This update fixes a potential data inconsistency issue. Previously, users could erase a lot number from a Purchase Order-related Move, leading to errors. Now, the system prevents this action when the Move is linked to lot valuation, ensuring accurate inventory tracking and preventing data lockups.
Original PR description
When we erase a sn/lot on a MO for a product that is tracked by lot, we will be deadlocked. ### Steps to reproduce: * Create a product tracked by lot and lot_valuated * Create a BoM for this product…
When we erase a sn/lot on a MO for a product that is tracked by lot, we will be deadlocked. ### Steps to reproduce: * Create a product tracked by lot and lot_valuated * Create a BoM for this product * Create a MO for this product * Confirm and Produce all * erase the lot and save -> the MO is deadlock, it's not possible to modify the lot number, nor it's possible to unbuild. ### Current behavior: A user is able to erase a lot/SN from a MO of a lot_valuated product. ### Expected behavior: It should not be possible to erase a lot/SN form a MO of a lot_valuated product. ### Observation: When the MO is done, its valuation will be calculated which in our case, it means, we have to have a lot number. When trying to add a lot/SN of a MO where it has been erased, we will remove the quantities from the previous lot, but in our case, since we don't have one, it will trigger the user error. https://github.com/odoo/odoo/commit/33e192de30526ea7fe320bcaa7a16dac8108feff This error is not triggered when removing the SN/lot because when we remove the value, it will be update to False which means it will skip _update_svl_quantity(): https://github.com/odoo/odoo/blob/109f829c2b461b14167e9227e42d096d4410a3b3/addons/stock_account/models/stock_move_line.py#L35-L36 https://github.com/odoo/odoo/blob/109f829c2b461b14167e9227e42d096d4410a3b3/addons/stock_account/models/stock_move_line.py#L62-L65 This use case is also protected when creating a product tracked by lot but not lot_valuated: https://github.com/odoo/odoo/commit/4963103e5587d36364b8df84d0b3407a1977efdf opw-6039885 Forward-Port-Of: odoo/odoo#255098