Thursday, April 17, 2025
16 changes · 18.0
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