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

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0036790
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Retail Modules] Web POSmajoralways2017-09-05 13:192017-10-01 23:16
ReportermarvintmView Statuspublic 
Assigned Tomigueldejuana 
PriorityurgentResolutionfixedFixed in Version
StatusclosedFix in branchFixed in SCM revisionff6702c39ef0
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned Tomtaal
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0036790: Synchronized mode has problems when the request to the backend reaches timeout

DescriptionThere is a problem when using Synchronized mode, if the request to the backend reaches timeout.

The Web POS is blocked until that point, but after the timeout is reached, and a retry is performed, this retry returns with the information that the backend continues executing the process.

Once this happens, a popup is shown to the user informing of this fact. This is correct. However, the user can then close the popup, and start using the Web POS again, and this is incorrect, because as the process is still running, the terminal should continue to be blocked until it finishes.

This can lead to very painful errors, such as tickets being created after one is still being processed, and in this case, the Cashup information would become corrupted because the information loaded for this second ticket would lack the changes of the ticket which is still being processed.
Steps To Reproduce- Activate Synchronize mode
- Make sure you have more than one retry by default configured
- Put a breakpoint in the Orderloader class so that it never finishes
- Log in the Web POS. Create a ticket and complete it.
- Verify that the "Processing transaction" popup is shown
- After timeout is reached, a new request (retry) is performed
- After this request returns, another popup is shown explaining to the user that the request is still being processed.
- The user can close this popup, and continue working. This is wrong, because the order has not yet been synchronized, and the system should continue to be blocked.
- Moreover, if the user now tries to do another ticket, the cashup information will be come incorrect, as it will no longer contain the previous sale.
Proposed SolutionIf Synchronized mode is enabled, in this case the Web POS should continue to be blocked, until it can confirm that the order either was processed successfully in the backend, or failed with an error.
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]
related to defect 0036918 closedmigueldejuana In Synchronized Mode, doing F5 while and order is being loaded reaches a wrong scenario 
related to defect 0036925 newmigueldejuana In Synchronized Mode, doing F5 while and order is being loaded if the server goes down we get inconsistency 
has duplicate defect 0036323 closedmtaal When the server is processing a message still then do not execute success or failure on the client 
causes defect 0037210 closedmigueldejuana All requests in Synchronize Mode do retry. Just transactional requests should do it. 

-  Notes
(0099059)
hgbot (developer)
2017-09-15 10:14

Repository: erp/pmods/org.openbravo.mobile.core
Changeset: 45e0fff1629b9c6641757adfebd0ed81f552b9c3
Author: Miguel de Juana <miguel.dejuana <at> openbravo.com>
Date: Thu Sep 14 09:13:23 2017 +0200
URL: http://code.openbravo.com/erp/pmods/org.openbravo.mobile.core/rev/45e0fff1629b9c6641757adfebd0ed81f552b9c3 [^]

Fixed issue 0036790: Synchronized mode has problems when the request to the backend reaches timeout

- If the message send is processing, keep retrying till it is finished
- Update the text of Synchronized message modal with number o fretries information

---
M src-db/database/sourcedata/AD_MESSAGE.xml
M web/org.openbravo.mobile.core/source/data/ob-requestrouter.js
M web/org.openbravo.mobile.core/source/utils/ob-utilitiesui.js
---
(0099171)
marvintm (manager)
2017-09-20 12:55

The current solution works fine, except in the case the system was configured to have 0 retries. In that case, when the timeout is reached, the popup disappears, and this is not correct, as the receipt is still being processed.
(0099462)
hgbot (developer)
2017-09-22 10:10

Repository: erp/pmods/org.openbravo.mobile.core
Changeset: ff6702c39ef0dc4cff3dde8d4518e38a691f5fc6
Author: Miguel de Juana <miguel.dejuana <at> openbravo.com>
Date: Thu Sep 21 16:29:55 2017 +0200
URL: http://code.openbravo.com/erp/pmods/org.openbravo.mobile.core/rev/ff6702c39ef0dc4cff3dde8d4518e38a691f5fc6 [^]

Fixed issue 0036790: Synchronized mode has problems when the request to the backend reaches timeout

- Change args setting because it come come from server with different structure
- If the request fail in the last server being in synchronize mode without retries set, keep asking the server also

---
M web/org.openbravo.mobile.core/source/data/ob-requestrouter.js
M web/org.openbravo.mobile.core/source/model/ob-terminal-model.js
---
(0099689)
mtaal (manager)
2017-10-01 23:16

reviewed and tested

- Issue History
Date Modified Username Field Change
2017-09-05 13:19 marvintm New Issue
2017-09-05 13:19 marvintm Assigned To => Retail
2017-09-05 13:19 marvintm Triggers an Emergency Pack => No
2017-09-15 10:14 hgbot Checkin
2017-09-15 10:14 hgbot Note Added: 0099059
2017-09-15 10:14 hgbot Status new => resolved
2017-09-15 10:14 hgbot Resolution open => fixed
2017-09-15 10:14 hgbot Fixed in SCM revision => http://code.openbravo.com/erp/pmods/org.openbravo.mobile.core/rev/45e0fff1629b9c6641757adfebd0ed81f552b9c3 [^]
2017-09-15 11:56 marvintm Assigned To Retail => migueldejuana
2017-09-20 12:55 marvintm Note Added: 0099171
2017-09-20 12:55 marvintm Status resolved => new
2017-09-20 12:55 marvintm Resolution fixed => open
2017-09-21 15:27 migueldejuana Relationship added related to 0036918
2017-09-22 10:07 migueldejuana Relationship added related to 0036925
2017-09-22 10:10 hgbot Checkin
2017-09-22 10:10 hgbot Note Added: 0099462
2017-09-22 10:10 hgbot Status new => resolved
2017-09-22 10:10 hgbot Resolution open => fixed
2017-09-22 10:10 hgbot Fixed in SCM revision http://code.openbravo.com/erp/pmods/org.openbravo.mobile.core/rev/45e0fff1629b9c6641757adfebd0ed81f552b9c3 [^] => http://code.openbravo.com/erp/pmods/org.openbravo.mobile.core/rev/ff6702c39ef0dc4cff3dde8d4518e38a691f5fc6 [^]
2017-09-22 14:28 marvintm Resolution time => 1506636000
2017-09-27 09:10 mtaal Review Assigned To => mtaal
2017-10-01 23:16 mtaal Note Added: 0099689
2017-10-01 23:16 mtaal Status resolved => closed
2017-10-02 10:20 mtaal Relationship added has duplicate 0036323
2017-11-02 15:12 migueldejuana Relationship added causes 0037210


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker