Openbravo Issue Tracking System - Retail Modules
View Issue Details
0032014Retail ModulesLayaway orderpublic2016-01-26 14:142016-02-29 09:30
adrianromero 
adrianromero 
urgentmajorrandom
closedfixed 
5
 
RR16Q2 
marvintm
No
0032014: [SERQA 614]PaidReceipts java class has hardcoded the position for fields
In the java class PaidReceits, the query that returns the order lines has a dynamic list of fields base on the Model extension for HQL fields, as a consequence the number of fields depends on the modules that extends this model and the order of fields is not guaranteed. See: https://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/file/479da99eacfc/src/org/openbravo/retail/posterminal/PaidReceipts.java#l110 [^]

But when executing the query to retrieve the field values of the result set, the position is hardcoded. See for example: https://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/file/479da99eacfc/src/org/openbravo/retail/posterminal/PaidReceipts.java#l140 [^]

Then, depending on the number of modules installed that extends @Qualifier(PaidReceipts.paidReceiptsLinesPropertyExtension) the number and order of fields returned by this query may break the application when accessing an field by index.



In Description
Possible solutions:

* Refactor the java class Paid receipts to access field values by field name, not by index name.
* Set by code the first fields that will be access by index, and leave the rest using the Model Extension.
SER-QA
related to defect 0031607 closed adrianromero [HGVOL] Retail Best Sellers module does not work with HGVOL. 
Issue History
2016-01-26 14:14adrianromeroNew Issue
2016-01-26 14:14adrianromeroAssigned To => Retail
2016-01-26 14:14adrianromeroTriggers an Emergency Pack => No
2016-01-28 18:10adrianromeroReview Assigned To => marvintm
2016-01-28 18:10adrianromeroResolution time => 1454540400
2016-01-28 18:10adrianromeroPriorityimmediate => urgent
2016-01-28 18:10adrianromeroSeveritycritical => major
2016-01-28 18:10adrianromeroProposed Solution updated
2016-01-29 15:38OrekariaAssigned ToRetail => marvintm
2016-01-29 15:38OrekariaStatusnew => feedback
2016-02-01 10:45ageteSummaryPaidReceipts java class has hardcoded the position for fields => [SERQA 614]PaidReceipts java class has hardcoded the position for fields
2016-02-01 10:45ageteTag Attached: SER-QA
2016-02-01 10:46OrekariaNote Added: 0083772
2016-02-01 10:59adrianromeroRelationship addedrelated to 0031607
2016-02-01 11:01adrianromeroNote Added: 0083777
2016-02-01 13:53ranjith_qualiantech_comAssigned Tomarvintm => ranjith_qualiantech_com
2016-02-01 13:53ranjith_qualiantech_comStatusfeedback => scheduled
2016-02-01 18:16OrekariaTypedefect => design defect
2016-02-02 13:37OrekariaAssigned Toranjith_qualiantech_com => adrianromero
2016-02-02 13:37OrekariaStatusscheduled => feedback
2016-02-11 20:37hgbotCheckin
2016-02-11 20:37hgbotNote Added: 0084132
2016-02-11 20:37hgbotStatusfeedback => resolved
2016-02-11 20:37hgbotResolutionopen => fixed
2016-02-11 20:37hgbotFixed in SCM revision => http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/8ba19515818eb58f07a81ecf6ce05e1fb232489b [^]
2016-02-11 20:37hgbotCheckin
2016-02-11 20:37hgbotNote Added: 0084133
2016-02-26 10:06dmitry_mezentsevNote Added: 0084557
2016-02-29 09:30marvintmStatusresolved => closed
2016-02-29 09:30marvintmFixed in Version => RR16Q2

Notes
(0083772)
Orekaria   
2016-02-01 10:46   
We are discussing the possible solutions
(0083777)
adrianromero   
2016-02-01 11:01   
Just as a note: fixing issue 31607 I realized that not only order of fields is important but also in some cases there are duplicated fields ej isactive in the Products query.
(0084132)
hgbot   
2016-02-11 20:37   
Repository: erp/pmods/org.openbravo.retail.posterminal
Changeset: 8ba19515818eb58f07a81ecf6ce05e1fb232489b
Author: Ranjith S R <ranjith <at> qualiantech.com>
Date: Mon Feb 01 21:39:04 2016 +0530
URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/8ba19515818eb58f07a81ecf6ce05e1fb232489b [^]

Fixes issue 32014 : Removing hardcoded column indexes in PaidReceipts

The problem was that the results of the queries were paired based on the index of the column returned which prevent the queries to be extensible and could lead to nasty hidden errors

The solution has been:
- refactor to remove indexed fields and auto-discover fields
- the ProoductProperties duplicated field have been fixed
- the date conversion has been removed

TODO:
- non already extended queries have not been fixed and should be addressed before applying the refactor done in this issue

---
M src/org/openbravo/retail/posterminal/PaidReceiptRelatedLinesProperties.java
M src/org/openbravo/retail/posterminal/PaidReceipts.java
M src/org/openbravo/retail/posterminal/master/ProductProperties.java
---
(0084133)
hgbot   
2016-02-11 20:37   
Repository: erp/pmods/org.openbravo.mobile.core
Changeset: 0721e3e24cb2316aeb425bdd7c40287d7d629613
Author: Rafa Alonso <ral <at> openbravo.com>
Date: Tue Feb 09 16:30:39 2016 +0100
URL: http://code.openbravo.com/erp/pmods/org.openbravo.mobile.core/rev/0721e3e24cb2316aeb425bdd7c40287d7d629613 [^]

Related to issue 32014: Better support methods in the 'HQLPropertyList' class

The problem was:
- that the current support methods were not able to retrieve key - value pairs from the results returned from the database without the necessity to use an index
- that there was not method to return the array of the json objects in the result of a query

TODO:
- the method should verify that all the entries returned by the database are present in the properties list and warn when they are not

---
M src/org/openbravo/mobile/core/model/HQLPropertyList.java
---
(0084557)
dmitry_mezentsev   
2016-02-26 10:06   
Not closed for 15 days!