Wednesday, December 31, 2025
2 changes · 17.0
Resolved issues and error corrections
This update resolves a crash that occurred when users switched tabs while a receipt was being generated in Point of Sale. The fix ensures the receipt component is reliably loaded and accessible, preventing the printing process from failing. This improves the overall reliability of the PoS system.
Original PR description
Steps to reproduce: ------------------- 1. Enable "Automatic Receipt Printing" so the receipt is auto printed after paying an order 2. From PoS, make an order, select it to invoice, and click the pay…
Steps to reproduce: ------------------- 1. Enable "Automatic Receipt Printing" so the receipt is auto printed after paying an order 2. From PoS, make an order, select it to invoice, and click the pay button. 3. While loading (normally a few seconds to finish the invoice), switch the tab and stay there for few seconds (the time the invoicing has finsihed). 4. Come back to the initial page, a traceback will appear and the ticket is not printed. Why it happens: --------------- The receipt is printed when the parent of the `OrderReceipt`, i.e. `RenderContainer` is rendered. In this case, we assume that `OrderReceipt` has already had the time to be mounted and thus it's in the DOM, so in this case, `this.ref?.el?.firstElementChild` has the order receipt. However, when switching the tab, and since OWL uses `requestAnimationFrame` as a scheduler, and since the browser will throttle `requestAnimationFrame` when the tab is not active, we will not have access to the order receipt component in its parent's `onRendered`! The fix ------- Instead of seeing the parent renders as a sign that its child has been successfully put in the DOM, we now renders the child component (OrderReceipt) in its own container and thus we can hook into its `onMounted` lifecycle where we know for sure that this component has been successfully mounted and attached to the DOM, and can be accessed through `this.ref?.el?.firstElementChild`. opw-5124585
This update fixes an issue where searching for serial numbers in the stock barcode view could return incorrect results. By adding a context, the system now correctly handles searches from the list view, ensuring more accurate and reliable stock tracking. This improves data integrity and user confidence.
Original PR description
Issue --> On the Lots/Serial Numbers view, with GS1 enabled, searching by a serial number can cause search arguments to get warped, unbeknownst to the end user. This can return unexpected results in the list view. Solution --> Add a context that skips the _preprocess_gs1_search_args method if the search is done from the list/graph view. This solution retains usage for any other purposes of the method. Community PR --> https://github.com/odoo/enterprise/pull/82989 opw-4574666