0057483: Sorting criteria is not applied consistently if IndexedDB master data cache is used

Description

Currently it is possible to specify a sorting criteria in a query executed on the Masterdata model. The problem is that this criteria is not applied consistently if the master data in-memory cache is used. This is functionally visible in case the query reaches the "limit" value, regardless of the limit being the hardcoded default (300) or a custom one specified in the criteria.

The reason this problem happens, is that the way the query is implemented when cache is used is:
- The in-memory cache is filtered by the criteria with the corresponding values of the properties and the logic specified
- The "limit" is then applied, so the array is truncated according to it
- Only then, the sorting criteria is applied

Steps To Reproduce

One way to reproduce this problem is to test product search with different values of the "Searching in WebPOS limit value for Products" preference. In an environment with a large number of products:
- First configure this preference to value 200 (for example), and do a product search returning more than 200 products
- Then configure it to a very low value (for example 10) and do the same search
- Verify that in the second search, instead of the first 10 products shown in the first search, different products appear

This should not happen, as the order should be always by product name, consistently over the whole set, so that the first 10 products ordered by name appear always.

Proposed Solution

I'm not sure if it is feasible to solve the problem in general, but I think a fix can be provided, which should cover 99% of the current functional cases in the POS.

I propose to change this part of the code:

https://gitlab.com/openbravo/product/pmods/org.openbravo.mobile.core/-/blob/master/web/org.openbravo.mobile.core/app/model/persistence/indexeddb/IndexedDBQuery.js?ref_type=heads#L205 [^]

It is currently:
- Filtering
- Slicing (applying the limit)
- Transforming (and as part of this, sorting happens)

We could make it a bit smarter:
- Filtering
- If sorting properties are present in the cache -> apply order on filtered results
- Slicing (applying the limit)
- Transforming

This will not solve all cases across the application, but my feeling is that most of the queries where limit applies and caching also applies, in practice in almost all the cases the sorted columns are part of the cache already, so this fix should cover them.

Issue History
Date Modified	Username	Field	Change
2024-12-18 12:44	marvintm	New Issue
2024-12-18 12:44	marvintm	Assigned To	=> Triage Platform Base
2024-12-18 12:44	marvintm	Triggers an Emergency Pack	=> No
2024-12-18 13:24	marvintm	Proposed Solution updated
2025-01-13 10:04	AugustoMauch	Assigned To	Triage Platform Base => meriem_azaf
2025-01-20 10:32	AugustoMauch	Status	new => scheduled
2025-01-20 12:12	hgbot	Note Added: 0174390

Notes
(0174390) hgbot (developer) 2025-01-20 12:12	Merge Request created: https://gitlab.com/openbravo/product/pmods/org.openbravo.mobile.core/-/merge_requests/803 [^]

Relationships [ Relation Graph ] [ Dependency Graph ]