Openbravo Issue Tracking System - POS2 | |||||
| View Issue Details | |||||
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0057483 | POS2 | Core | public | 2024-12-18 12:44 | 2025-01-20 12:12 |
| Reporter | marvintm | ||||
| Assigned To | meriem_azaf | ||||
| Priority | normal | Severity | major | Reproducibility | have not tried |
| Status | scheduled | Resolution | open | ||
| Platform | OS | 5 | OS Version | ||
| Product Version | |||||
| Target Version | Fixed in Version | ||||
| Merge Request Status | |||||
| Review Assigned To | |||||
| OBNetwork customer | |||||
| Support ticket | |||||
| Regression level | |||||
| Regression date | |||||
| Regression introduced in release | |||||
| Regression introduced by commit | |||||
| Triggers an Emergency Pack | No | ||||
| Summary | 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. | ||||
| Additional Information | |||||
| Tags | No tags attached. | ||||
| Relationships | |||||
| Attached Files | |||||
| 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 | |||||
|
|
|||||
|
|
||||