Anonymous | Login
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Retail Modules] Web POSmajoralways2012-09-06 17:402012-09-25 13:09
ReportermarvintmView Statuspublic 
Assigned Tomarvintm 
PriorityurgentResolutionfixedFixed in Version
StatusclosedFix in branchFixed in SCM revision2048cbce78b5
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

0021573: Change in local tables in different versions of the Web POS needs to be managed

DescriptionCurrently, the local tables are automatically created when a user logs in the Web POS initially, and then, are not touched again.

This will be a problem when subsequent versions of the Web POS (which will include changes in the structure of these tables) are released.

The structure of these tables needs to be updated (probably by droping and creating the tables again), when a change in the database version is detected.

Moreover, the unlikely but theoretically possible case of offline terminals which reconnect to an updated OB server needs to be managed, to prevent data loss in case of pending-to-be-sent tickets.
Steps To ReproduceThe problem will happen when users update to the next version of the POS.
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]

-  Notes
hgbot (developer)
2012-09-20 13:12

Repository: erp/pmods/org.openbravo.retail.posterminal
Changeset: 2048cbce78b51480bb0f3a91701f3d87f3040c6b
Author: Antonio Moreno <antonio.moreno <at>>
Date: Thu Sep 20 13:11:27 2012 +0200
URL: [^]

Fixed issue 21573. The following changes have been made:
- Now the database version change will be detected. If the version changed, the model tables will be dropped.
- To avoid losing data on the client side, a particular check will be done if a change is detected in the application cache: if there are no pending tickets, the page will be reloaded (at this point, a change in the database version will be detected, and the tables will be dropped). If there are pending tickets, a popup will be shown, and the user will be compelled to log in and complete his tickets. Once the page is reloaded, the database version change will be detected, and the tables will be dropped.

M src-db/database/sourcedata/AD_MESSAGE.xml
M src/org/openbravo/retail/posterminal/templates/cache-manifest.ftl
M web/org.openbravo.retail.posterminal/index.html
M web/org.openbravo.retail.posterminal/js/components/commonbuttons.js
M web/org.openbravo.retail.posterminal/js/data/dal.js
M web/org.openbravo.retail.posterminal/js/login/view/login.js
marvintm (developer)
2012-09-21 11:04

This issue has now been fixed, which means that the system will automatically recreate the database when the version of the database itself has changed.

It is very important that System administrators understand that it is their responsibility to ensure that all POS terminals have no pending tickets before updating the POS module. After the POS module has been updated, the client will display a warning to the user in case there are still pending tickets, and the user has only one shot to complete them. After that, the next time the page is reloaded, the application cache triggers in, and the database will be recreated, so all pending data will be lost.

- Issue History
Date Modified Username Field Change
2012-09-06 17:40 marvintm New Issue
2012-09-06 17:40 marvintm Assigned To => adrianromero
2012-09-06 17:41 marvintm Priority normal => urgent
2012-09-20 13:08 marvintm Assigned To adrianromero => marvintm
2012-09-20 13:12 hgbot Checkin
2012-09-20 13:12 hgbot Note Added: 0052259
2012-09-20 13:12 hgbot Status new => resolved
2012-09-20 13:12 hgbot Resolution open => fixed
2012-09-20 13:12 hgbot Fixed in SCM revision => [^]
2012-09-21 11:04 marvintm Note Added: 0052272
2012-09-25 13:09 adrianromero Status resolved => closed

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker