Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0028584Openbravo ERPA. Platformpublic2015-01-13 12:332015-02-02 16:41
Reporterjecharri 
Assigned ToAugustoMauch 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusnewResolutionopen 
PlatformOS5OS Version
Product Version 
Target VersionFixed in Version 
Merge Request Status
Review Assigned To
OBNetwork customer
Web browserGoogle Chrome
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0028584: Auxiliary input vs display logic does not work fine in all the cases
DescriptionAuxiliary input vs display logic does not work fine in all the cases
Steps To Reproduce-Create an auxiliary input for window "Product - Product"
the validation code=@SQL=SELECT CASE when m_product_category_Id ='0C20B3F7AB234915B2239FCD8BE10CD1' then 'Y' else 'N' end FROM M_PRODUCt WHERE M_PRODUCT_ID = @M_PRODUCT_ID@

-Go to "windows, tabs and fields" and set the following display logic to field "brand" in product window "@Product_cat@='Y'"

When the product category is "Backpacks & Travel" the field brand will be displayed. White valley sampledata

The display logic works fine but it does not work when you are editing in form view. Attached a video
Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
has duplicate design defect 0025152 closed AugustoMauch Problems when using an auxiliary input in display logics 
Attached Fileszip 15_01_13_12_33_02.mp4.zip (2,548,525) 2015-01-13 12:33
https://issues.openbravo.com/file_download.php?file_id=7673&type=bug
Issue History
Date ModifiedUsernameFieldChange
2015-01-13 12:33jecharriNew Issue
2015-01-13 12:33jecharriAssigned To => AugustoMauch
2015-01-13 12:34jecharriFile Added: 15_01_13_12_33_02.mp4.zip
2015-01-13 12:34jecharriWeb browser => Google Chrome
2015-01-13 12:34jecharriModules => Core
2015-01-13 12:34jecharriResolution time => 1421276400
2015-01-13 12:34jecharriTriggers an Emergency Pack => No
2015-01-13 12:34jecharriWeb browserGoogle Chrome => Google Chrome
2015-01-13 12:34jecharriPriorityurgent => immediate
2015-01-13 12:42extraIssue Monitored: extra
2015-01-13 17:08alostaleWeb browserGoogle Chrome => Google Chrome
2015-01-13 17:08alostaleResolution time1421276400 =>
2015-01-13 17:08alostaleNote Added: 0073468
2015-01-13 17:08alostalePriorityimmediate => normal
2015-01-13 17:08alostaleTypedefect => design defect
2015-02-02 16:41alostaleWeb browserGoogle Chrome => Google Chrome
2015-02-02 16:41alostaleTarget Version3.0PR15Q2 =>
2016-09-02 08:28alostaleRelationship addedhas duplicate 0025152

Notes
(0073468)
alostale   
2015-01-13 17:08   
Moving to design defect: in order to properly implement it, it would be required to parse the SQL in the auxiliary input to detect which fields in the current window participate in that logic to mark those a dynamic columns. Once they are dynamic changes on them should trigger a backend call to recalculate the auxiliary input value.

== Alternative solution with current platform ==

Do not use an auxiliary input.

Instead set the displayLogic to something like:

myFunction(@M_Product_Category_ID@, item, form, currentValues, context)

where myFunction is a javascript function, in this way current parser would detect M_Product_Category_ID as dynamic and would invoke myFunction whenever it changes.

To implement myFunction:

If it is possible to evaluate the display logic synchronously based on local values, do it and return true if the field should be shown or false if not.

If it requires backend evaluation, implement like:

myFunction = function (newValue, item, form, currentValues, context) {
  var callback = function(data) {
    // evaluate here the display logic, item is the field to show/hide
    if (show) {
      item.show();
    } else {
      item.hide();
    }
  }
  invokeActionHandler(callback);
  return item.isVisible(); // keep visibility till callback is executed
}