Daily updates from Odoo
Wednesday, May 6, 2026
309 changes
1 change
Resolved issues and error corrections
This update resolves an issue where free FSM services with prepaid invoicing were not appearing on invoices. The change adjusts a calculation to correctly reflect the quantity of services, ensuring these services are now properly included when generating invoices. This improves the accuracy of invoicing for service-based contracts.
Original PR description
Changed _compute_qty_to_invoice in industry_fsm_sale, SaleOrderLine to no longer set qty_to_invoice to 0 for free services with prepaid invoicing. Previous changes seem intended for goods. Steps to reproduce: - Create service product with 0 price, prepaid invoice policy, creates FSM task - Create/Confirm sales order with created product - Attempt to create invoice, get 0 quantity to invoice error Current Behavior: Free services linked to FSM tasks do not appear on invoices due to compute 0 qty_to_invoice Expected Behavior: Prepaid Invoice Services linked to FSM tasks appear on invoices. Other invoice policies can be invoiced through the generated sales order lines (timesheets, delivered quantity, etc.) opw-6047992 Forward-Port-Of: odoo/enterprise#113718
2 changes
Resolved issues and error corrections
This update clarifies French Profit and Loss reports by splitting account 649 into two new accounts (6491 and 6492). This separation accurately reflects social security charges and salaries, aligning with French accounting standards (ANC PCG 2026). The original account remains for legacy systems.
Original PR description
Splitting account 649 into two new accounts (6491 and 6492) is necessary to handle the Profit and Loss report properly. This ensures we can accurately separate social security charges from salaries in the report. Reference: ANC PCG 2026, page 445, note (h) https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf task-6053784 Forward-Port-Of: odoo/enterprise#114412 Forward-Port-Of: odoo/enterprise#111420
This update fixes a bug in the payroll calculation process. Previously, the system incorrectly skipped remuneration declarations when all worked days fell under a specific code, leading to missed payments for year-end bonuses or other non-worked day payments. This change ensures accurate declaration of all remuneration amounts, particularly for scenarios like end-of-year bonuses.
Original PR description
Forward-Port-Of: odoo/enterprise#116191 Forward-Port-Of: odoo/enterprise#106689
1 change
Resolved issues and error corrections
This update ensures Odoo's Dutch reporting modules (SBR, ICP, and Status Info) correctly submit data to the new Digipoort infrastructure, which is migrating to digipoort.logius.nl by May 1, 2026. This change is critical to avoid submission failures and maintain compliance with Dutch regulations.
Original PR description
*: l10n_nl_reports_sbr{,_icp,_status_info}
---
Description of the issue this commit addresses:
The Dutch Digipoort endpoint infrastructure is being migrated from procesinfrastructuur.nl to digipoort.logius.nl effective May 1, 2026. Odoo's SBR modules need to use the new endpoints or submissions will fail.
---
Desired behavior after this commit is merged:
This commit updates all Digipoort endpoint URLs (delivery and status services) from the old domain to the new logius.nl domain, and clarifies that valid PKIoverheid certificates are required for both environments. Reports now submit to the new Digipoort infrastructure correctly.
---
task-6171403
Forward-Port-Of: odoo/enterprise#1156685 changes
Resolved issues and error corrections
This update corrects a misleading validation error that appeared when using the translation button on Sale Order Templates. The issue stemmed from how the system attempted to save records, particularly within O2M list views. Now, the system correctly identifies and highlights missing required fields, improving the user experience.
Original PR description
Steps to reproduce: * Enable multiple languages * Go to Sale Order Templates and create a new template * Add a product line, then click the translate button on the description field * A confusing…
Steps to reproduce: * Enable multiple languages * Go to Sale Order Templates and create a new template * Add a product line, then click the translate button on the description field * A confusing validation error appears for missing `sale_order_template_id` Issue: * Instead of highlighting the missing required fields on the sale order template form view, it raises a misleading validation error on `sale_order_template_id` Cause: * `useTranslationDialog` always attempts to save the passed record directly. In O2M list views, the field can belong to a nested relational record, so the correct behavior is to save the root record instead. Affected Version: 17.0 Before: <img width="1919" height="1014" alt="image" src="https://github.com/user-attachments/assets/cd61381d-289a-4df4-bdf2-7881fa851939" /> After: <img width="1920" height="887" alt="image" src="https://github.com/user-attachments/assets/5218c74b-c024-4994-b816-cb7ae69b420f" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a memory-related issue that occurred when processing quantity data for stock moves. By proactively fetching this field, the system now avoids running out of memory, ensuring smoother and more reliable operation. This fix was necessary because the problem was present in the previous version and is now addressed in the current 17.0 release.
Original PR description
While mapping the quantity field on stock moves, an out-of-memory issue occurred. To prevent this, the field is now prefetched in the same way as other fields. Note: the issue is faced during 16.0…
While mapping the quantity field on stock moves, an out-of-memory issue occurred. To prevent this, the field is now prefetched in the same way as other fields.
Note: the issue is faced during 16.0 version too but as 16.0 is no more supported for bug fix. So, doing it from 17.0 version.
```py
Traceback (most recent call last):
File "/tmp/tmpstui3bd7/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpstui3bd7/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpstui3bd7/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpstui3bd7/migrations/base/tests/test_mock_crawl.py", line 550, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3038, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3219, in _read_format
vals[name] = convert(record[name], record, use_name_get)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 6007, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1222, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1404, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/16.0/addons/mail/models/mail_thread.py", line 403, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4276, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 101, in determine
return needle(records, *args)
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 702, in _compute_related
record[self.name] = self._process_related(value[self.related_field.name])
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 6007, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1222, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1404, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/16.0/addons/mail/models/mail_thread.py", line 403, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4276, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 98, in determine
return needle(*args)
File "/home/odoo/src/odoo/16.0/addons/purchase_stock/models/res_partner.py", line 37, in _compute_on_time_rate
for move, qty_done in zip(moves, moves.mapped('quantity_done')):
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5470, in mapped
recs = recs._fields[name].mapped(recs)
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1296, in mapped
self.__get__(first(remaining), type(remaining))
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1187, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3245, in _fetch_field
self._read(fnames)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3322, in _read
cr.execute(query_str, params + [sub_ids])
File "/home/odoo/src/odoo/16.0/odoo/sql_db.py", line 547, in execute
return self._cursor.execute(*args, **kwargs)
File "/home/odoo/src/odoo/16.0/odoo/sql_db.py", line 324, in execute
res = self._obj.execute(query, params)
psycopg2.DatabaseError: out of memory for query result
```
opw-5921410
upg-3891767
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue where contacts enrolled in shared courses were incorrectly merged. Now, attempts to merge these contacts will be blocked, preventing data duplication and ensuring accurate course enrollment records. This change improves data integrity and simplifies contact management.
Original PR description
Expected Behaviour: Contacts enrolled in common courses should not be merged and the merge should fail. Steps to reproduce: 1- Go to one of the courses 2- Add two attendees to the course 3- Go to Contacts App 4- Select the two attendees you added to the course 5- Try merging the two contacts Actual Behaviour before the Fix: Contacts enrolled in common courses are getting merged and the common courses are kept in the destination contact. Behaviour with the Fix: Contacts enrolled in common courses are blocked from being merged and an error message is shown to the user saying that the reason the merge is blocked is a duplicate course. opw-5417223
This update fixes an issue where the Point of Sale system would fail when multiple rescue sessions were open for a configuration. Now, the system intelligently displays a list of rescue sessions when multiple are active, or a direct form view when only one is open, ensuring a smoother user experience.
Original PR description
When multiple rescue sessions existed for a POS config, calling `open_opened_rescue_session_form` raised a ValueError ("Expected singleton") because `.id` was accessed on a multi-record set.
Now opens a filtered list view titled "Rescue Sessions" when multiple open rescue sessions are found, and a direct form view when there is only one.
opw-6184661
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue preventing sales team members from opening milestones within projects created from sales orders. The fix bypasses access restrictions to ensure users can correctly calculate quantities, allowing them to manage milestones effectively. This improves the sales process and prevents workflow disruptions.
Original PR description
Steps to reproduce: - Install the sale_project module - Create a sale order based on milestones - Create the project from the order - Open the project, click the three dots, and open a milestone Issue: Users are unable to open milestones and get an access error. Cause: Users in `sales_team.group_sale_salesman` lack read access to the related `sale.order.line`, causing an AccessError when `sale_line_id` is accessed during the computation of `product_uom_qty`. Fix: Compute `product_uom_qty` using `sudo()` to bypass record rule restrictions. task-5477304