Project:
| View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
| ID | ||||||||
| 0049888 | ||||||||
| Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||
| design defect | [POS2] POS | major | sometimes | 2022-07-27 13:06 | 2024-05-27 16:11 | |||
| Reporter | asier_perez | View Status | public | |||||
| Assigned To | Retail | |||||||
| Priority | normal | Resolution | no change required | Fixed in Version | ||||
| Status | closed | Fix in branch | Fixed in SCM revision | |||||
| Projection | none | ETA | none | Target Version | ||||
| OS | Any | Database | Any | Java version | ||||
| OS Version | Database version | Ant version | ||||||
| Product Version | SCM revision | |||||||
| Merge Request Status | ||||||||
| Review Assigned To | marvintm | |||||||
| OBNetwork customer | No | |||||||
| Support ticket | ||||||||
| Regression level | ||||||||
| Regression date | ||||||||
| Regression introduced in release | ||||||||
| Regression introduced by commit | ||||||||
| Triggers an Emergency Pack | No | |||||||
| Summary | 0049888: Cash Up Error prevents from logging in after doing Cash Up, refresh page and trying to log in very quickly | |||||||
| Description | When doing Cash Up and then refreshing the page and logging in quickly, sometimes the next error message appears: 'There are cashup errors in this terminal'. It prevents from logging in again until the error is deleted from the database or backend. This is mainly due to application source code updates. When the source code is updated, the service-worker sends a message to the web to purge the state on refresh/login, that results in losing the local cashup, which allows us to work while we have errors in backend. | |||||||
| Steps To Reproduce | ## Updated steps to reproduce 1. Login WebPOS and complete a cashup(if you can complete it with errors better). 2. (For this step we need to have cashup errors in backend). Open DevTools by pressing F12 and clean the application state to simulate a source update. 3. Refresh the application and login, you'll see the "there are cashup errors in the terminal" because the local state has been purged due to an application update. ## Original steps to reproduce This error can be reproduced in live builds (POS2 with modules), and it could require several tries following the next steps. 0- Log in Web POS and leave a till open; this step prevents the Close Store dialog to appear later in POS2 and causes the cash up process to be faster, which is important to reproduce the error 1- Go to POS2 and log in 2- Do cash up normally and just after clicking on the 'Finish' button, press F5 to refresh the page 3- Repeat steps 1 and 2 until the error appears, preventing you to log in Note: For now, it is not very clear what the timing is to press F5, and the error could not occur after several tries. | |||||||
| Proposed Solution | TBD: An option would be to not purge the state entirely or keep some things between version updates. | |||||||
| Tags | No tags attached. | |||||||
| Attached Files |  cashUpError.json [^] (4,279 bytes) 2022-08-16 14:18 cashUpErrorMessage.txt [^] (1,495 bytes) 2022-08-16 14:27 [Show Content]
 cashup.png [^] (30,773 bytes) 2023-03-14 17:26
| |||||||
 Relationships [ Relation Graph ]
[ Dependency Graph ]
|
|
 Relationships |
