0057665: Global mitigation is not working when there are messages not synced

Openbravo Issue Tracking System - Retail Modules
View Issue Details

ID	Project	Category	View Status	Date Submitted	Last Update
0057665	Retail Modules	Web POS	public	2025-01-16 13:04	2025-03-27 12:11

Reporter	malsasua
Assigned To	Retail
Priority	high	Severity	major	Reproducibility	always
Status	closed	Resolution	duplicate
Platform		OS	5	OS Version
Product Version
Target Version		Fixed in Version
Merge Request Status	open
Review Assigned To
OBNetwork customer	Gold
Support ticket	117967
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency Pack	No

Summary	0057665: Global mitigation is not working when there are messages not synced
Description	The global mitigation implemented in https://issues.openbravo.com/view.php?id=56377 [^] is not working when there are messages pending to sync. A similar fix of this issue https://issues.openbravo.com/view.php?id=57429 [^] should be implemented for the global mitigation
Steps To Reproduce	[offline] 1. create and complete ticket 2. do logout [online] 3. login -> back to the past happens 4. mitigation is triggered but the messages created in 1 was not synced yet duplicate doc number happens
Proposed Solution	We could implement the following change to handle this case: - We can add a new rule to the "Global mitigation" mechanism. - The new rule would check the list of pending orders to synchronize. If any of those orders has a "sequence" value for its document number, that is greater than the current sequence number in the state, then it means that the state has been corrupted. - In this case, we will not attempt to fix the state itself. Instead, following the principle of the global mitigation, we should just reset the state, and delegate on the standard mechanism that initializes the POS state from the initial state, from the information that is read from the backend. We need to test both the offline and the online cases. - In the case of online, the expectation would be that the POS is opened with a new state fully reinitialized from the information from the backend. - In the case of offline, the expectation would be that the state is reset, but then login is not possible, and the user is notified that an online login is required because there is data missing that must be loaded from the backend. In general it should be working already like this, but we need to explicitly test both cases to ensure that both work in this way.
Additional Information
Tags	No tags attached.
Relationships
Attached Files

Issue History
Date Modified	Username	Field	Change
2025-01-16 13:04	malsasua	New Issue
2025-01-16 13:04	malsasua	Assigned To	=> Retail
2025-01-16 13:04	malsasua	OBNetwork customer	=> Gold
2025-01-16 13:04	malsasua	Support ticket	=> 117967
2025-01-16 13:04	malsasua	Triggers an Emergency Pack	=> No
2025-01-16 19:29	Practics	Issue Monitored: Practics
2025-01-17 14:04	marvintm	Proposed Solution updated
2025-01-17 14:04	marvintm	Status	new => scheduled
2025-01-17 14:04	marvintm	Assigned To	Retail => ranjith_qualiantech_com
2025-01-20 13:57	hgbot	Merge Request Status	=> open
2025-01-20 13:57	hgbot	Note Added: 0174404
2025-01-20 13:57	hgbot	Note Added: 0174405
2025-01-20 13:57	hgbot	Note Added: 0174406
2025-02-13 14:02	marvintm	Note Added: 0175599
2025-02-13 14:02	marvintm	Type	defect => design defect
2025-02-14 01:55	hgbot	Note Added: 0175629
2025-02-14 01:55	hgbot	Note Added: 0175630
2025-02-14 01:55	hgbot	Note Added: 0175631
2025-02-15 18:19	ranjith_qualiantech_com	Assigned To	ranjith_qualiantech_com => Retail
2025-03-27 12:11	hgbot	Note Added: 0177492
2025-03-27 12:11	hgbot	Status	scheduled => closed
2025-03-27 12:11	hgbot	Resolution	open => duplicate

Notes