Openbravo Issue Tracking System - Retail Modules | ||||||||||||
View Issue Details | ||||||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | |||||||
0029483 | Retail Modules | Web POS | public | 2015-03-31 18:47 | 2015-06-29 15:02 | |||||||
Reporter | migueldejuana | |||||||||||
Assigned To | guilleaer | |||||||||||
Priority | normal | Severity | major | Reproducibility | always | |||||||
Status | closed | Resolution | fixed | |||||||||
Platform | OS | 5 | OS Version | |||||||||
Product Version | ||||||||||||
Target Version | Fixed in Version | |||||||||||
Merge Request Status | ||||||||||||
Review Assigned To | migueldejuana | |||||||||||
OBNetwork customer | ||||||||||||
Support ticket | ||||||||||||
Regression level | ||||||||||||
Regression date | ||||||||||||
Regression introduced in release | ||||||||||||
Regression introduced by commit | ||||||||||||
Triggers an Emergency Pack | No | |||||||||||
Summary | 0029483: When incremental is working, total button remains disabled for 1 minute | |||||||||||
Description | When incremental update is working, total button remains disabled for 1 minute in slow devices an it bothers users. Do we need to block total button when incremental update? If we have a product in the ticket and the incremental update remove it, do we process correctly the order(because we are processing an order with a removed product)? | |||||||||||
Steps To Reproduce | - Set incremental update every minute (POS Terminal Type window) - Login in a slow device - create an order and see how total button is disabled for a while without doing anything. | |||||||||||
Proposed Solution | I know that could be a corner case but I would manage it. Case: We have an opened order, we do an incremental refresh, something included in the order have changed in the master data. Solution: I will review the opened orders content and see if something have change, if something have changed, show a modal telling this and 2 options: - Delete the order and start creating the order again. - Process the order as it is in that moment. I know that it can be a bit hard but this should not happen very often and if it happens we must not let the user work with wrong data. | |||||||||||
Additional Information | ||||||||||||
Tags | No tags attached. | |||||||||||
Relationships |
| |||||||||||
Attached Files | diffIssue29483.diff (1,476) 2015-06-25 11:59 https://issues.openbravo.com/file_download.php?file_id=8228&type=bug | |||||||||||
Issue History | ||||||||||||
Date Modified | Username | Field | Change | |||||||||
2015-03-31 18:47 | migueldejuana | New Issue | ||||||||||
2015-03-31 18:47 | migueldejuana | Assigned To | => Retail | |||||||||
2015-03-31 18:47 | migueldejuana | Triggers an Emergency Pack | => No | |||||||||
2015-03-31 18:47 | migueldejuana | Relationship added | related to 0029396 | |||||||||
2015-06-23 13:26 | malsasua | Resolution time | => 1435356000 | |||||||||
2015-06-25 11:58 | guilleaer | Assigned To | Retail => guilleaer | |||||||||
2015-06-25 11:59 | guilleaer | File Added: diffIssue29483.diff | ||||||||||
2015-06-25 11:59 | guilleaer | Status | new => scheduled | |||||||||
2015-06-25 11:59 | guilleaer | Note Added: 0078502 | ||||||||||
2015-06-25 11:59 | guilleaer | Status | scheduled => resolved | |||||||||
2015-06-25 11:59 | guilleaer | Resolution | open => fixed | |||||||||
2015-06-29 15:00 | guilleaer | Note Edited: 0078502 | bug_revision_view_page.php?bugnote_id=0078502#r8932 | |||||||||
2015-06-29 15:02 | migueldejuana | Review Assigned To | => migueldejuana | |||||||||
2015-06-29 15:02 | migueldejuana | Note Added: 0078562 | ||||||||||
2015-06-29 15:02 | migueldejuana | Status | resolved => closed |
Notes | |||||
|
|||||
|
|
||||
|
|||||
|
|