|
Notes |
|
|
(0165153) AugustoMauch (administrator) 2024-05-27 10:36 |
This issue has been changed to Design Defect and reassigned to Retail because: - When sources are updated, the infra removes the local state, as it can be inconsistent with the updated sources. - As a consequence, in order to initialize the cashup, there is some POS business logic that tries to initialize the cashup from the backend, something that cannot happen because there were cashups in error From the infra point of view, resetting the state when sources are updated makes sense. This either will keep working like it is, or the POS team can think of doing something to initialize the cashup even when it is not possible to do it from the backend |
|
(0165176) marvintm (viewer) 2024-05-27 16:11 |
This is actually the expected behavior. There are two things to consider: - First, when a new version of Openbravo is deployed, we cannot guarantee that the local state in the POS will be compatible with the new sources. Therefore, we need to reset it, and as part of this reset, the POS will have to reload the Cashup information from the backend. - Second, it is not possible for the POS to load a reliable version of the Cashup information if there are Errors While Importing pending to be resolved in the backend. For these two reasons, it is very important to understand that there should never be Errors While Importing pending to be solved when a new version of OB is deployed. EWIs should never be considered a "normal" thing to exist in an production instance, they should always be solved whenever they appear, but particularly after a deployment it is an extremely important point to consider. Both CSU and Services teams are aware about this, and reviewing pending EWIs is part of the basic tasks they need to perform before a deployment is done. |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2022-07-27 13:06 | asier_perez | New Issue | |
| 2022-07-27 13:06 | asier_perez | Assigned To | => Retail |
| 2022-07-27 13:06 | asier_perez | File Added: reproduceCashUpError.spec.js | |
| 2022-07-27 13:06 | asier_perez | OBNetwork customer | => No |
| 2022-07-27 13:06 | asier_perez | Triggers an Emergency Pack | => No |
| 2022-07-27 14:00 | asier_perez | Summary | Error when executing Cash Up Cypress tests several times => Cash Up Error prevents from logging in after doing Cash Up and trying to log in very quickly |
| 2022-07-27 14:00 | asier_perez | Description Updated | View Revisions |
| 2022-07-27 14:00 | asier_perez | Steps to Reproduce Updated | View Revisions |
| 2022-07-27 14:00 | asier_perez | Proposed Solution updated | |
| 2022-07-27 14:01 | asier_perez | Description Updated | View Revisions |
| 2022-07-27 14:03 | asier_perez | Description Updated | View Revisions |
| 2022-07-27 14:03 | asier_perez | Description Updated | View Revisions |
| 2022-07-27 14:04 | asier_perez | Steps to Reproduce Updated | View Revisions |
| 2022-07-27 14:05 | asier_perez | Description Updated | View Revisions |
| 2022-07-27 14:07 | asier_perez | Steps to Reproduce Updated | View Revisions |
| 2022-07-27 14:08 | asier_perez | Steps to Reproduce Updated | View Revisions |
| 2022-07-28 09:34 | asier_perez | Steps to Reproduce Updated | View Revisions |
| 2022-07-28 09:46 | asier_perez | Severity | critical => major |
| 2022-07-28 09:46 | asier_perez | Steps to Reproduce Updated | View Revisions |
| 2022-07-28 09:54 | asier_perez | Description Updated | View Revisions |
| 2022-07-28 09:54 | asier_perez | Steps to Reproduce Updated | View Revisions |
| 2022-07-28 09:58 | asier_perez | Description Updated | View Revisions |
| 2022-07-28 10:21 | asier_perez | Steps to Reproduce Updated | View Revisions |
| 2022-08-16 11:04 | asier_perez | Steps to Reproduce Updated | View Revisions |
| 2022-08-16 14:18 | asier_perez | File Added: cashUpError.json | |
| 2022-08-16 14:27 | asier_perez | Description Updated | View Revisions |
| 2022-08-16 14:27 | asier_perez | File Added: cashUpErrorMessage.txt | |
| 2022-08-16 14:29 | asier_perez | Description Updated | View Revisions |
| 2022-11-28 16:04 | andre_montenegro | Summary | Cash Up Error prevents from logging in after doing Cash Up and trying to log in very quickly => Cash Up Error prevents from logging in after doing Cash Up, refresh page and trying to log in very quickly |
| 2022-11-28 16:04 | andre_montenegro | Description Updated | View Revisions |
| 2023-03-14 17:25 | asier_perez | Description Updated | View Revisions |
| 2023-03-14 17:25 | asier_perez | Steps to Reproduce Updated | View Revisions |
| 2023-03-14 17:25 | asier_perez | File Deleted: reproduceCashUpError.spec.js | |
| 2023-03-14 17:26 | asier_perez | File Added: cashup.png | |
| 2023-03-14 17:29 | asier_perez | Steps to Reproduce Updated | View Revisions |
| 2023-03-14 17:35 | asier_perez | Steps to Reproduce Updated | View Revisions |
| 2023-05-04 17:04 | AugustoMauch | Assigned To | Retail => cberner |
| 2023-05-18 17:53 | cberner | Description Updated | View Revisions |
| 2023-05-18 17:53 | cberner | Steps to Reproduce Updated | View Revisions |
| 2023-05-18 17:53 | cberner | Proposed Solution updated | |
| 2024-04-11 13:37 | asier_perez | Severity | major => critical |
| 2024-05-07 15:58 | lorenzofidalgo | Target Version | => 24Q2 |
| 2024-05-27 10:36 | AugustoMauch | Note Added: 0165153 | |
| 2024-05-27 10:36 | AugustoMauch | Assigned To | cberner => Retail |
| 2024-05-27 10:36 | AugustoMauch | Type | defect => design defect |
| 2024-05-27 10:36 | AugustoMauch | Steps to Reproduce Updated | View Revisions |
| 2024-05-27 10:36 | AugustoMauch | Status | new => acknowledged |
| 2024-05-27 12:24 | guillermogil | Severity | critical => major |
| 2024-05-27 12:24 | guillermogil | Target Version | 24Q2 => |
| 2024-05-27 16:07 | marvintm | Status | acknowledged => scheduled |
| 2024-05-27 16:11 | marvintm | Review Assigned To | => marvintm |
| 2024-05-27 16:11 | marvintm | Note Added: 0165176 | |
| 2024-05-27 16:11 | marvintm | Status | scheduled => closed |
| 2024-05-27 16:11 | marvintm | Resolution | open => no change required |
|
Issue History |
| Copyright © 2000 - 2009 MantisBT Group |
 |