Project:
View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
ID | ||||||||
0029483 | ||||||||
Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||
defect | [Retail Modules] Web POS | major | always | 2015-03-31 18:47 | 2015-06-29 15:02 | |||
Reporter | migueldejuana | View Status | public | |||||
Assigned To | guilleaer | |||||||
Priority | normal | Resolution | fixed | Fixed in Version | ||||
Status | closed | Fix in branch | Fixed in SCM revision | |||||
Projection | none | ETA | none | Target Version | ||||
OS | Any | Database | Any | Java version | ||||
OS Version | Database version | Ant version | ||||||
Product Version | SCM revision | |||||||
Review Assigned To | migueldejuana | |||||||
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. | |||||||
Tags | No tags attached. | |||||||
Attached Files | diffIssue29483.diff [^] (1,476 bytes) 2015-06-25 11:59 [Show Content] | |||||||
Relationships [ Relation Graph ] [ Dependency Graph ] | ||||||||
|
Notes | |
(0078502) guilleaer (manager) 2015-06-25 11:59 edited on: 2015-06-29 15:00 |
Attached a temporal fix for Q1.1 This functionality will be refactored in next releases. |
(0078562) migueldejuana (developer) 2015-06-29 15:02 |
Reviewed |
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 | View Revisions |
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 |
Copyright © 2000 - 2009 MantisBT Group |