0058213: MasterData models with pagination by offset and multiple queries can lose records with high volumes

Description

When a masterdata model has multiple queries in its definition, it works with the standard pagination (by offset) and the queries return a high amount of records, the second query might not return all the information.
The ProcessHQLQuery.java file (in mobile.core) iterates the queries of each model and returns the data to the POS taking into account the page/batch size. When the first query finishes, the process fills the batch with the first results of the second query; to that end, it resets the offset to 0 inside the java itself. If these results fill the page and another request needs to be done for the second query, the offset is not recomputed properly in the POS side, so the second page of the second query is calculated with the global offset, which leads to records being missing from the database.

Among the existing masterdata models, the CharacteristicValue and all the translation models are subject to suffer this problem.

Steps To Reproduce

In a clean pos2-modules environment, the CharacteristicValue loads a total of 157 records, 3 from the first query and 154 from the second.
Log in POS and force a full refresh by clearing the cache. After logging in, check the CharacteristicValue table in IndexedDB and verify that it contains the expected 157 records.
Log in backoffice and change or create the "Masterdata models batch size" preference with value 50.
In POS, clear the cache again to force a new full refresh.
After logging in again, recheck the CharacteristicValue table and verify that there are now only 154 records.

Cause:
The first page (offset 0) is loaded with the 3 records from the first query and 47 from the second query.
The second page is loaded with 50 records from the second query, but starting from offset 50.
The third page is loaded with 50 records from the second query, starting from offset 100.
The fourth page is loaded with 4 records from the second query, starting from offset 150.
Records #48, #49 and #50 from the second query are lost because the offset is not changed after the first page is loaded

Proposed Solution

The ProcessHQLQuery.java already sends the information about the query change (it sends a queryIndex as part of the response). The POS code should take that queryIndex into accoung to adjust the offset when the queryIndex changes.

Also, for the Masterdata Translations Infrastructure, it would be nice to update the base TranslationMasterDataProcessHQLQuery to support pagination by id in its queries.

Issue History
Date Modified	Username	Field	Change
2025-03-12 11:27	aaroncalero	New Issue
2025-03-12 11:27	aaroncalero	Assigned To	=> Triage Platform Base
2025-03-12 11:27	aaroncalero	Triggers an Emergency Pack	=> No

Relationships [ Relation Graph ] [ Dependency Graph ]

Notes
There are no notes attached to this issue.