Wednesday, December 24, 2025
8 changes · 18.0
Resolved issues and error corrections
This update prevents unnecessary email reminders for timesheet approvals. It ensures reminders are only sent when there are actual timesheets needing attention, and when a user is correctly designated as a manager or approver – even if the employee doesn't have a manager assigned. This reduces email clutter and improves efficiency.
Original PR description
prevent cron from sending approver reminder if no timesheet assigned to approver Send the reminder email if: - there are timesheets to validate - AND if the user is set as either the manager or timesheet approver of an employee with timesheets left to be validated - OR if the said employee has no manager or timesheet approver set Task-3624610 Forward-Port-Of: odoo/enterprise#52355
This update resolves a problem where certain tests in the l10n_mx_edi module were consistently failing due to an incorrect date calculation. The change sets a standard test date in the middle of the year, ensuring all tests run reliably and accurately.
Original PR description
Some tests are making "self.frozen_today - timedelta(days=1)". It means some tests are failing only the first of January. To avoid that, let's make "frozen_today" to be in the middle of the year. Forward-Port-Of: odoo/enterprise#102772
This update resolves a bug in the calendar functionality that prevented the 'knowledge_calendar_command_tour' tour from working correctly in Chrome 143 and later. The fix ensures events are dispatched properly when the calendar container is attached to a shadow tree, aligning with web standards and resolving a compatibility issue.
Original PR description
Tour "knowledge_calendar_command_tour" fails since Chrome 143 with an error "Cannot read properties of null (reading 'querySelectorAll')". This is due to the fix in Chromium "Fix target/relatedTarget…
Tour "knowledge_calendar_command_tour" fails since Chrome 143 with an error "Cannot read properties of null (reading 'querySelectorAll')". This is due to the fix in Chromium "Fix target/relatedTarget clearing logic during dispatch" [^1] introduced in Chrome 143, to actually match the spec [^2]. To quote the Chromium commit message: > According to the spec, only if the top node is in a shadow tree, both > the target and relatedTarget should be cleared. > However, if the top node is not in a shadow tree and not a document, > the target and relatedTarget are always cleared. Because the current > implementation only checks whether the top node is not a document. > So, this patch fixes the bug by checking whether the top node is in a > shadow tree. In practice, this means that events are now properly dispatched when the FullCalendar container's element is not connected to the document but still to the shadow tree. As a result, the OWL reference to this container can not exist anymore when the event handler is called but FullCalendar's API still has the right reference to this element. Note: Firefox and Safari already implemented the spec properly (aka. it was already broken for them...) [^1]: https://chromium.googlesource.com/chromium/src/+/63178146cd776eae2b466983f0835e86c314d051%5E%21/ [^2]: https://dom.spec.whatwg.org/#concept-event-dispatch
This update resolves an issue where scanning cashier barcodes would cause an error if employee logging was turned off. Now, the barcode scanning functionality works seamlessly regardless of whether employee logging is enabled, ensuring consistent operation for all users. This improves the reliability of the Point of Sale module.
Original PR description
Before this commit, if logging with employee was disabled, scanning a cashier barcode would raise an error. opw-5437310 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where setting a Bill of Materials (BoM) and changing the production quantity in a manufacturing order could create duplicate work orders. The fix ensures that work orders are only created once during recalculation, preventing this duplication and streamlining the manufacturing process.
Original PR description
Steps to reproduce:
- Create a storable product "P1"
- Create a BoM with one operation
- Create a manufacturing order for product "P1"
- Do not set any BoM
- Save
- In draft state:
- Set the BoM
- Without saving, update the quantity to produce
Problem:
The same operation is added twice, resulting in duplicate work orders.
Cause:
Work orders are recomputed multiple times when BoM and quantity are changed before saving, and existing (not yet saved) work orders linked to the same BoM are not properly filtered out.
Fix:
Ensure that work orders linked to the current BoM are only created once during recomputation.
opw-5404686This update fixes an issue where multiple order lines were incorrectly refunded during the Point of Sale refund process. Now, only the selected line is refunded, and deleting a refund order correctly restores the order's status. This ensures accurate refund transactions and a smoother user experience.
Original PR description
Steps to reproduce: - In POS, select a paid order in the ticket screen with multiple lines. - Select the first line, choose a quantity to refund, and click Refund. - Return to the ticket screen, select the same paid order again. - Select another line and quantity, and click Refund. Issue: - In the second refund, all order lines were being refunded, even though only one line was selected. - After deleting a refund order, the ticket screen still showed messages like "Refunding x quantities in xyz order." Fix: - Only the selected lines are refunded. - Deleting a refund order restores the state of the linked order correctly. Task-5095578
This update resolves an error that occurred when a user removed the end date from a planning slot. The fix ensures the system handles the absence of an end date correctly, preventing a technical error and maintaining smooth slot management functionality. This improves the user experience and prevents data inconsistencies.
Original PR description
Currently an error occurs when user tries to remove end date on slot. Steps to replicate: - Install `planning`. - Create a new planning slot and click on a slot template at the top. - Remove the end…
Currently an error occurs when user tries to remove end date on slot.
Steps to replicate:
- Install `planning`.
- Create a new planning slot and click on a slot template at the top.
- Remove the end date (rightmost) and click elsewhere.
Error:
```
File /home/odoo/odoo18/enterprise/planning/models/planning.py, line 423, in _compute_template_id
if slot._different_than_template():
File /home/odoo/odoo18/enterprise/planning/models/planning.py, line 439, in _different_than_template
slot_time = self[slot_field].astimezone(pytz.timezone(self._get_tz()))
AttributeError: 'bool' object has no attribute 'astimezone'
```
Cause:
- When the end date was removed, [compute] was triggered, calling the `_different_than_template()` method, which iterates through the fields in the slot template.
- Since the user removed `end_datetime`, `self['end_datetime']` became false and caused the error at line [1].
Solution:
- Returned from the function call when `end_datetime` is false.
[compute]: https://github.com/odoo/enterprise/blob/745c1cc0e06f5e0578ec4383439f8be2419adb6b/planning/models/planning.py#L418-L426
[1]: https://github.com/odoo/enterprise/blob/745c1cc0e06f5e0578ec4383439f8be2419adb6b/planning/models/planning.py#L438
No IDThis update resolves an issue preventing regular users from digitizing expense receipts. Previously, users needed specific administrator access. The change now allows digitization for draft expenses, streamlining the expense reporting process. This improvement ensures all users can easily upload receipts, reducing delays and improving efficiency.
Original PR description
When a regular user tries to digitize the receipt attached to an expense, the `UserError(_("You don't have the rights to bypass the validation process of this expense."))` is raised. It seems that currently, the user needs to be in the Expenses Administrator group (`group_hr_expense_manager`) to digitize the receipt, which doesn't seem correct.
This PR solves the issue by skipping the check of the user's group if the expense is in draft state, as suggested by @JulienAlardot: https://github.com/odoo/enterprise/pull/101011#pullrequestreview-3558220264
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr