Daily updates from Odoo
Tuesday, December 16, 2025
9 changes · master
Resolved issues and error corrections
This update fixes an issue where unscheduled shifts weren't immediately reflected in the Gantt view, requiring a page refresh. The change ensures shifts are updated instantly when unscheduled, improving scheduling accuracy and reducing user frustration. This improves the overall planning process.
Original PR description
**Steps to reproduce:** Go to planning gantt view. Click on shift. Click on unschedule button on popover. **Issue:** When clicking on Unschedule button on a shift popover, sometimes the shift still appears and again clicking on that it cause missing error occured until the page is refreshed. **Cause:** The record wasn’t updating in the view after a shift was unscheduled, so the unscheduled shift was still showing. **Fix:** Modified the method to reload the model and notify the view immediately after calling action_unschedule, ensuring shifts reflect the latest server state without requiring a manual refresh. task-5075381 Forward-Port-Of: odoo/enterprise#102010 Forward-Port-Of: odoo/enterprise#97108
This update resolves an issue that caused errors during call recording by correctly managing how the system listens for media streams. The change ensures the Odoo's SIP library functions properly, preventing disruptions and improving recording reliability. This enhances the overall call recording experience.
Original PR description
When recording a call, a traceback shows up because the current session uses `onTrack` to set a listener. This is a problem because `onTrack` is a property on the `peerConnection`, this means that it overrides the listener put by SIP library. This commit fixes that by using `addEventListener` instead so the original implementation of the SIP library is not overriden. The handler override was introduced in this PR: https://github.com/odoo/enterprise/pull/99168 Task-5379708
This update fixes an issue where Odoo wasn't correctly displaying replies to Tweets, leading to a double mention. The change aligns Odoo's Twitter reply interface with Twitter's native format, now showing "In reply to <user>" in feeds and related views. This ensures a consistent and user-friendly experience when interacting with Tweets.
Original PR description
Bug === When we reply to a Tweet, we want to show "In reply to <user>", in the feed view, in the modal for the "post" and the "comments". Task-3686630
This update resolves an issue where sick leave deferral calculations were inaccurate when a leave period extended across multiple months. The fix ensures correct deferral amounts are applied, improving the accuracy of payroll processing for employees with extended sick leave. This impacts the proper calculation of employee compensation.
Original PR description
The defer computation was not correct if the leave spans multiple months. This commit fixes it. Forward-Port-Of: odoo/enterprise#102188
This update resolves a bug that prevented refunds from being processed correctly for orders created with 'Consumidor Final Anónimo' customers in the POS system. The fix ensures proper error dialogs are displayed, preventing crashes and allowing refunds to be completed for this customer segment.
Original PR description
We had a bug when attempting to refund orders that were created with the "Consumidor Final Anónimo" customer. The refund validation would crash with a TypeError instead of showing the proper error…
We had a bug when attempting to refund orders that were created with the "Consumidor Final Anónimo" customer. The refund validation would crash with a TypeError instead of showing the proper error message. Steps to reproduce: ------------------- In POS with l10n_cl_edi module activated: * Create a new order with "Consumidor Final Anónimo" as customer * Add products and pay the order * Validate the order * Attempt to refund this order > Observation: The refund validation would crash with: TypeError: Cannot read properties of undefined (reading 'add') at OrderPaymentValidation.isOrderValid Why the fix: ------------ The code was trying to access `this.dialog` which is undefined in the OrderPaymentValidation class context. The dialog service should be accessed via `this.pos.dialog`, which is the correct pattern used throughout the base OrderPaymentValidation class. This fix ensures the error dialog is properly displayed when attempting to refund orders for the anonymous final consumer, instead of crashing with a TypeError. Forward-Port-Of: odoo/enterprise#101356
This update ensures that orders are immediately sent to the kitchen (PDIS) after a self-order payment is confirmed, regardless of whether the user sees a confirmation page. Previously, delays or missed confirmation pages could cause confusion. This change improves the reliability of order processing for self-order and kiosk transactions.
Original PR description
pos_online_payment* = pos_online_payment_self_order_preparation_display Task: [#5217268](https://www.odoo.com/odoo/project/1737/tasks/5217268) --- Previously, when an online payment was made, the…
pos_online_payment* = pos_online_payment_self_order_preparation_display Task: [#5217268](https://www.odoo.com/odoo/project/1737/tasks/5217268) --- Previously, when an online payment was made, the user was supposed to be redirected to a payment confirmation page which, once the transaction succeeded, sent the related order to the kitchen (PDIS). However, in some cases, the user never reaches this page. For example, the user may see the payment succeed in their banking app and close the tab before the redirection happens. For POS self-orders, we must send the order to the kitchen as soon as the payment is confirmed to avoid confusion between the customer, the cashier, and the kitchen staff. Relying solely on the confirmation page was therefore unreliable. --- To fix this, we now leverage the cron that post-processes payment transactions: we gather all transactions made in self-order or kiosk mode that are not yet post-processed, and send their corresponding orders to the kitchen. This ensures that orders reach the PDIS even when the user never lands on the confirmation page. Forward-Port-Of: odoo/enterprise#99249
This update automatically selects a failure location when a quality check fails, preventing incorrect stock movements and manual corrections. Previously, users had to manually choose a location, leading to errors and inconsistencies. This change ensures accurate stock tracking and reduces the risk of mistakes in quality control processes.
Original PR description
- When `failure location(s)` are configured on a `Quality Point`, users must manually choose one when failing a `quality check`. However, if the user forgets to select one, the failed quantities are incorrectly moved to the `stock location` instead of a `designated failure location`. - This results in incorrect stock moves and quantity values, requires manual corrections, and increasing the risk of mistakes. This improvement ensures that the quality check wizard automatically preselects the first available failure location whenever at least one exist, ensuring that failed quantities are correctly going to failure location even if user don't select one, which ensures consistency across all operation types, creates correct stock moves, and maintains accurate quantity values. Task ID: 4737111
This update addresses a requirement from FAIA version 2.01, which now mandates the inclusion of a 'PurchaseInvoices' tag in the generated SAFT XML reports for Luxembourg (`l10n_lu`) companies. Previously, vendor bills weren't correctly identified, leading to report discrepancies. This change implements a standardized template to ensure accurate reporting.
Original PR description
Since version 2.01 of FAIA, it is a requirement to include the `PurchaseInvoices` tag in the FAIA XML. With a `l10n_lu` company: - Create a vendor bill. - In the general ledger, download the FAIA XML report. In the generated XML document, the vendor bill will not appear under `PurchaseInvoices`. The `PurchaseInvoices` section is meant to mirror the `SalesInvoices` section and contains the exact same structure. This PR implements a generic template for both. **Specs and source** (in `FAIA_v2.01_full`): https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip opw-5360572 Forward-Port-Of: odoo/enterprise#102092 Forward-Port-Of: odoo/enterprise#100697
This update fixes an issue where refreshing a new offer page would reset the employee information, requiring users to re-enter details. The change ensures the correct employee context is maintained when the offer page is refreshed, improving the user experience and data accuracy. This prevents data entry errors and streamlines the offer creation process.
Original PR description
Steps to Reproduce ================== - Go to Employees - Choose an employee with no offers - Click on the "Offers - new" smart button (a form view will open with the correct employee name at the bottom) - Refresh the offer's page without saving (the employee field is emptied and the required Applicant field appears) Issue ================== The generate offer action that is triggered through the smart button returns a one-time action dictionary with the context. But that context is lost when we refresh the offer page as it's not saved anywhere. Fix ================== Replace the action dictionary with an action record for creating a new offer to ensure the context is maintained upon page refresh. Task-ID: 5059490