Daily updates from Odoo
Wednesday, May 27, 2026
7 changes · master
Resolved issues and error corrections
This update fixes an issue preventing users from importing emissions data within the ESG module. The change allows the 'import' action to appear in the COG menu, even with the 'create' attribute disabled, ensuring seamless data import functionality. This improves the usability of the ESG reporting features.
Original PR description
Before this commit, the "import" action of emissions in the ESG module was not visible in the COG menu. It is because the "create" attribute of the list view is disabled, which prevents the menu item from being displayed. With this commit, we override the standard behavior in this particular action, by allowing the import action to show up in the COG menu, even if the "create" attribute is disabled. version-19.1 Forward-Port-Of: odoo/enterprise#118004
This update fixes a bug where Preparation Displays (PDIS) weren't correctly updated during table actions like transferring or merging orders. Previously, new PDIS were created instead of reusing existing ones, leading to inconsistencies. Now, PDIS are synchronized across all table actions, ensuring accurate order information on both the POS and kitchen screens.
Original PR description
Task: [#5005179](https://www.odoo.com/odoo/1737/tasks/5005179) --- When executing table actions such as transfer, merge, link, or unlink, the related Preparation Displays (PDIS) were not being updated. This caused inconsistencies between the POS orders and the kitchen screens. Also, when merging or linking orders and cancelling some lines, a new `pdis_order` was created instead of reusing the existing one. This fix ensures that PDIS are correctly synchronized and notified on any table actions. Forward-Port-Of: odoo/enterprise#99975 Forward-Port-Of: odoo/enterprise#98374
This update corrects a bug where refund processing triggered the unintended cancellation of original invoices within the Mexican CFDI integration. The fix adds a check to ensure the automatic cancellation flow only applies to invoice replacements, preventing credit notes from causing incorrect cancellations. This ensures accurate accounting and avoids disruptions for users.
Original PR description
Issue: Implementation of automatic CFDI cancel flow of an invoice substituted by a new one accidentally resulted in sending credit notes created from an invoice also triggering cancellation of the original. Solution: adding a check to only apply to invoice replacements and not refunds. ticket-6245456 Forward-Port-Of: odoo/enterprise#118327
This update ensures that signatories receive the signed document and Certificate of Completion (COC) as email attachments after completing a signature request via WhatsApp. Previously, the system only sent a WhatsApp link, causing delays in receiving the official signed document. This change improves the user experience and compliance with standard document delivery processes.
Original PR description
Previously, if a signature request was completed via the WhatsApp channel, the system only sent a WhatsApp message containing a link to the document. It bypassed standard email delivery entirely, meaning signatories never received the actual signed PDF or the Certificate of Completion (COC) as attachments. This commit improves the completion flow across both the backend and the generated reports: - **Backend:** Refactored `_send_completed_documents_message` to always call `super()`. This ensures the final signed document and COC are reliably delivered as email attachments, even after the WhatsApp link is sent. - **Reports:** Inherited the `sign_request_logs` QWeb template. When `send_channel == 'whatsapp'`, the PDF now dynamically replaces the "Email Verification" headers and footnotes with "Phone Verification". Additionally, it replaces the generic checkmark with the signer's masked phone number. Task: 5951833
This update ensures that when a food delivery order is cancelled through the aggregator (Atlas), the corresponding order in the POS system is also correctly marked as cancelled. Previously, the POS order remained in an active state, leading to confusion. This change improves order visibility and accuracy for both staff and customers.
Original PR description
pos*: pos_urban_piper, pos_enterprise When a food delivery order is cancelled from the aggregator side, the PoS order remains active on the frontend instead of reflecting the cancelled state. Steps to reproduce: - Configure UrbanPiper with Atlas - Place an order via Atlas - Open the order from the notification bar - Cancel the order from Atlas Issues: - Cancelled orders continue to appear in `Draft` - Accepted/preparation orders are not cancelled on the preparation display Fix: - Synchronise the PoS order state with the delivery state on cancellation - Update preparation display orders when delivery orders are cancelled Task-6217704 Forward-Port-Of: odoo/enterprise#118294 Forward-Port-Of: odoo/enterprise#117374
This update resolves an issue where the timesheet timer wouldn't function when accessed from a subtask. The fix ensures the timer correctly opens and pre-fills with the subtask's project details, preventing a 'missing record' error. This improves the user experience for managing timesheets on subtasks.
Original PR description
**Problem:** Clicking the timesheet timer in the systray while viewing a subtask raises a MissingError, preventing the user from starting the timer. **Steps to reproduce:** 1. Open a project task…
**Problem:** Clicking the timesheet timer in the systray while viewing a subtask raises a MissingError, preventing the user from starting the timer. **Steps to reproduce:** 1. Open a project task that has subtasks 2. Click the subtasks smart button and open a subtask 3. Click the timesheet timer icon in the systray 4. Observe the "missing record" error **Current behavior:** The systray RPC fails with MissingError. **Expected behavior:** The timer opens, with the subtask's project and task prefilled. **Cause of the issue:** The frontend sends `currentState.active_id` regardless of the model it refers to. When the user navigates to a subtask via the smart button, `active_id` is the parent task's id. The systray controller then does `request.env['project.project'].browse(active_id)`, which returns a truthy recordset for an id that does not exist in `project_project`. Reading `.allow_timesheets` on that recordset triggers the DB fetch and raises MissingError. The same pattern exists in the `helpdesk_timesheet` override for both the `project.task` and `helpdesk.ticket` branches. **Fix:** Adding `.exists()` after the browse validates the recordset before any field access, so a stray `active_id` falls through to the task's own project (or ticket's project) instead of crashing. opw-6169548 Forward-Port-Of: odoo/enterprise#117039
This update resolves a bug where the Gantt view incorrectly displayed working hours for employees on public holidays. The fix converts all time zone calculations to UTC, ensuring accurate representation of unavailable time slots. This prevents employees from being incorrectly scheduled to work on holidays.
Original PR description
[FIX] hr_attendance_gantt: fix gantt view with public holidays Bug reproduction: 1 - Select flex schedule employee (or change its schedule to 40h flex one) and make its contract before 01/01/2026 2 -…
[FIX] hr_attendance_gantt: fix gantt view with public holidays
Bug reproduction:
1 - Select flex schedule employee (or change its schedule to 40h flex one) and make its contract before 01/01/2026
2 - Create a new public holiday on 01/01/2026 (from 00.00 to 23.59 or 23.55 (depends on version, it does not matter))
3 - in attendance app the cell from 00.00 to 01.00 seems white for that day and for selected employee (this cell seems like not holiday and employee can work)
Bug cause:
1 - After a long traceback, _gantt_unavailability in hr_attendance_gantt/HrAttendance, if an employee is flexible then unavailable_intervals is calculated with the Brussel time zone
2 - All other unavailable intervals are converted to the UTC in the function of _gantt_unavailability except in the final lines of the function.
3 - When the employee is flexible and since the conversion is not done in the final lines, it remains 1 hour more (UTC+1), it is from 1 am to 1 am of next day instead of 0 am to 23.59.
Bug solution:
1 - I converted the timezone to UTC to solve the problem.
task - 6067070
Forward-Port-Of: odoo/enterprise#112493