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

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0038912
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Retail Modules] Web POSmajoralways2018-07-06 10:582018-07-13 11:04
ReporteraaroncaleroView Statuspublic 
Assigned Tomigueldejuana 
PriorityhighResolutionfixedFixed in VersionRR18Q4
StatusclosedFix in branchFixed in SCM revisione9a618ea8184
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned Toguilleaer
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0038912: Using Synchronized Mode, a ticket can get stuck in WebPOS after being synchronized

DescriptionUsing synchronized mode, a ticket is not removed from the WebPOS after its synchronization is completed.
If the WebPOS is refreshed at any point during the synchronization, there is a field in localStorage (OB.UTIL.localStorage.getItem('synchronizedMessageId')) which tracks the last "synchronized transaction" and checks, after the login process has finished, the status of the last synchronization (calling the CheckProcessingMessage java process). If the last synchronized ticket was processed correctly, then it is removed from the WebPOS.

However, before removing the ticket, the WebPOS clears the synchronizedMessageId and then reloads the cashup from the server (which is an asynchronous call). If the user hits F5 again while the cashup is being reloaded, the ticket in web pos can no longer be checked against backend because the synchronizedMessageId doesn't exist.
Steps To ReproduceEnable the WebPOS Synchronized Mode preference.
Set a breakpoint in the OrderLoader, and another one in the Cashup process.
Login in web pos
Create a ticket and add some products.
Click on the total amount button to go to the payment tab.
Add the required payment and click in Done
When the breakpoint in the OrderLoader is hit, refresh the WebPOS. Validate any reload-related alerts in the browser.
Remove the OrderLoader breakpoint and let the order be synchronized.
When the WebPOS finishes loading, the Cashup breakpoint will hit.
Check in the browser console that the OB.UTIL.localStorage.getItem('synchronizedMessageId') field is null.
Reload the WebPOS again.
Now the POS will be loaded normally, but the ticket will remain in WebPOS, while also being synchronized in backend.
Proposed SolutionThe logic executed in WebPOS after calling CheckProcessingMessage should be reviewed to ensure that the synchronizedMessageId is not removed until the order has been correctly removed from WebPOS
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]

-  Notes
(0105699)
hgbot (developer)
2018-07-11 10:26

Repository: erp/pmods/org.openbravo.retail.posterminal
Changeset: e9a618ea81848fea4c1679b7e49e5a45df3ae3b1
Author: Miguel de Juana <miguel.dejuana <at> openbravo.com>
Date: Tue Jul 10 12:58:13 2018 +0200
URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/e9a618ea81848fea4c1679b7e49e5a45df3ae3b1 [^]

Fixed issue 0038912: Using Synchronized Mode, a ticket can get stuck in WebPOS after being synchronized

- Wait until rebuildCashup(asynchronous) is done to remove the id of the order from localstorage. We have to remove the order from the UI before removing synchronizedMessageId

---
M web/org.openbravo.retail.posterminal/js/login/model/login-model.js
---

- Issue History
Date Modified Username Field Change
2018-07-06 10:58 aaroncalero New Issue
2018-07-06 10:58 aaroncalero Assigned To => Retail
2018-07-06 10:58 aaroncalero Triggers an Emergency Pack => No
2018-07-11 10:26 hgbot Checkin
2018-07-11 10:26 hgbot Note Added: 0105699
2018-07-11 10:26 hgbot Status new => resolved
2018-07-11 10:26 hgbot Resolution open => fixed
2018-07-11 10:26 hgbot Fixed in SCM revision => http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/e9a618ea81848fea4c1679b7e49e5a45df3ae3b1 [^]
2018-07-11 10:38 guilleaer Review Assigned To => guilleaer
2018-07-11 17:56 migueldejuana Assigned To Retail => migueldejuana
2018-07-13 11:04 guilleaer Status resolved => closed
2018-07-13 11:04 guilleaer Fixed in Version => RR18Q4


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker