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-01-20 13:57 |
| Reporter | malsasua | ||||
| Assigned To | ranjith_qualiantech_com | ||||
| Priority | high | Severity | major | Reproducibility | always |
| 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 | 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 | 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 | |||
| Notes | |||||
|
|
|||||
|
|
||||
|
|
|||||
|
|
||||
|
|
|||||
|
|
||||