Daily updates from Odoo
Thursday, April 17, 2025
26 changes
10 changes
Enhancements to existing features
Odoo can now automatically find IoT Boxes available on the local network, reducing manual setup work. The connection screens and guided steps were also improved so users can add a new IoT Box more confidently and with fewer errors.
Original PR description
This PR adds the possibility to auto-detect the IoT Boxes registered on your local network. It also improves the UI and the wizards the user sees when trying to connect a new IoT Box to the database Related odoo PR: odoo/odoo#204629 Related internal PR: https://github.com/odoo/internal/pull/3462 Related upgrade PR: https://github.com/odoo/upgrade/pull/7533 task-4687795
Appointments can now be managed in a Kanban-style board, making schedules easier to scan and organize at a glance. The appointment form was also refined to improve day-to-day usability for teams handling bookings.
Original PR description
In this commit: === - Added a Kanban view for appointments. - Improved the form view for better usability. Task-4640315
Bank statement import now correctly handles CODA files that contain statements for more than one bank account. This helps businesses using Belgian CODA, Codabox, CAMT, OFX, QIF, or Japanese Zengin imports avoid missed or misassigned bank statement data when one file covers multiple accounts.
Original PR description
This commit implements the correct handling of coda files with statements for multiple accounts. Task: 4502185
The field service sales and stock product catalog has been aligned with recent product catalog interface updates, keeping the workflow consistent for users. The catalog now also shows the correct currency even before a sales order is created, reducing confusion during early product selection.
Original PR description
This commit modifies the product catalog UI tests and code in `industry_fsm_*` to match UI changes in community PR changes in the Product Catalog, as introduced in the Community PR. Also, ensure that a currency shows in catalog even when no SO has been created yet. TaskId: 4610850
This update makes appointment management clearer by highlighting no-show appointments, improving resource links, and preventing timezone-related errors. It also simplifies the sales commission team dashboard to match the updated CRM dashboard experience.
Original PR description
- Adapt CRM overrides to changes in the dashboard view and tweak some UI elements for appointment. Many fields and some views were removed in that process. - Add a fallback for the timezone of appointment types, which avoids some tracebacks if the user somehow has no timezone. - Cross through "no show" appointments in the gantt view to make it more obvious at a glance that this was entirely not attended. - Allow clicking resources, remove the "avatar" widget for them in the appointment view as it doesn't bring anything and replace with a regular tag widget which is clickable and allows to easily manage them. task-4568114
Emails sent to the Documents app without attachments are now automatically converted into document files. This removes the need for users to manually print, save, or upload email-only invoices and receipts, making document capture faster and simpler.
Original PR description
For instance, when receiving invoices from digital services, you sometimes just receive your invoice/receipt as an email without any attachment. Currently you'd have to open the email, print/save the email as PDF and either upload it manually to the Documents app, or attach it to an email sent to a Documents alias. This commits converts emails without attachments sent to Documents into documents. task-4539553
WhatsApp conversation titles in Discuss now show the contact's name instead of only their phone number. This makes chats easier to recognize and also avoids an error when a WhatsApp channel is created without a linked message.
This update fixes a crash that could occur when receiving recruitment-related VoIP calls. It also simplifies and renames shared call display elements so call screens are easier to maintain and use consistently across VoIP views.
Original PR description
## [FIX] voip_hr_recruitment: traceback on incoming call The patch of CallInvitation components was not done correctly and failed to redefine the original list of child components. As a result, Owl couldn't find the definitions of ActionButton and UserInfo and would crash when trying to render the CallInvitation. ## [IMP] voip: merge CallView into UserInfo CallView was introduced to avoid code duplication between CallInvitation, InCallView, and CallSummary, which have some data in common. The concept of CallView is no longer useful since the part that is shared is fully encompassed by the UserInfo component that was added later. This commit merges the two to keep only one component. ## [MOV] voip: rename UserInfo to ContactInfo ContactInfo is believed to be more in line with the terminology in use in VoIP, and less confusing than "UserInfo" since "user" in the context of Odoo refers to another concept entirely.
Resolved issues and error corrections
The Knowledge search bar now uses the correct module-specific rules when looking for published articles. This prevents search errors and lets portal users find relevant child articles after moving between published and shared content.
Original PR description
This commit fixes an issue with the KnowledgeSidebar Component which provides a domain to search for a specific article. The issue is that it used the field `website_published` inside the knowledge module. Which never defines this field on the model. This error was introduced by https://github.com/odoo/enterprise/pull/77597. This is supposed to be the job of the website_knowledge module, which implements the field on the model. Another issue is when a portal user access a published article and switches to an article shared with them, he can not search for articles that are descendants of the original published article. This is fixed by registering the original root id (which may be a published article), and searching published articles that are children of that specific root. task-4734644
Code cleanup and technical improvements
The Knowledge app’s permission panel and options menu were redesigned to load more responsively and behave more consistently. Users get clearer permission controls, more predictable behavior when leaving private articles, and improved stability backed by new tests.
Original PR description
Make Knowledge feel a little bit more responsive by deferring the loading of some fields. For both the PermissionPanel and the options panel we remove as much as possible the usage of separate RPC…
Make Knowledge feel a little bit more responsive by deferring the loading of some fields. For both the PermissionPanel and the options panel we remove as much as possible the usage of separate RPC calls. This change made us rely more on the record Object populated by the DB values. Tests were also implemented for each Component to test their behavior and ensure stability and robustness for the future. There's also been some minor improvements to the behavior done. #### PermissionPanel * no more check that "based on" articles are accessible by the user (more coherent with the topbar "hierarchy"). * when the owner of a private article leaves the article, the article is sent to the trash instead of archiving it (as suggested by the confirmation dialog). * portal users with permission "none" are not hidden anymore. * the permission selectors are now dropdowns (more flexible than selectors and has a style that is consistent with the app). * the "remove member" button has been replaced by an option in the permission dropdown. #### Member rights escalation * Allow a member to remove itself from an article if its member permission is the same as the inherited_permission. i.e. a read access member on a readonly article can remove itself: - this allows an action symmetry (a user can join a readonly article and also remove itself as a member to see/hide it in the sidebar) #### OptionsDropdown * The bootstrap dropdown has been replaced by a separate Component that uses the Dropdown class provided by the framework. * The bus system for toggling each panel has been replaced by a reactive object in the environment provided by the Controller. This doesn't rely on d-none class on the parent any more to hide/show each panel. Task-4273102
16 changes
Enhancements to existing features
Invoice batch sending now shows more accurate counts based on the delivery methods that can actually be used for each invoice. Peppol invoice handling is also more reliable, including better behavior when invoice formats are missing and clearer treatment of blocking send errors.
Original PR description
### [IMP] account: fix the summary of account.move.send.batch.wizard *: account_peppol, snailmail_account The summary was displaying wrong numbers of invoices. Indeed, it was computed on default…
### [IMP] account: fix the summary of account.move.send.batch.wizard *: account_peppol, snailmail_account The summary was displaying wrong numbers of invoices. Indeed, it was computed on default methods, instead of methods that are applicable to the move. For example, if a move was not possible to send through Peppol because the partner is not registered on the network, it was still displayed in the summary of the batch sending (then not used when the async processing happened). We also always put email as a fallback, even if no email is set, since it can be added through the wizard. task-no (review with TSB/PMAX) ---------------------------- ### [FIX] account_peppol: Remove 'skipped' state of Peppol moves This state doesn't really make sense. It only happens when there is an error while generating the XML file to send, which can be considered as a blocking error. task-no ---------------------------- ### [FIX] account_peppol: fix batch send of Peppol invoices when no format set In previous commit[1], we set the BIS3 format on invoices that were meant to be sent trough Peppol, even if no invoice_edi_format was set on the Partner. This commit fixes some cases when sending multiple invoices with no invoice_edi_format but Peppol as default sending method ended up not being sent. [1]: https://github.com/odoo/odoo/commit/84a0b81a258262e3bb9dbaa9c9f37796303a9dad task-no
This pull request bundles several usability and reliability updates across Odoo, including clearer product availability for delivery and click-and-collect, better payment deletion guidance, corrected POS receipt links, and improved messaging membership behavior. These changes reduce customer-facing errors, improve staff workflows, and make reports and website interactions behave more consistently.
Original PR description
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
Product forms now avoid loading a very large Intrastat code list into the browser. This reduces memory use and helps users navigate product records more smoothly, especially in databases with many Intrastat codes.
Original PR description
Previously, the intrastat_code_id was filtered by checking against a large list that is sent to the frontend. This caused huge memory usage due to the list being used in many objects and the list itself being large, around 10k items. This memory leak caused slowness in the frontend while going through the product form views. Currently, the list is not being sent. The domain itself is evaluated from the frontend without sending a list. This reduces memory footprint and slowness.
The Knowledge portal search experience has been adjusted so results better match whether users are searching from the portal or the main back office. This should make it easier for portal users to find the right articles without seeing less relevant internal results.
Helpdesk tickets that include billable timesheets can now be invoiced more easily once they are solved. Timesheets are automatically validated when a ticket reaches the solved stage, and a new Create Invoices action in the helpdesk overview helps teams bill completed work faster and with fewer manual steps.
Original PR description
Before this commit : - Timesheets are not validated automatically when a ticket is solved . - No available button to create invoices for solved tickets in the helpdesk overview. After this commit: - Timesheets linked to a helpdesk ticket get validated when ticket is moved to Solved stage. - A 'Create Invoices' button is added to invoice solved tickets in helpdesk overview. Task id: 4243781
Resolved issues and error corrections
This fix makes Point of Sale database upgrades process records in smaller batches, avoiding very slow updates on large sales databases. For affected customers, upgrade time can drop from several hours to around ten minutes, reducing downtime and migration risk.
Original PR description
Before this commit odoo/odoo@5bb76504425082cfd654a2860350aa94d9782dbd, the update query for UUID deduplication used…
Before this commit odoo/odoo@5bb76504425082cfd654a2860350aa94d9782dbd, the update query for UUID deduplication used [cr.split_for_in_conditions()](https://github.com/odoo/odoo/blob/13133b40eb545c4d4f7427c2145b3d57074fa74b/odoo/sql_db.py#L402-L405) to chunk IDs properly for the `WHERE id IN (...)` clause. However, after the mentioned commit, all IDs are passed at once, especially when `fetchmany()` returns up to 1 lac records. This significantly slows down the update query due to large `IN` clauses and memory overhead. To address this, reduce the processing chunk from 1lac to 10k IDs. This reduces update time from over 2 hours to under 10 minutes in practice for recordset shown below: ```sql apan_2760231=> select count(*) from pos_order; count -------- 146885 (1 row) apan_2760231=> select count(*) from pos_order_line; count -------- 378860 (1 row) apan_2760231=> select count(*) from pos_payment; count -------- 184679 (1 row) ``` Logs: Before fix (Almost 3 hrs): ```py 2025-04-17 07:06:31,094 31 INFO db_2760231 odoo.modules.migration: module point_of_sale: Running migration [1.0.2>] post-deduplicate-uuids 2025-04-17 10:08:39,397 31 INFO db_2760231 odoo.addons.base.models.ir_module: module point_of_sale: loading translation file /home/odoo/src/odoo/18.0/addons/point_of_sale/i18n/nl.po for language nl_NL ``` After fix (reduces to 10 mins): ```py 2025-04-17 11:29:44,294 23 INFO apan_2760231_18.0 odoo.modules.migration: module point_of_sale: Running migration [1.0.2>] post-deduplicate-uuids 2025-04-17 11:39:58,582 23 INFO apan_2760231_18.0 odoo.addons.base.models.ir_module: module point_of_sale: loading translation file /home/odoo/src/odoo/18.0/addons/point_of_sale/i18n/nl.po for language nl_NL ``` opw-4734894 upg-2760231 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Duplicating a restaurant point of sale no longer automatically copies its floor plan. This prevents orders placed at matching tables in duplicated restaurants from mixing or overwriting each other, reducing confusion for restaurant staff.
Original PR description
The original issue was that when you duplicated a pos restaurant, it would also duplicate it's floors. And when you would make an order on the same table in the 2 restaurant the second one would take the first one and override it. Steps to reproduce: ------------------- * Duplicate a restaurant * Make an order on the same table in the 2 restaurant * The second one will take the first one and override it > Observation: The new order contains the first order lines in it if you check the db Why the fix: ------------ To avoid confusion when duplicating restaurant we prevent duplicating the floor plans automatically. opw-4536327
Mobile users can now expand record dialogs, such as subtasks, just like they can on desktop. This makes related areas like the chatter accessible on phones and improves consistency across devices.
Original PR description
Steps: - Install `project` - Open a task - Create a subtask - Try to access chatter - It works on desktop, because you have the expand button - It doesn't work on mobile This commit adds this button on mobile too opw-4631478
Fixed an issue where sales orders could fail when customers used coupon programs that had multiple rewards. The system now selects the best available global discount reward, helping sales teams apply coupons reliably without interruptions.
Original PR description
This error occurs when a user creates multiple rewards of the same program using below steps : Steps to Reproduce : - Install module `sale_management` and `sale_loyalty. - In Products, go to Discount & Loyalty. - Create two new `Discount & Loyalty` with the program type `Coupons` and `Generate coupons. ` - Add multiple rewards to one coupon program. - Create a sale order and apply a coupon code from the first Discount & Loyalty program. Repeat the process with the coupon code from the second program. ValueError : Expected singleton: loyalty.reward(3, 4, 5) This error occurs when the system tries to fetch global_rewards but receives multiple values instead of a single record. This commit resolves the error by ensuring that only the global reward with the highest discount is selected. Sentry - 6417784661 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Physical gift cards sold and invoiced through Point of Sale now keep the entered card code and associated customer. This prevents missing or incorrect gift card records in the backend, making follow-up and redemption more reliable.
Original PR description
When selling a physical gift card, and invoicing it. The code and partner id where not taken into account. Steps to reproduce: ------------------- * Open PoS * Add a gift card to the order * Click on selling a physical gift card * Enter any code * Validate the order and invoice it > Observation: If you check the gift card in the backend, you will see that the code and partner id are not set correctly. Why the fix: ------------ When updating the rewards, the code and partner id were never set. opw-4597330
Fixed an issue where applying a global discount after a fixed product-specific loyalty reward could incorrectly increase the reward amount and make the final Point of Sale total too low or even negative. The checkout total now stays accurate by keeping fixed rewards at their intended value while applying the global discount only to the remaining amount.
Original PR description
Steps to reproduce ------------------ - Create a product with price $80 - Create a fixed discount reward for this product with $40 - In PoS config, enable global discount - In a new PoS order, add…
Steps to reproduce ------------------ - Create a product with price $80 - Create a fixed discount reward for this product with $40 - In PoS config, enable global discount - In a new PoS order, add the product created in the first step and observe that we now have 2 orderlines, the product at $80 and the discount at $40. Total amount remaining to pay is $40 - Add a global discount of 50% -> At this point, we are expecting to apply the 50% discount on the remaining $40, and hence, a discount of $20, which changes the order's total price to $20. We also expect the fixed discount line of $40 to remain at $40, as it's a fixed price discount. Indeed, we now see a $20 global discount as an orderline, but the $40 fixed discount has changed its value from $40 to $53.33, and thus, the total amount has decreased to $6.67 instead of $20 -> A corrupted final amount!! In some other pricing configs, this final total amount will even become negative. Reason ------ After applying the global discount, we recalculate the value of the discounts to keep everything in sync, so we recompute the discount value of the fixed $40 discount in `_getRewardLineValuesDiscount`, and since now the total amount to pay, i.e. `order.get_total_with_tax()` is less then the value of the product (due to the global discount), `discountFactor` [1] of the fixed discount increases since `discountable` decreases. However, at the end when we calculate the new `unit_price` of this fixed discount, we multiply the `discountFactor` by the intial product price, i.e. by the price before the global discount, and hence, the amount of the fixed tax will be higher than expected, causing this buggy behavior. Below is a math representation of the bad (current) vs good (new) behavior: Bad: discountable = $60 = $80 - $20, where $20 is (total - fixed) * discount, i.e. (80-40)*0.5 discountFactor = $40 / $60 = 0.666666 price_unit = 0.666666 * $80 = $53.3333 (instead of $40) Good should be: discountable = $60 = $80 - $20, where $20 is (total - fixed) * discount, i.e. (80-40)*0.5 discountFactor = $40 / $60 = 0.666666 price_unit = 0.666666 * $60 = $40 I.e the good behavior should be multiplying the `discountFactor` by the the min of the remaining total price (after applying the global discount, so $60), and the initial value of the product (here $80). The formula has been updated accordingly. [1]: https://github.com/odoo/odoo/blob/76e2aa6b70d1fb03b8ce2f8e4a7e9c3d9425270f/addons/pos_loyalty/static/src/overrides/models/pos_order.js#L1163 opw-4622428
This fix makes Point of Sale database upgrades process records in smaller batches, avoiding very large updates that could run for hours. For large retail databases, the upgrade step can complete much faster and with less strain on the system.
Original PR description
Before this commit odoo/odoo@5bb76504425082cfd654a2860350aa94d9782dbd, the update query for UUID deduplication used…
Before this commit odoo/odoo@5bb76504425082cfd654a2860350aa94d9782dbd, the update query for UUID deduplication used [cr.split_for_in_conditions()](https://github.com/odoo/odoo/blob/13133b40eb545c4d4f7427c2145b3d57074fa74b/odoo/sql_db.py#L402-L405) to chunk IDs properly for the `WHERE id IN (...)` clause. However, after the mentioned commit, all IDs are passed at once, especially when `fetchmany()` returns up to 1 lac records. This significantly slows down the update query due to large `IN` clauses and memory overhead. To address this, reduce the processing chunk from 1lac to 10k IDs. This reduces update time from over 2 hours to under 10 minutes in practice for recordset shown below: ```sql apan_2760231=> select count(*) from pos_order; count -------- 146885 (1 row) apan_2760231=> select count(*) from pos_order_line; count -------- 378860 (1 row) apan_2760231=> select count(*) from pos_payment; count -------- 184679 (1 row) ``` Logs: Before fix (Almost 3 hrs): ```py 2025-04-17 07:06:31,094 31 INFO db_2760231 odoo.modules.migration: module point_of_sale: Running migration [1.0.2>] post-deduplicate-uuids 2025-04-17 10:08:39,397 31 INFO db_2760231 odoo.addons.base.models.ir_module: module point_of_sale: loading translation file /home/odoo/src/odoo/18.0/addons/point_of_sale/i18n/nl.po for language nl_NL ``` After fix (reduces to 10 mins): ```py 2025-04-17 11:29:44,294 23 INFO apan_2760231_18.0 odoo.modules.migration: module point_of_sale: Running migration [1.0.2>] post-deduplicate-uuids 2025-04-17 11:39:58,582 23 INFO apan_2760231_18.0 odoo.addons.base.models.ir_module: module point_of_sale: loading translation file /home/odoo/src/odoo/18.0/addons/point_of_sale/i18n/nl.po for language nl_NL ``` opw-4734894 upg-2760231 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a connection issue in Argentina electronic invoicing that could occur when running newer Python versions. It helps keep tax web service communication reliable across supported deployment environments.
This update improves batch invoice sending for Brazil, Colombia, Mexico, and Uruguay localizations by showing more accurate invoice counts before sending. It also fixes cases where Peppol invoices could be missed when no electronic invoice format was set, and treats Peppol XML generation problems as blocking errors instead of silently skipped items.
Original PR description
*: l10n_br_edi, l10n_co_dian, l10n_mx_edi, l10n_uy_edi 1. fix the summary of account.move.send.batch.wizard The summary was displaying wrong numbers of invoices. Indeed, it was computed on default…
*: l10n_br_edi, l10n_co_dian, l10n_mx_edi, l10n_uy_edi 1. fix the summary of account.move.send.batch.wizard The summary was displaying wrong numbers of invoices. Indeed, it was computed on default methods, instead of methods that are applicable to the move. For example, if a move was not possible to send through Peppol because the partner is not registered on the network, it was still displayed in the summary of the batch sending (then not used when the async processing happened). We also always put email as a fallback, even if no email is set, since it can be added through the wizard. 2. fix batch send of Peppol invoices when no format set In previous commit[1], we set the BIS3 format on invoices that were meant to be sent trough Peppol, even if no invoice_edi_format was set on the Partner. This commit fixes some cases when sending multiple invoices with no invoice_edi_format but Peppol as default sending method ended up not being sent. [1]: https://github.com/odoo/odoo/commit/84a0b81a258262e3bb9dbaa9c9f37796303a9dad 3. Remove 'skipped' state of Peppol moves This state doesn't really make sense. It only happens when there is an error while generating the XML file to send, which can be considered as a blocking error. task-no (review with TSB and PMAX)
Payslips now exclude overtime that is still waiting for manager approval. This helps prevent employees from being paid for overtime before it has been reviewed and approved, improving payroll accuracy.
Original PR description
to reproduce: ============= - with employee having attendace houre based contract - set in attendace settigns that overtime should be approved by manager - create attendace for this employee with overtime pending for approval - create payslip for this employee -> the overtime is included in the payslip even if it is not approved Problem: ======== unapproved overtimes are not filtred while computing payslip lines Solution: ========= - add a filter to exclude unapproved overtimes in payslip line computation opw-4610454
Fixes an issue that could cause Helpdesk ticket screens or automated checks to run out of memory when processing large numbers of tickets. The change makes ticket counting more efficient, improving reliability for teams with high ticket volumes.
Original PR description
**Traceback:** ```python ('helpdesk.helpdesk_ticket_menu_all', 117, 'Helpdesk > Tickets > All Tickets', 157): Traceback (most recent call last): File…
**Traceback:**
```python
('helpdesk.helpdesk_ticket_menu_all', 117, 'Helpdesk > Tickets > All Tickets', 157):
Traceback (most recent call last):
File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 259, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 272, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 432, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 463, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3814, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4045, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 7031, in __getitem__
return self._fields[key].__get__(self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1303, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1485, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/18.0/addons/base_automation/models/base_automation.py", line 816, in _compute_field_value
return _compute_field_value.origin(self, field)
File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 429, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5253, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
return needle(*args)
File "/home/odoo/src/enterprise/18.0/helpdesk/models/helpdesk_ticket.py", line 298, in _compute_partner_ticket_count
partner_tickets.fetch(['stage_id']) # prevent over-fetching fields, leading to potential out-of-memory error
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4095, in fetch
self.check_access('read')
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4394, in check_access
if not self.env.su and (result := self._check_access(operation)):
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4435, in _check_access
if domain and (forbidden := self - self.sudo().filtered_domain(domain)):
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6627, in filtered_domain
data = record.mapped(key)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6470, in mapped
recs = recs._fields[name].mapped(recs)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1377, in mapped
self.__get__(first(remaining))
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 3059, in __get__
return super().__get__(records, owner)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1266, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4071, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4108, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4197, in _fetch_query
rows = self.env.execute_query(query.select(*sql_terms))
File "/home/odoo/src/odoo/18.0/odoo/api.py", line 979, in execute_query
return [] if self.cr.description is None else self.cr.fetchall()
MemoryError
```
Issue:
------
The `_compute_partner_ticket_count` method caused a MemoryError while running the test cases due to the large number of records and over fetching of `stage_id` in the line: `partner_tickets.fetch(['stage_id'])`
followed by: `partner_tickets.filtered(lambda ticket: not ticket.stage_id.fold)`
Solution:
---------
Replaced the fetch and filtered logic with a search method to resolve the MemoryError and improve performance
upg-2707381
opw-4653413