Daily updates from Odoo
Thursday, May 14, 2026
4 changes · master
Resolved issues and error corrections
This update resolves an error that occurred when users set their fiscal year's end date to February 29th. The fix ensures reports accurately calculate dates, regardless of whether the fiscal year is a leap year or not. This prevents reporting issues related to incorrect date calculations.
Original PR description
**Steps to Reproduce:** 1. Install the Accounting module. 2. Go to Settings and set the fiscal year's last day to 29 February. 3. Accounting > Reporting > open any report. **Error:** `ValueError - day is out of range for month` **Cause:** At [1], a fixed year (2025) is used to compute the fiscal year end. However, 2025 is not a leap year, so creating a date with February 29 raises an error. **Fix:** Ensure that when the fiscal year’s last day is Feb 29, a leap year (2024) is used for the computation. For all other dates, the year remains unchanged (2025). As a result; - If the last day is February **28** (non-leap year) -> `fy_start` becomes **March 1** - If the last day is February **29** (leap year) -> `fy_start` also becomes **March 1** [1] - https://github.com/odoo/enterprise/blob/4fa1c0c13308bd8de06646543391f8cbcf28d05e/account_reports/models/account_report.py#L820 sentry-7438598965 Forward-Port-Of: odoo/enterprise#115400
This update prevents a critical error that occurred when creating quality checks from quality points. The issue arose when a product wasn't specified, causing a system error. This fix ensures quality checks can be created successfully under all circumstances, improving data integrity and usability.
Original PR description
When creating a quality check from a quality point, a traceback occurs if no product is set. Steps to reproduce the error: - Install ``quality_control`` module with demo data - Go to Quality > Quality Control > Control Points > Create a new Control point > Set Control per: Quantity, Partial Test: 99 > Save - Click on Quality Checks smart button > Click on New Traceback: ```py ValueError: Expected singleton: uom.uom() ``` https://github.com/odoo/enterprise/blob/4fa1c0c13308bd8de06646543391f8cbcf28d05e/quality_control/models/quality.py#L369 During creation of a quality check, ``product_id`` is not set. The compute method ``_compute_qty_to_test`` accesses ``product_id.uom_id``, which leads to the above traceback. sentry-7440188763 Forward-Port-Of: odoo/enterprise#115292
This update cleans up tests related to the recent restructuring of the POS stock functionality. Previously, tests were referencing outdated stock-related data, which has now been removed to align with the new `pos_stock` module. This ensures the tests accurately reflect the current system.
Original PR description
Issue: ====== - Some tests were still using stock-related fields and groups that were previously part of `pos`, but were moved to a new module `pos_stock` after the refactor. Fix: ===== - Remove references to these fields from the tests, as stock-related logic is now handled in `pos_stock` module. Task-6183114 Error-242928,243017,243059 Related Community PR: https://github.com/odoo/odoo/pull/262719 Forward-Port-Of: odoo/enterprise#116185
The 'Waiting for Me' filter in the Sign app was incorrectly fetching all documents instead of filtering those requiring the current user's signature. This update corrects a technical issue related to how the system processes filter criteria, ensuring the filter functions as intended and only displays relevant documents.
Original PR description
When applying the 'Waiting for me' filter in the Sign app, all documents are fetched instead of filtering out documents that do not need the current user's signature. Steps to reproduce: 1) Install…
When applying the 'Waiting for me' filter in the Sign app, all documents are fetched instead of filtering out documents that do not need the current user's signature.
Steps to reproduce:
1) Install sign with demo data
2) Open sign app and remove default filter
3) Add a filter Waiting for me
Observed Behavior:
All the documents are fetched.
Expected Behavior:
Documents should be filtered out to only show those where the current user is a signer.
Root Cause:
Since [commit](https://github.com/odoo/enterprise/pull/76079/changes/8b5048f63f91a38a710b611d17f5cf27fbd0a18a), The `_search_need_my_signature` method returned `NotImplemented` for any operator other than `in` at [1]. While the filter uses `=` at [2]. Following a recent ORM optimization with the mentioned commit, the operators are now standardized as shown
From:
`('need_my_signature', '=', True)]`
To:
`[('need_my_signature', 'in', [True])]`
This means the search method now receives the expected `in` operator. However, the return logic uses a `not in` condition when filtering documents waiting for signature.
As a result, instead of filtering documents, all documents are returned.
[1]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/models/sign_request.py#L107-L108
[2]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/views/sign_request_views.xml#L177
Fix:
Corrected the return domain logic to fetch the correct documents.
opw-6026935
Forward-Port-Of: odoo/enterprise#117049
Forward-Port-Of: odoo/enterprise#113760