Daily updates from Odoo
Wednesday, May 6, 2026
4 changes · 17.0
Enhancements to existing features
This update ensures Odoo's Dutch reporting modules (SBR, ICP, and Status Info) correctly submit data to the new Digipoort infrastructure, effective May 1, 2026. This migration is required by the Dutch government and prevents submission failures. It also confirms the need for valid PKIoverheid certificates.
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#115668Resolved issues and error corrections
This update fixes an issue where the DMFA report incorrectly displayed '5' for 'Days Per Week' when employees worked fewer than 5 days a week. The fix adjusts the calculation to accurately reflect the employee's actual working schedule, ensuring accurate reporting for Belgian payroll compliance.
Original PR description
## Issue When generating a DMFA report with a working schedule with more or less than 5 days a week, the *Days Per Week* value in the report is still appearing as 5. ## Steps to reproduce 1. Install…
## Issue
When generating a DMFA report with a working schedule with more or less than 5 days a week, the *Days Per Week* value in the report is still appearing as 5.
## Steps to reproduce
1. Install *Belgium - Payroll* (`l10n_be_hr_payroll`)
2. In Payroll's Settings:
- set *ONSS Registration Number* to `0830123456`
- set *DMFA Employer Class* to `083`
- create a *Work Address DMFA code* (any name, any numeral code, but set the *Working Address* to the Belgian company used for the rest of the steps)
3. In Employees' Settings, set the *Company Working Hours* to a new Working Schedule, with 9 hours/day, 4 days/week. E.g from Monday to Thursday included:
- Work from 8:00 to 12:00
- Lunch from 12:00 to 13:00
- Work from 13:00 to 18:00
4. Create an Employee E for the Belgian company:
- In the *Payroll* tab, set the start date of the contract to 01/01/2026.
- In the *Personal* tab, set the *NISS Number* to `85073003328`
5. Create the payslip for January 2026 for the Employee E.
6. In Payroll > Reporting > Belgium > DMFA, create a new DMFA for the first quarter of 2026 and generate the PDF report
7. **In the generated PDF report, the _Days per Week_ line is set to 5.**
## Cause
The number of days was calculated by multiplying `5` with the `work_time_rate` of the related calendar. This is inaccurate in the case of a company where employees are only expected to work 4 days a week.
opw-6103934This 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 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