Daily updates from Odoo
Tuesday, January 6, 2026
26 changes · saas-18.3
Resolved issues and error corrections
This update fixes an issue where the DIN5008 invoice report didn't include Incoterm information. The fix adds the necessary logic to display the Incoterm code and location, ensuring compliance with DIN5008 reporting standards. This improves invoice accuracy for international transactions.
Original PR description
**Steps to reproduce:** 1. Install the modules account and l10n_din5008. 2. Go to Settings and set DIN5008 as the default invoice report template. 3. Navigate to Configuration → Settings and set a default Incoterm. 4. Create a new customer invoice. 5. Print the DIN5008 Invoice Report. **Issue:** The DIN5008 invoice report did not display the Incoterms, while other invoice layouts printed them correctly. **Cause:** This was due to missing logic in l10n_din5008 report to include Incoterm data. Confirmed with TSB that the DIN5008 layout should display Incoterms. **Fix:** This commit adds the Incoterm information to the DIN5008 template data: - Always include the Incoterm code - If an Incoterm location is set, display it as `CODE - LOCATION` **opw-5349267** Forward-Port-Of: odoo/odoo#240688 Forward-Port-Of: odoo/odoo#238682
This update corrects a bug that caused a 'singleton' error when marking Field Service tasks as complete. The issue stemmed from how the system linked timesheets to sale order lines, specifically when multiple identical sale order lines existed. The fix ensures the timesheet always correctly links to the first applicable sale order line, maintaining consistent functionality.
Original PR description
Steps to reproduce: ------------------------------ 1. Install `industry_fsm_sale` module. 2. Open the settings of the field-service project and open the invoicing page 3. Add one employee on the…
Steps to reproduce:
------------------------------
1. Install `industry_fsm_sale` module.
2. Open the settings of the field-service project and open the invoicing page
3. Add one employee on the Invoicing page and create a new product with a Unit Price
4. On the product form, set the same value in the Sales Price field
5. Create a Sale Order with two sale order lines that use the same product and the same quantity
6. In Field Service create a Task for the same customer and set one of the sale order lines in the Sales Order Item field.
7. Create one timesheet for the task using the same employee added in the Invoicing page. Save the timesheet and click Mark as done
Observation:
------------------------------
A singleton traceback occurs when marking the task done:
```
raise ValueError('Expected singleton: %s' % record)
ValueError: Expected singleton: sale.order.line(62, 63)
```
Issue:
------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/31663b503c75dc2a83cc9585280df02f4d704e89/industry_fsm_sale/models/project_task.py#L507-L511
According to our scenario, we will get two SOL for the same product `id` and `price_unit` Which on further used to link the SOL to timesheet. Following code assumes the single SOL and gives singleton error https://github.com/odoo/enterprise/blob/31663b503c75dc2a83cc9585280df02f4d704e89/industry_fsm_sale/models/project_task.py#L553-L554
Solution:
------------------------------
When building the `sols_by_product_and_price_dict` using the key
(product_id, price_unit), When multiple sale order lines exist for the same key,
only keep the one that comes first in the sequence to maintain the consistency.
as in following code:
https://github.com/odoo/enterprise/blob/a7b79f79d90a37fb2458f05bcf439c109f1d756f/industry_fsm_sale/models/account_analytic_line.py#L15-L20
This ensures the timesheet always links to the first applicable sale
order line, matching existing behavior.
opw-5373018
Forward-Port-Of: odoo/enterprise#101774This update resolves an issue where the search panel in the hierarchy view was getting cut off when navigating deep within the organization structure. The fix ensures the hierarchy content scrolls correctly, maintaining the position of the search panel and control panel. This improves the user experience for navigating complex organizational data.
Original PR description
Issue: The hierarchy renderer was missing the standard `.o_renderer` class, so global layout and scrolling rules were not applied. Fix: Add `.o_renderer` on the hierarchy renderer root a to correct scrollable container. Impact: Restores expected scrolling behavior in hierarchy view Task: 5326054 Forward-Port-Of: odoo/odoo#236823
This update clarifies the documentation for a specific function in the Odoo account module. Previously, it wasn't clear that this function didn't create new records but instead updated existing ones. This change ensures developers understand the function's behavior, preventing potential confusion and errors.
Original PR description
I have adding a docs for force_create that I have added in a previous task as it was not clear for some colleagues that it do not create but still updates the available records 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#241995
This update fixes a visual issue on the user profile page where course tags were being cut off. The change adjusts the layout to ensure all tags are fully visible, maintaining a consistent and professional appearance. This improvement addresses a minor aesthetic concern and enhances the user experience.
Original PR description
In the website profile page, the course tags are slightly cut on the bottom. This commit adapts the block size to fit the entire tag. Note that the combo of fixed height / hidden overflow is actually intended to only show a single line of tags and not all of them, to avoid having a variable course card total height. Task-5457464 Forward-Port-Of: odoo/odoo#241897
This update resolves a bug that prevented users from assigning statements to multiple bank lines within the Bank Reconciliation widget. The fix ensures the system handles multiple selections correctly, preventing a common error. This improves the usability of a key accounting function.
Original PR description
An error occurs when a user tries to assign a Statement to multiple selected lines in the Bank Statement list view. Steps to reproduce: 1) Install Accounting with demo data. 2) Open the Bank…
An error occurs when a user tries to assign a Statement to multiple selected lines in the Bank Statement list view. Steps to reproduce: 1) Install Accounting with demo data. 2) Open the Bank Reconciliation widget. 3) Switch to the List view. 4) Select multiple statement lines. 5) Click on the 'Statement' field to assign a statement to the selected lines. Error: `TypeError: Cannot read properties of undefined (reading 'root')` Root Cause: The `BankRecMany2OneMultiID` component attempts to access `active_ids` through `this.env.model.root` (see [1]). During re-rendering, the value of `this.env.model` becomes undefined, which leads to the error. Fix: Add a check for the existence of `this.env.model` in the getter to avoid accessing `root` on an undefined model. [1]- https://github.com/odoo/enterprise/blob/c194bee0e48db407288e3c402e71840af299568d/account_accountant/static/src/components/bank_reconciliation/list_view/list_view_many2one_multi_edit.js#L14 opw-5403564
This update fixes a reporting error in the French P&L statements. The 'owner remuneration' account (644) was incorrectly categorized as 'tax and duties.' This change ensures accurate reporting of wages and salaries for French businesses, aligning with accounting standards.
Original PR description
Account '644 owner remuneration' was in the 'tax and duties' category in the french P&L but it belongs to the 'wages and salaries' category task-5446018 Forward-Port-Of: odoo/enterprise#103214 Forward-Port-Of: odoo/enterprise#103061
This update resolves an issue where color fields within editable lists weren't saving changes when using the 'bottom' editing mode. Previously, edits to color fields were lost. Now, color field changes will correctly save when the list is in 'bottom' mode, ensuring data integrity and a consistent user experience.
Original PR description
This commit fixes the issue where editing a field with widget="color" does not save it when the list is in editable="bottom" mode. project.task~5262582 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#238644
This update fixes a limitation in generating payslips for previous years. Now, employee data can be retroactively updated, allowing for accurate reporting of payroll snapshots across all years. This ensures compliance and provides a complete historical record of employee compensation.
Original PR description
Currently employee data only updates current year snapshots, which can be an issue when generating payslips for previous years, in this PR we enable retroactive updates by changing the mecanism. The new mecanism updates snapshots of the payslip years, making a reference date usage possible. Forward-Port-Of: odoo/enterprise#103147
This update clarifies delivery slip reports by explicitly labeling the delivery address as 'Delivery Address' and simplifying customer information labels. These changes reduce potential errors and improve the accuracy of delivery details, leading to smoother operations.
Original PR description
To resolve ambiguities and improve operational efficiency: 1. The delivery address is explicitly labeled 'Delivery Address'. Ensuring no doubt about the final destination. 2. The label for the customer's primary information has been updated from 'Customer Address' to simply Customer, which prevents operators from mistaking it for the delivery point. Backport of https://github.com/odoo/odoo/pull/220019 Task: 3379926 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#241988
This update fixes an issue where Odoo incorrectly processed partner names with only one word, resulting in an empty first name field. Now, single-word names are properly assigned to the first name, ensuring accurate data entry and reporting. This improves the reliability of payment processing and customer information.
Original PR description
Description of the issue/feature this PR addresses: The name splitting logic fails when the partner name contains only one word, resulting in an empty first name. Current behavior before PR: Splitting a single-word name returns an empty first name and assigns the word to the last name. Desired behavior after PR is merged: A single-word name is correctly assigned to the first name field, leaving the last name empty. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241926
This update fixes an issue where delivery slips were printed with move lines in the incorrect order. The change ensures that move lines are printed in the same order as their associated stock moves, resulting in accurate and consistent delivery slip reports. This improves the reliability of our shipping documentation.
Original PR description
**Steps to reproduce:** - Add 2 products in a delivery - Add the second's product move lines before the first one. - Validate and print delivery slip **Issue:** We iterate the `move_line_ids` directly which means if we have a new move line for a move with a lower id, it will push the product to the end of the delivery slip. **Example:** If we have `stock.move(1,)` with `stock.move_line(52,)` and `stock.move(2,)` with `stock.move_line(51,)`. `stock.move_line(51,)` will be printed first, which introduces a change in the order of the delivery slip. **Fix:** Iterate on `move_ids` and access `move_line_ids` through it, to print `move_lines_ids` in the same order of the `move_id`. Task: 4570203 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213400
This update fixes a bug preventing users from registering for event slots from pages other than the event registration page. Previously, the 'register' button only displayed available slots on the registration page. Now, users can register for slots directly from event pages like talk schedules, expanding event accessibility and convenience.
Original PR description
* = event, event_booth, event_exhibitor, event_track, event_track_quiz The "register" button displays open slots only on the registration page of an event, and not on the other pages of this one. This PR fixes this issue by making available the open slots from the event.event model for the modal_slot_registration template as an instance of this one is always present in the context of those pages. Reproduce: Create an event with the "Multiple Slots" option checked and link it to a slot of tomorrow. The "register" button will display the slot on the registration page of the event but not on the page of the talks. Task-5083175
This update automatically updates the IoT box's database version whenever a new database release is available. Previously, manual restarts were required, which is now eliminated, improving system stability and reducing manual intervention. This ensures the IoT boxes always use the latest database, enhancing performance and reliability.
Original PR description
Before this commit, when the DB was upgraded to a new version, the IoT box had to be manually restarted so that it would checkout and align with the new version. After this commit, we check the DB branch whenever we receive a `bundle_changed` message on the websocket. If it has changed then the IoT will restart and checkout the new version. task-5463520 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where exporting data from the MPS (Material Requirements Planning) view would crash due to incorrect field selection. A recent change introduced a new model, 'mrp.production.schedule', which was causing conflicts during the export process. Now, the export function correctly retrieves data from the intended 'mrp.product.forecast' model.
Original PR description
Steps to reproduce: - Go to MPS - Select one or more records - Click on Action > Export - Search and expand "Forecasted quantity at date" - Select "Forecasted quantity at date/Minimum to Replenish" - Export Before: A traceback is raised with the following error: "ValueError: Invalid field 'min_to_replenish_qty' on 'mrp.product.forecast'" This is caused by the model being overwritten by "mrp.production.schedule". The regression was introduced by commit ac52882, which added a default model "mrp.production.schedule". After: The export works correctly with sub fields. https://github.com/odoo/enterprise/commit/ac52882891a9ede6a5b008ac39fc62b82b7bf813 opw-5406704 Forward-Port-Of: odoo/enterprise#103097
This update resolves a technical issue related to the l10n_gt_edi module, specifically adding a 'neutralization' process. This ensures that database copies created for support investigations are isolated and won't unintentionally impact the live production system or customer data. It allows our support team to safely examine duplicate databases.
Original PR description
This commit adds the missing neutralization necessary for the l10n_gt_edi module The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. Forward-Port-Of: odoo/enterprise#102695
This update adds a critical neutralization process for the l10n_tw_edi_ecpay module, allowing our support team to safely examine database copies without impacting the live production system or customer data. This ensures secure and efficient troubleshooting of issues related to Taiwan's electronic invoice requirements.
Original PR description
This commit adds the missing neutralization necessary for the l10n_tw_edi_ecpay module introduced in [1] The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. [1] https://github.com/odoo/odoo/pull/223132 Forward-Port-Of: odoo/odoo#240975
This update fixes an issue where changes to a product's Bill of Materials (BOM) didn't properly remove associated raw materials from the manufacturing order. The fix ensures that move raw materials are correctly deleted when a BOM is updated, preventing inventory discrepancies. This improves the accuracy of production planning.
Original PR description
### Steps to reproduce: - Create a bom for a product with 2 component lines: - 1 x COMP1 - 1 x COMP2 - Create an MO for your product (do not confirm it) - Delete the second bom line of the bom - On…
### Steps to reproduce:
- Create a bom for a product with 2 component lines:
- 1 x COMP1
- 1 x COMP2
- Create an MO for your product (do not confirm it)
- Delete the second bom line of the bom
- On the draft MO, click on `update bom`
#### > This automatically modifies the `move_raws` of the MO but the un-linked move raws were neither deleted nor cancelled as shown by the move analysis
### Cause of the issue:
Clicking on `update bom` will launch a call of the `action_update_bom` which will itself call the `_link_bom` to update the record: https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/mrp_plm/models/mrp_production.py#L73-L80 https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L2406-L2418 Now the issue is that the `bom_id` is set to `False` before the value of the `move_raw_ids` and `workorder_ids` are stored to be unlinked in the `moves_to_unlink` and `workorders_to_unlink` variable. Now, the issue is that the `bom_id` is a dependency of both compute methods: https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L745-L746 https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L563-L564 in particular, `moves_to_unlink` will always be an empty record set and the value of the `workorders_to_unlink` might be unreliable.
opw-5243203
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#239654This update resolves an issue preventing customers in French territories like La Réunion from using Stripe Connect. The change adjusts how the system identifies a company's location to ensure Stripe Connect is correctly enabled, aligning with Stripe's availability policies. This expands payment options for users in these regions.
Original PR description
## Versions 17.0+ ## Issue Customers located in French territories (e.g. La Réunion) can't use Stripe Connect. ## Steps to reproduce *Ensure Stripe payment provider is installed* - From the Settings'…
## Versions 17.0+ ## Issue Customers located in French territories (e.g. La Réunion) can't use Stripe Connect. ## Steps to reproduce *Ensure Stripe payment provider is installed* - From the Settings' app, access your company's data: - Change your company's country for "Réunion". - Go to Payment Providers and open Stripe: - Try to enable Stripe via Stripe Connect; - A message tells you your country is not supported by Stripe. ## Cause Commit 94b37a3f51089621a2f12360c7a13f610b24ba3a introduced territories mapping by adding the method `_stripe_get_country()`, mapping the company country (`self.company_id.country_id.code`) to enable Stripe under the parent country as specified in their documentation (https://support.stripe.com/questions/stripe-availability-for-outlying-territories-of-supported-countries). This fix was first applied in 16.0 and forwarded but didn't check that commit de782a680de8e5a2d7c89b982c485ca29da34b3a, from saas-16.2, added another condition on (`self.env.company.country_id.code`) on the Stripe Connect flow. opw-5421185 Forward-Port-Of: odoo/odoo#241269
This update resolves an issue where applying full amounts to bank statement lines (like invoices and payments) was incorrectly triggering tax calculations. This change ensures that tax calculations are only applied to lines that actually require them, improving the accuracy of financial reporting. It addresses a bug introduced in a previous commit.
Original PR description
Since this commit: https://github.com/odoo/enterprise/commit/5893005187fd67613baaae38e58e126dc9e28544 It could happens that on lines that come from an invoice or a payment (so lines with reconciled_lines_ids. Applying the full amount would trigger the edit_tax_line function which shouldn't be the case since those lines cannot have tax set on them. no task id
This update fixes a bug in the Point of Sale (POS) system where variant names weren't correctly displayed when items were added to combo orders. The change ensures that variant names are accurately shown on the order, improving the user experience and accuracy of sales transactions. This resolves an issue reported by users.
Original PR description
In POS, if in a combo, one of option has instantly created variant it will not show the variant name in the order Steps to reproduce: ------------------- * Create a product with instantly generated…
In POS, if in a combo, one of option has instantly created variant it will not show the variant name in the order Steps to reproduce: ------------------- * Create a product with instantly generated variants * Create a combo choice and add one of his variants * Create a combo product and add the combo * Open an store that sells this combo * Select the combo and choose the product with variant and confirm the selection Issue : On the left size in the order the variant name will not appear. Observation: ------------ When it tries to construct the name of the product it need the attribute_value_ids: https://github.com/odoo/odoo/blob/35c77b89e4c0db035ad25fef9a34be6ef74db7b5/addons/point_of_sale/static/src/utils.js#L36-L39 Since in our case the product is a variant "always" the attribute are not inside attribute_value_ids, it will not have them : https://github.com/odoo/odoo/blob/942b7a21d7e0eb15133f4af1b47e68f48dec70c7/addons/point_of_sale/static/src/app/models/utils/compute_combo_items.js#L31-L33 opw-5037355
This update fixes a bug that prevented users from creating helpdesk tickets when helpdesk teams included members from different companies. The change prevents unnecessary data fetching in sudo, ensuring users only access resources within their own company. This resolves an access error and improves ticket creation functionality.
Original PR description
Before this commit, the `resource_ids` field in `res.users` model was fetched in sudo due to the `resource_calendar_id` related field in `res.users` and so the user will get the resources of members…
Before this commit, the `resource_ids` field in `res.users` model was fetched in sudo due to the `resource_calendar_id` related field in `res.users` and so the user will get the resources of members in a helpdesk team from another company than the current one(s). The problem is since the current user does not have access to those resources due to the multi company rule, he will get a traceback when he will try to create a ticket from that helpdesk team if the assignement method is ramdom and a user with resource exists in another company. This commit makes sure the resource_ids field in res.users is not fetched in sudo to correctly determine which user to set to the ticket when the current user tries to create a ticket. Steps to reproduce the issue: ---------------------------- 1. Install helpdesk module 2. Create a new company B 3. Create a new user with helpdesk user access right (or use Marc demo) and give the company B to that user 4. Select that new company created in step and go to helpdesk app. 5. Create an helpdesk team with auto-assignment set to "randomly" and set admin user as members in that helpdesk team 6. log in as the user created in step 3 7. make usre the company selected is the one created in step 2 8. create a ticket in the helpdesk team created in step 5 Expected behavior: ----------------- The ticket should be created without any issue. Actual behavior: --------------- An access error is raised because the current user does not have access to the resource of admin user since it is not in the same company than the current one. opw-5223717 Forward-Port-Of: odoo/enterprise#102910 Forward-Port-Of: odoo/enterprise#102859
This update adjusts the timing for maintaining real-time video connections (RTC) in Odoo. Previously, a missed ping would immediately drop the connection, but now a longer timeframe is used. This prevents disconnections when the Odoo server is temporarily slow, ensuring smoother video calls.
Original PR description
Before this commit, the ping to keep rtc sessions alive was done every 30 seconds and had a 1 minute timeframe to successfully ping, which meant that missing a single ping would drop the rtc session. This commit increases the timeframe to 1 minutes and 15 seconds so that one ping can be missed. This can help preventing disconnections when the Odoo server is slow, as calls can work fine without a stable connection to the odoo server (since P2P and SFU connections are independent from Odoo once the connections are initialized). task-5177246 Forward-Port-Of: odoo/odoo#234553
This update resolves an issue where requesters didn't see signed documents after the signing process. The fix ensures that both the requester and signer automatically receive 'view' access rights to the signed document, preventing access restrictions and improving document visibility.
Original PR description
To reproduce: ============= - as a User U with Admin rights on Documents (not Sys Admin) - create a folder at the root of the company - create a Sign Request template using this folder as signed document folder - send the Sign Request to another user O and sign it with that user O - go to Documents app with user U and check the folder where the signed document should be - the signed document is not there Problem: ======== when creating signed documents, the access rights for the requester are not set, causing the requester to not see the signed document Solution: ========= give `view` access right on signed documents to both the requester and the signer if they don't already have `edit` access right on it or ownership opw-[5087233](https://www.odoo.com/web#id=5087233&view_type=form&model=project.task) Forward-Port-Of: odoo/enterprise#99307 Forward-Port-Of: odoo/enterprise#97132
This update resolves a memory issue that occurred when generating invoices for subscriptions, particularly with large databases. By optimizing how the system retrieves data, the change significantly reduces memory consumption, preventing errors and improving the stability of the automated invoicing process. The fix resulted in a 1.7GB reduction in memory usage.
Original PR description
A MemoryError can be thrown when running the scheduled action `_cron_recurring_create_invoice` on large databases. When there are lots of subscriptions, sale.orders and account.move.lines, the…
A MemoryError can be thrown when running the scheduled action `_cron_recurring_create_invoice` on large databases. When there are lots of subscriptions, sale.orders and account.move.lines, the compute method overwrite `_get_invoiced` in the sale_subscription module can consume a lot of memory. The issue is mostly coming from the search on account.move.line. In case a lot of account.move.lines have a subscription_id, the search to get `all_subscription_ids` is going to return a lot of records. Then, accessing any field on this recordset will prefetch all the prefetchable fields, leading to a MemoryError. This commit fixes that by manually fetching the fields we need on account_move_line. Since `subscription_move_lines` is not used anywhere else and `move_by_origin` only contains ids, the number of queries stays the same while the memory consumption plummets. #### Benchmark In a database with 236 000 account.move.line with a non-null subscription_id, running the schedule action with 5 subscriptions to invoice consumes at least 1.7GB (MemoryError raised). After this commit it consumes 191MB. <img width="1918" height="943" alt="sale_subscription_before" src="https://github.com/user-attachments/assets/e868921f-e691-47c3-8474-edb9a1d22d0b" /> <img width="1920" height="949" alt="sale_subscription_after" src="https://github.com/user-attachments/assets/78e9fc31-4c5f-4369-8bd0-494ca2c693fd" /> Forward-Port-Of: odoo/enterprise#102364
This update fixes a visual inconsistency in the Point of Sale system. Previously, when searching for partners with wildcard characters, the system would display a 'found' count but not show the results in the list. This change ensures that the search bar correctly interprets wildcard patterns, aligning with the backend database search and providing a seamless user experience.
Original PR description
When the client typed `a%t%` into the search bar and pressed 'Enter', we load the partners from the backend using `getNewPartners` and showed a dialog "x partners found", however, we never show those results in the partner list since the search bar didn't support the wildcard ilike pattern. This commit adds support for searching wildcard patterns, to match the SQL behavior more or less. Clients now won't be confused by seeing "x partners loaded" and at the same time seeing an empty list. opw-5395340 Forward-Port-Of: odoo/odoo#242140 Forward-Port-Of: odoo/odoo#240541