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

View Issue Details[ Jump to Notes ] [ Issue History ] [ Print ]
ID
0041196
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Retail Modules] Web POSminoralways2019-06-27 17:372019-07-11 18:57
ReporterasiermartirenaView Statuspublic 
Assigned Toasiermartirena 
PrioritynormalResolutionfixedFixed in VersionRR19Q4
StatusclosedFix in branchFixed in SCM revision741ba45e7f60
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned Toadrianromero
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0041196: When the multi order process fails in the preOrderSave hook, it is not correctly managed

DescriptionWhen the preOrderSave hook fails in the pay open tickets flow, the payments and tickets must return back to a initial state. Here there are two possibilities: Synchronized mode or not.
Without the synchronized mode, that means in the common mode, the orders must not return back fully to an initial status. Just the needed properties must return back to the initial status. In addition, the orderlist models must be updated. In this case, as the reference is the same to the multiorder object, won't be needed.
In the other hand, with synchronized mode, after the process fails, the order must return back to an initial status. For this purpose, the order must be fully restored with the frozen order, instead of just updating some properties. The orderlist records must also be updated, to use the new references.

For payments, is also necessary to restore fully to it's initial value.
Steps To ReproduceExecute a Pay Open Tickets flow and force the preOrderSave to fail.

Check that the orders are not correctly restores --> In the case of the common mode the order list models and multi order models are not now referencing to the same object. With synchronized mode, the same problem. Also, some values that have been modified during the preOrderSave hook have not been restored to it's initial value.

In payments --> Realize that only the origAmount property has been restored. The amount is still set to zero.
TagsNo tags attached.
Attached Files

- Relationships [ Relation Graph ] [ Dependency Graph ]
related to defect 0041271 closedasiermartirena Layaways can generate shipments when the synchronization process have some failure 

-  Notes
(0113161)
hgbot (developer)
2019-07-03 18:24

 Repository: erp/pmods/org.openbravo.retail.posterminal
Changeset: 741ba45e7f60034549e4772c0c00f6877b735393
Author: Asier Martirena <asier.martirena <at> openbravo.com>
Date: Wed Jul 03 18:24:13 2019 +0200
URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/741ba45e7f60034549e4772c0c00f6877b735393 [^]

Fixed issue 41196: When the multi order process fails in the preOrderSave hook, it is not correctly managed

Now, when the pay open tickets flow fails during the preOrderSave hook, the order data is restored depending on the synchronized mode status.
If the synchronized mode is disabled, instead of restoring the order model to the frozen model, only those needed properties are set to the initial status.
In synchronized mode, the full order is restored. This means that the backbone model is fully changed. In addition, now the order list model is also restored (updated) to the frozed model, maintaining the same object in both orderList and multiOrder lists.
In addition, payments are always fully restored to the frozen status. Up to now, only the 'origAmount' was restored, having, for example, the property 'amount' with value zero after the values were restored.

If the preOrderSave hook fails, the Web POS waits until all orders have been treated until they are restored, to avoid to restore data in and then to modify the order after that.

---
M web/org.openbravo.retail.posterminal/js/data/dataordersave.js
---
(0113256)
adrianromero (manager)
2019-07-10 14:58

 Verified
(0113304)
guilleaer (manager)
2019-07-11 18:57

 reclosed

- Issue History
Date Modified Username Field Change
2019-06-27 17:37 asiermartirena New Issue
2019-06-27 17:37 asiermartirena Assigned To => asiermartirena
2019-06-27 17:37 asiermartirena Triggers an Emergency Pack => No
2019-07-03 18:24 hgbot Checkin
2019-07-03 18:24 hgbot Note Added: 0113161
2019-07-03 18:24 hgbot Status new => resolved
2019-07-03 18:24 hgbot Resolution open => fixed
2019-07-03 18:24 hgbot Fixed in SCM revision => http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/741ba45e7f60034549e4772c0c00f6877b735393 [^]
2019-07-09 14:09 adrianromero Relationship added related to 0041271
2019-07-10 14:58 adrianromero Review Assigned To => adrianromero
2019-07-10 14:58 adrianromero Note Added: 0113256
2019-07-10 14:58 adrianromero Status resolved => closed
2019-07-10 14:58 adrianromero Fixed in Version => RR19Q4
2019-07-11 15:31 hgbot Checkin
2019-07-11 15:31 hgbot Note Added: 0113277
2019-07-11 15:31 hgbot Status closed => resolved
2019-07-11 15:31 hgbot Fixed in SCM revision http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/741ba45e7f60034549e4772c0c00f6877b735393 [^] => http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal-discounts/rev/741ba45e7f60034549e4772c0c00f6877b735393 [^]
2019-07-11 18:56 guilleaer Note Deleted: 0113277
2019-07-11 18:57 guilleaer Note Added: 0113304
2019-07-11 18:57 guilleaer Status resolved => closed

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker