Openbravo Issue Tracking System - Retail Modules | ||||||||||||
View Issue Details | ||||||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | |||||||
0035078 | Retail Modules | Web POS | public | 2017-01-19 09:34 | 2017-03-03 14:31 | |||||||
Reporter | marvintm | |||||||||||
Assigned To | ranjith_qualiantech_com | |||||||||||
Priority | urgent | Severity | major | Reproducibility | always | |||||||
Status | closed | Resolution | fixed | |||||||||
Platform | OS | 5 | OS Version | |||||||||
Product Version | ||||||||||||
Target Version | RR16Q4.2 | Fixed in Version | RR16Q4.2 | |||||||||
Merge Request Status | ||||||||||||
Review Assigned To | marvintm | |||||||||||
OBNetwork customer | No | |||||||||||
Support ticket | ||||||||||||
Regression level | ||||||||||||
Regression date | ||||||||||||
Regression introduced in release | ||||||||||||
Regression introduced by commit | ||||||||||||
Triggers an Emergency Pack | No | |||||||||||
Summary | 0035078: Discounts priority is not properly taken into account if incremental refresh updates the discount information | |||||||||||
Description | Discounts defined in the system should be applied following order of priority. When the Web POS is initially loaded, this works correctly. However, if incremental refresh later on updates some discounts, this may stop working properly. The reason for this is that the query executed in the client-side doesn't contain an explicit order, which means that it implicitly uses the "_idx" property, automatically generated when records are loaded from the backend. The query in the backed does have proper order, so it works correctly on the first load. However, if incremental refresh is triggered and it either adds new discounts, or updates previously existing discounts, their corresponding value for the idx column will reset to 0, and in this case, their effective priority will no longer be valid. | |||||||||||
Steps To Reproduce | - Define two discounts over the same product, disc1 and disc2 (disc1 priority=20, disc2 priority=40). They should not have the "apply next discount" checked. - Log in the Web POS. Add the product to the ticket. Notice that the disc1 is applied. Delete the ticket. - Go to the backend. Change the disc2 name and save. - Go back to the web pos, and refresh the page (F5). - Add the same product again. Notice that now the disc2 is applied instead. This is wrong. | |||||||||||
Proposed Solution | In the executor.js file, in the query executed for the Discounts, an orderby of priority and id should be added. Once this is done, the problem will no longer happen. | |||||||||||
Additional Information | ||||||||||||
Tags | No tags attached. | |||||||||||
Relationships |
| |||||||||||
Attached Files | ||||||||||||
Issue History | ||||||||||||
Date Modified | Username | Field | Change | |||||||||
2017-01-30 09:46 | marvintm | Type | defect => backport | |||||||||
2017-01-30 09:46 | marvintm | Target Version | => RR16Q4.2 | |||||||||
2017-01-30 13:32 | hgbot | Checkin | ||||||||||
2017-01-30 13:32 | hgbot | Note Added: 0093933 | ||||||||||
2017-01-30 13:32 | hgbot | Status | scheduled => resolved | |||||||||
2017-01-30 13:32 | hgbot | Resolution | open => fixed | |||||||||
2017-01-30 13:32 | hgbot | Fixed in SCM revision | http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/c22376541cdcaed876f82bac2cb2faa2a87a08da [^] => http://code.openbravo.com/retail/backports/3.0RR16Q4.2/org.openbravo.retail.posterminal/rev/733e52f859deb95d899d05221af7bdbd4eed5df1 [^] | |||||||||
2017-01-30 13:33 | hgbot | Checkin | ||||||||||
2017-01-30 13:33 | hgbot | Note Added: 0093934 | ||||||||||
2017-03-03 14:31 | marvintm | Review Assigned To | => marvintm | |||||||||
2017-03-03 14:31 | marvintm | Status | resolved => closed | |||||||||
2017-03-03 14:31 | marvintm | Fixed in Version | => RR16Q4.2 |
Notes | |||||
|
|||||
|
|
||||
|
|||||
|
|