Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0057665
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Retail Modules] Web POSmajoralways2025-01-16 13:042025-01-20 13:57
ReportermalsasuaView Statuspublic 
Assigned Toranjith_qualiantech_com 
PriorityhighResolutionopenFixed in Version
StatusscheduledFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned To
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

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

DescriptionThe 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 SolutionWe 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.
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]

-  Notes
(0174404)
hgbot (developer)
2025-01-20 13:57

Merge Request created: https://gitlab.com/openbravo/product/pmods/org.openbravo.pos2/-/merge_requests/3386 [^]
(0174405)
hgbot (developer)
2025-01-20 13:57

Merge Request created: https://gitlab.com/openbravo/product/pmods/org.openbravo.core2/-/merge_requests/1727 [^]
(0174406)
hgbot (developer)
2025-01-20 13:57

Merge Request created: https://gitlab.com/openbravo/product/pmods/org.openbravo.mobile.core/-/merge_requests/804 [^]

- 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 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 Note Added: 0174404
2025-01-20 13:57 hgbot Note Added: 0174405
2025-01-20 13:57 hgbot Note Added: 0174406


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker