Wednesday, September 23, 2026
3 changes · 19.0
Enhancements to existing features
Users can now manage IAP-related settings, such as credit purchases, low balance warnings, auto-refill, and SMS options, from one dedicated page. This reduces switching between different configuration areas and makes paid service management easier to understand and maintain.
Original PR description
This commit aims at improving how users interact with IAP. Instead of having to configure some details (low balance warnings, auto-refill, SMS) on its db, and others on IAP (buying of credits), we will now present to the user a new IAP page (served by the IAP server) where he/she can manage everything in a single place. task-6128821 Partial backport of https://github.com/odoo/odoo/pull/269021
This update reduces the number of products processed when preparing barcode stock data. It should make barcode-based inventory workflows faster and more efficient, especially when handling larger product sets.
Original PR description
`_get_stock_barcode_data` currently does a union to get a set of products to compute on, this set of products is currently much larger than it needs to be. I'll update with more when I can.
Point of Sale now calculates customer amounts due in one batch instead of repeating the same work for every cached customer. This reduces database load and helps stores open sessions faster, avoiding slowdowns on large production systems.
Original PR description
Issue ----- Opening a PoS sends every partner cached on the device to `get_all_total_due`. On a production database, six of those calls within 30 minutes ran 7061 queries, the worst one 4837 queries…
Issue ----- Opening a PoS sends every partner cached on the device to `get_all_total_due`. On a production database, six of those calls within 30 minutes ran 7061 queries, the worst one 4837 queries in 46.7 seconds, keeping a worker busy for the whole duration and slowing down the entire system. Cause ----- `get_all_total_due` loops over the recordset and calls `get_total_due` once per partner. Each iteration runs its own `pos.order` search for the open pay later orders and re-reads `point_of_sale.group_pos_user`, hence exactly two queries per partner. Every other value the method needs (`total_due`, `pos_orders_amount_due`, `invoices_amount_due` and the `_load_pos_data_read` payload) is already computed for the whole recordset at once by the ORM prefetching, so only those two remained unbatched. That search is also the expensive one: `commercial_partner_id` is not indexed, so each of them scans the whole set of orders in state 'paid'. Fix ----- Move the computation to `_get_total_due_data`, which queries the orders, the pay later payments and the partners data once for the whole recordset. `get_total_due` and `get_all_total_due` keep their signature and their return value, and both delegate to it. Measured on a database with 300k pos orders, for 1000 partners: 2193 queries / 3.98s before, 16 queries / 0.27s after. opw-6530561