Daily updates from Odoo
Wednesday, June 24, 2026
10 changes · master
Resolved issues and error corrections
This update resolves an issue where duplicate preparation cards or tickets were sometimes generated when using the UrbanPiper POS integration. A recent code change introduced redundant order creation processes. The fix reuses the existing, reliable flow that checks if the order has been sent to the kitchen, preventing duplicates and ensuring accurate ticket generation.
Original PR description
Steps to reproduce: = * Create a POS configuration with UrbanPiper enabled. * Open a POS session. * Place and accept an UrbanPiper quick order. Issue: = * In some cases, two preparation cards or preparation tickets are generated for the same order. Reason: = * A recent refactor of the preparation order/preparation order line flow introduced multiple code paths that could trigger preparation order creation for the same order. Fix: = * Reused the existing preparation order creation flow that already checks whether the order has been sent to the kitchen/preparation display. * This prevents duplicate preparation order creation and avoids generating multiple preparation cards/tickets for the same order. task-6273306
This update fixes a bug in the Preparation Time report for Point of Sale, ensuring that preparation durations are displayed correctly based on the user's current timezone. Previously, the report always used the timezone of the system administrator, leading to inaccurate data. This change improves reporting accuracy and provides users with reliable preparation time insights.
Original PR description
In POS, the Preparation Time report groups average preparation durations by hour. Those hour buckets were always computed with the timezone of the user who ran the module upgrade (OdooBot /…
In POS, the Preparation Time report groups average preparation durations by hour. Those hour buckets were always computed with the timezone of the user who ran the module upgrade (OdooBot / superuser), not the timezone of the user viewing the report. Changing the user, company, or browser timezone had no effect on the graph until the module was upgraded again. Steps to reproduce: ------------------- * Configure a Preparation Display and create POS orders with measured preparation times. * Open Point of Sale → Reporting → Preparation Time. * Note the hour bucket used for the orders. * Change your user timezone in Preferences and reload the report. > Observation: The hour buckets stay the same. Before the fix, they only changed after upgrading `pos_enterprise`, because the timezone was embedded in the SQL view created during `init()` as superuser. Why the fix: ------------ Replace the static PostgreSQL view with a dynamic `_table_query` so `order_hour` is computed with the current user's timezone on each report read. `init()` now only drops the legacy view instead of recreating it with a frozen timezone. opw-6220248 Forward-Port-Of: odoo/enterprise#118365
This update fixes a confusing issue in the budget report where budget lines were labeled with repetitive names. The change now includes related analytic accounts in the display name, making budget lines much easier to distinguish and understand. This improves report readability and data analysis.
Original PR description
Budget report grouping by budget line displayed the budget name for every line, which made different lines indistinguishable and produced labels like "Budget 2026 x", "Budget 2026 x (2)", etc. Compute a more specific display name for budget lines by appending the analytic accounts concerned by the line to the budget name. Also expose Budget Line as a first-class group-by in the Budget Report search view and apply it by default when opening the report. task-6293065 Forward-Port-Of: odoo/enterprise#121204
This update automatically updates the map routes when a user changes their location. Previously, users had to manually refresh the map to see the correct routes. This improvement ensures a smoother and more accurate user experience when navigating maps within the Odoo Enterprise application.
Original PR description
In this commit, we ensure that the map is updated with the newly computed routes if the user position changes. Prior to this commit, the user had to manually trigger an update to correctly view the updated routes. Forward-Port-Of: odoo/enterprise#120966
This update resolves an issue where appointment filters were incorrectly persisting across different views (Kanban to Gantt). Now, filters are automatically cleared when switching views, ensuring accurate appointment display and preventing bookings from being hidden. This improves the user experience for managing appointments.
Original PR description
In this commit: - When switching from Kanban to Gantt view, the POS-specific filters `date_filter` and `hour_filter` (added by `PosAppointmentSearchFilter`) were persisting on the shared SearchModel, incorrectly hiding bookings. - Now these filters are removed when activating the Gantt view. - Clear these filters when changing views and add a tour test to cover the Kanban → Gantt navigation flow. Also extract common appointment view tour helpers for reuse. Task:6276594 Forward-Port-Of: odoo/enterprise#120368
This update resolves an issue where tours were behaving unpredictably. The team refined the triggers used in the tours to ensure they consistently activate when intended, leading to a smoother and more reliable user experience. This change focuses on internal improvements to the Odoo Enterprise application.
Original PR description
Fix undeterministic tours by making some triggers more precise in a few steps.
This update fixes a reporting issue where tax tags weren't correctly applied to invoices using group taxes. The change ensures that all child tax tags associated with a parent tax are included in generic reports, accurately reflecting tax calculations for Philippine businesses. This improves the reliability of financial reporting.
Original PR description
When using group taxes, the base invoice lines only store the parent tax in the `account_move_line_account_tax_rel` table. Because of this, if a child tax within the group contains a specific tax report tag (e.g., tag 33A on the SC/PWD exempt component introduced in the base localization), the generic report query would previously fail to pick up those base lines. This commit updates the SQL join conditions in `l10n_ph_generic_report.py` to also match `account_tax.id` against the child taxes of the linked parent tax using the `account_tax_filiation_rel` table. This ensures that base lines are correctly reported under the tags of their respective child taxes. Task-6032306 See: odoo/odoo#270764
This update fixes an issue where scanning an unknown barcode in the Point of Sale (POS) system didn't automatically open the product creation form. The fix removes a redundant check for API keys, ensuring the form opens correctly regardless of whether a barcode lookup key is configured. Users can now consistently create products by scanning barcodes.
Original PR description
When scanning an unknown barcode in POS, the product creation form was never opened because `barcode_lookup()` was called with no barcode as an implicit API key check. Commit 0c8019a4aa7 ([FIX] product_barcodelookup: avoid crash on invalid image URLs) standardized `barcode_lookup_request()` to always
return a `requests.Response` object, removing the `{'authenticated': True}` dict it previously returned for HTTP 404 responses. As a result the JS check `response?.authenticated` was always falsy and the form never opened.
Fix: remove the API key check entirely. `allowProductCreation()` already gates on the user having product create rights, which is the only condition that matters. If a Barcode Lookup API key is configured the `_onchange_barcode` on the form will auto-fill product data; if not, the user can fill it in manually. Either way the form is always usable.
opw-6295221
Forward-Port-Of: odoo/enterprise#120256This update streamlines the automatic onboarding tours within several Odoo modules (Helpdesk, Planning, Sale, Web Studio, and Knowledge) by removing unnecessary formatting wrappers. This fix resolves validation errors and ensures a smoother, more reliable onboarding experience for new users. The change also adds specific validation rules for onboarding tours.
Original PR description
…ntent
This update fixes an issue where report titles within Odoo Knowledge embeds were not consistently translated. The solution involves retrieving the report's name directly, streamlining the process and eliminating a previous fallback mechanism. This ensures accurate and localized report titles are displayed in Knowledge.
Original PR description
Problem: The title of the report is not translated properly in embeds in Knowledge. Considering how `data-embedded-props` are fed, I don't think we can directly feed the translated value that easily ? Possible solution: we have the report_id in options, we can just read the name ? Pro: we wouldn't even need to provide the report name in the first place (so that fallback thing is most likely useless). Cons: There's a bit of back-and-forth with the additional read. Should most likely be fixed in 19.0+ and not in master if we want to fix it. task-none (follow-up of discussion in https://github.com/odoo/enterprise/pull/120077#discussion_r3389814591)