Thursday, October 16, 2025
3 changes · 18.0
Enhancements to existing features
Refreshing UrbanPiper webhooks from settings now also disconnects existing products from the POS and sends a fresh menu update to UrbanPiper. This helps keep the external delivery platform aligned with the latest point-of-sale menu data.
Original PR description
Following this commit: - On refreshing webhooks from settings, products will be unlinked from pos. - Fresh menu will be updated to Urbanpiper platform task-5163764
Changing inventory valuation settings on very large product categories is now much faster. This helps businesses avoid long waits or timeouts when updating stock valuation methods for categories with many product variants.
Original PR description
Changing a product.category's valuation from manual to real-time or real-time to manual does mainly two things. The first one is emptying the current stock and valuation. The second is to replenish…
Changing a product.category's valuation from manual to real-time or real-time to manual does mainly two things. The first one is emptying the current stock and valuation. The second is to replenish the stock according to the new valuation. This process can be heavy when the number of product.products related to the active product.category is big. This can happen when product.attributes are set to "Creation: Instantly" for instance. This commit aims at improving the overall speed of this change in some cases. A first optimization is to use `product_tmpl_id` to retrieve the `product_variant_ids`. When there are a lot of products, it's faster to explicitely use the delegated field `product_tmpl_id`. This avoids lots of calls to `__getitem`/`__setitem__` in `_compute_related`. The downside of doing this is that subsequent calls to `self.product_variant_ids` are gonna raise a CacheMiss. So we have to explicitely use `product_tmpl_id.product_variant_ids` every time. We argue that it's not really an issue here as retrieving the variant_ids from a product.product itself is not that frequent in the codebase. A second optimization is to avoid calling `product.qty_available` in `_compute_value_svl` in case `avg_cost = 0`. With an avg_cost of 0, the total_value is always going to be 0. So there's no point in calling the heavy compute method `_compute_quantities` to retrieve `qty_available` here. #### speedup In a database with 228 000 product.products linked to the same product.category, the time to switch the category valuation from manual to real-time: +15min (timeout) -> 18s --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website editor now detects when a browser or device cannot support image filters and disables that option instead of showing an error. This keeps editing stable for users on systems without WebGL support, such as some Linux Chrome setups.
Original PR description
On recent versions of Chrome for Linux (v140+), the old SwiftShader software fallback for WebGL has been removed. As a result, new window.WebGLImageFilter() now throws if no GPU context is available, typically when WebGL is disabled or unsupported. Since the application cannot enable WebGL from JavaScript, this commit improves the user experience by detecting the absence of a WebGL context early and disabling image filters in edit mode. Instead of raising a traceback, the editor now skips the filter feature and can optionally display a friendly message explaining that WebGL is required to use image filters. This avoids runtime errors and ensures a more robust behavior on platforms where WebGL is unavailable. task-5117584 Forward-Port-Of: odoo/odoo#229705