Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0028340Openbravo ERPA. Platformpublic2014-12-02 23:162022-02-01 08:08
Reporterjecharri 
Assigned ToTriage Platform Base 
PrioritynormalSeverityminorReproducibilityalways
StatusnewResolutionopen 
PlatformOS5OS Version
Product Version 
Target VersionFixed in Version 
Merge Request Status
Review Assigned To
OBNetwork customer
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0028340: The HQL Where clause in the selectors is not refreshing the current value
DescriptionThe HQL Where clause in the selectors is not refreshing the current value.

If you have a field that has OBUISEL selector reference and this this selector has a where clause depending in another value, if you change the value of this field the value of column with OBUISEL selector is not changeg
Steps To Reproduce-Install attached module
-Login as System
-Go to references window and change the "HQL Where clause" of "products" reference to
e.active='Y' AND e.isGeneric='N' AND e.productCategory.id=@inpmProductCategoryId@
-Login with admin role and go to selector window
-Select a product
-Verify that if you change the product category the product field is not updated and continue having a wrong value
Proposed SolutionI think that HQL Where clause should work as validations because it is not possible to assign a validation to one column that it is using OBUISEL_Selector reference
Additional Information
TagsNo tags attached.
Relationships
related to design defect 0019974 acknowledged Triage Platform Base When changing Organization, it shows the previously selected Business Partner. 
Attached Files? org.openbravo.selectors-1.0.0.obx (13,523) 2014-12-02 23:16
https://issues.openbravo.com/file_download.php?file_id=7570&type=bug
Issue History
Date ModifiedUsernameFieldChange
2014-12-02 23:16jecharriNew Issue
2014-12-02 23:16jecharriAssigned To => AugustoMauch
2014-12-02 23:16jecharriFile Added: org.openbravo.selectors-1.0.0.obx
2014-12-02 23:16jecharriModules => Core
2014-12-02 23:16jecharriResolution time => 1392418800
2014-12-02 23:16jecharriTriggers an Emergency Pack => No
2014-12-03 07:32alostaleResolution time1392418800 => 1423954800
2014-12-03 07:44alostaleRelationship addedrelated to 0019974
2014-12-10 12:08alostaleNote Added: 0072385
2014-12-10 12:08alostaleStatusnew => feedback
2015-01-27 08:55alostaleAssigned ToAugustoMauch => jonalegriaesarte
2015-02-02 13:31jonalegriaesarteAssigned Tojonalegriaesarte => jecharri
2015-02-16 11:21jonalegriaesarteResolution time1423954800 =>
2015-02-16 11:21jonalegriaesarteNote Added: 0074503
2015-02-16 11:21jonalegriaesarteAssigned Tojecharri => alostale
2015-02-16 11:21jonalegriaesarteStatusfeedback => new
2015-02-16 11:21jonalegriaesarteTypedefect => design defect
2017-04-10 14:35alostaleAssigned Toalostale => platform
2022-02-01 08:08alostaleAssigned Toplatform => Triage Platform Base

Notes
(0072385)
alostale   
2014-12-10 12:08   
So if a field that participates in the where clause is modified and selected value in the selector doesn't match the new restrictions, it is still preserved. Similar case is reported in 19974.

This would require of some UX decisions: what should happen in this case? the field with invalid value is nullified? should we have any visual hint for this? 2.50 drop downs work in this way: if the value is mandatory, new first available value in the drop down is selected; if not mandatory, it's nullified (I think).

Other consideration is how this would affect performance, note these expressions must be evaluated in backend, meaning that whenever there is a change in any field involved in any of these validations, additional requests would be triggered.

IMO, this issue is a design defect because all of the explained before + effort to implement it (which I think it could easily be more than 10 days).
(0074503)
jonalegriaesarte   
2015-02-16 11:21   
Moved to design defect