Openbravo Issue Tracking System - Retail Modules
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0057483Retail ModulesWeb POSpublic2024-12-18 12:442025-01-27 08:16
Reportermarvintm 
Assigned Tomeriem_azaf 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOS5OS Version
Product Version 
Target VersionFixed in VersionRR25Q2 
Merge Request Statusapproved
Review Assigned To
OBNetwork customerNo
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0057483: Sorting criteria is not applied consistently if IndexedDB master data cache is used
DescriptionCurrently 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 ReproduceOne 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 SolutionI'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.
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2024-12-18 12:44marvintmNew Issue
2024-12-18 12:44marvintmAssigned To => Triage Platform Base
2024-12-18 12:44marvintmOBNetwork customer => No
2024-12-18 12:44marvintmTriggers an Emergency Pack => No
2024-12-18 13:24marvintmProposed Solution updated
2025-01-13 10:04AugustoMauchAssigned ToTriage Platform Base => meriem_azaf
2025-01-20 10:32AugustoMauchStatusnew => scheduled
2025-01-20 12:12hgbotMerge Request Status => open
2025-01-20 12:12hgbotNote Added: 0174390
2025-01-26 12:22hgbotMerge Request Statusopen => approved
2025-01-26 12:23hgbotResolutionopen => fixed
2025-01-26 12:23hgbotStatusscheduled => closed
2025-01-26 12:23hgbotNote Added: 0174703
2025-01-26 12:23hgbotFixed in Version => RR25Q2
2025-01-26 12:23hgbotNote Added: 0174704
2025-01-27 08:16AugustoMauchProjectPOS2 => Retail Modules
2025-01-27 08:16AugustoMauchCategoryCore => Web POS

Notes
(0174390)
hgbot   
2025-01-20 12:12   
Merge Request created: https://gitlab.com/openbravo/product/pmods/org.openbravo.mobile.core/-/merge_requests/803 [^]
(0174703)
hgbot   
2025-01-26 12:23   
Merge request merged: https://gitlab.com/orisha-group/bu-commerce/openbravo/product/pmods/org.openbravo.mobile.core/-/merge_requests/803 [^]
(0174704)
hgbot   
2025-01-26 12:23   
Directly closing issue as related merge request is already approved.

Repository: https://gitlab.com/orisha-group/bu-commerce/openbravo/product/pmods/org.openbravo.mobile.core [^]
Changeset: 6703100eea1cffde195dfede9c0ec6b205ea7a94
Author: meriem azaf <m.azaf@orisha.com>
Date: 26-01-2025 10:46:30
URL: https://gitlab.com/orisha-group/bu-commerce/openbravo/product/pmods/org.openbravo.mobile.core/-/commit/6703100eea1cffde195dfede9c0ec6b205ea7a94 [^]

Fixes ISSUE-57483: Sorting criteria is not applied consistently if IndexedDB master data cache is used

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

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

---
M web/org.openbravo.mobile.core/app/model/persistence/indexeddb/IndexedDBQuery.js
---