Friday, September 18, 2026
5 changes · 18.0
Resolved issues and error corrections
Date and date-time values now display in the proper format when administrators set default values in debug mode. This helps prevent confusion and avoids saving date fields with unintended date-time values.
Original PR description
Problem: When setting default values in debug mode, the date and datetime values are not formatted correctly. This leads to confusion and incorrect values being set for date fields. Steps to reproduce: 1. Enable debug mode 2. Create a journal entry, set the date to some date (August 31st, for example), and save. 3. Click the bug icon, click Set default values. 4. Click on the dropdown, notice how the date is displayed as datetime instead of date. Cause: The displayed values were not being formatted for date and datetime fields when setting default values. They were just output as strings. Also, dates were not serialized correctly before being sent to the server, they were serialized as datetime instead of date, because the code was checking the constructor name of the value instead of the field type. opw-6533491
This fix makes fiscal position selection consistent when imported records share the same priority value. It helps prevent unpredictable accounting behavior caused by database ordering differences.
Original PR description
The algorithm to find the right fiscal position works on top of deterministically ordered fiscal position records. This invariant is not enforced by the functional code. Importing data without explicit sequence number results in multiple records ending up with the same value in this column. Sorting by column 'sequence' is not good enough to have repetitive results in this case. The fiscal position algorithm can return a different record due to database implementation details. Adding field "id" to the default ordering ensures the order of fiscal position records remains deterministic. This is because insertion order is preserved and locked into order-preserving id-values when importing data. REF Runbot; https://runbot.odoo.com/odoo/error/945738
The attendance kiosk now shows weekday names in the selected company or interface language instead of always using English. This provides a more consistent localized experience for employees using kiosk mode.
Original PR description
Problem:
The weekday displayed in the attendance kiosk header is always shown in English, even when the comapany contact's language is changed.
This happens because `DateTime.toFormat("cccc")` uses Luxon's locale, but the `DateTime` instance is created without setting the current UI locale.
Steps to reproduce:
1. Install `hr_attendance`.
2. Change the company contact language to a language other than English (e.g. French).
3. Open the Kiosk Mode.
4. Observe that the date and UI are translated, but the weekday remains in English (e.g. "Monday" instead of "Lundi").
Fix:
Set the Luxon locale from the document language before formatting the weekday. This ensures `toFormat("cccc")` returns the weekday in the active Company contact language.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe point of sale IoT setup no longer requires payment devices to report a manufacturer. This keeps payment terminal detection working with the latest stable IoT Box image, reducing setup issues for stores using IoT-connected payment hardware.
Original PR description
We remove the manufacturer from the domain to ensure compatibility with the last stable IoT Box image that doesn't provide a manufacturer. Forward-Port-Of: odoo/enterprise#132142
The Timesheet Grid now only greys out public holidays that belong to the company currently being viewed. This prevents holidays from other companies from incorrectly affecting timesheet planning and review.
Original PR description
Issue: - Public holidays from other companies were incorrectly included in the Timesheet Grid view of the current company. As a result, days corresponding to those holidays appeared greyed out.…
Issue: - Public holidays from other companies were incorrectly included in the Timesheet Grid view of the current company. As a result, days corresponding to those holidays appeared greyed out. Cause: - The `grid_unavailability` method relies on the `_get_valid_work_intervals` function to fetch all unavailability data at once. When fetching data for multiple employees, this function also retrieves public holidays from all companies. Fix: - The method no longer uses the data returned by `_get_valid_work_intervals` for company unavailable days. Instead, it now always makes a separate, direct call via the `get_company_unavailable_dates()` function. This ensures that only holidays relevant to the current company are considered in the grid view. The company is also passed in the domain of `_work_intervals_batch`, which otherwise returns the leaves of every company when no resource is given. Steps to reproduce: - 1. Create Company A and Company B. 2. In Company B, create a public holiday on Tuesday. 3. Switch back to Company A. 4. Open the All Timesheets Grid view from Company A. Expected behavior: - - The grid column for Tuesday should not be grey for Company A users. Current behavior: - - The grid column for Tuesday is grey, incorrectly showing it as a time-off day. task:4492966 Forward-Port-Of: odoo/enterprise#88495