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