Bug 1580535

Summary: Refresh of a second dynamic dialog does not update the hash passed to $evm.object['values'] when another dialog is referenced
Product: Red Hat CloudForms Management Engine Reporter: Robb Manes <rmanes>
Component: AutomateAssignee: eclarizi
Status: CLOSED ERRATA QA Contact: Shveta <sshveta>
Severity: high Docs Contact:
Priority: high    
Version: 5.9.0CC: cpelland, mkanoor, nansari, obarenbo, rovalent, rspagnol, simaishi, smallamp, sshveta, tfitzger
Target Milestone: GAKeywords: ZStream
Target Release: 5.9.3   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 5.9.3 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-07-12 13:15:10 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: CFME Core Target Upstream Version:
Embargoed:
Attachments:
Description Flags
disabled submit
none
dialog none

Description Robb Manes 2018-05-21 17:40:42 UTC
Description of problem:
=======================
When referencing dialog information from another dialog, pulling information from a "parent" dialog, child dialogs do not update in the UI however logging shows they are returning the right hash in the $evm.object['values'] hash.

If you create a dialog entry and have two drop-down menus, and create an automate method for the first that lists some option, if you have your second menu/automate method try to utilize the output of the first it will never change from the initial value, despite any refreshes performed on the dialogs.  Note that logs show that we are retrieving the correct values from the first dialog, but anything passed to the 'values' hash of the $evm.object object on the second dialog is ignored entirely.  Examples below.

Version-Release number of selected component (if applicable):
=============================================================
5.9.1.2

How reproducible:
=================
Every time

Steps to Reproduce:
===================
- Create a parent dialog utilizing an automate method like so:

$evm.object['values'] = {'' => 'Empty Set', 1 => 'Burger', 2 => 'Fries', 3 => 'Shake'}

- Then have a dialog rely on the above dialog's selections in another method:

parent_selection = $evm.root.attributes["dialog_dynamic_dialog_parent"]
$evm.log(:info, "DIALOG_DEBUG: child_dialog received #{parent_selection} from parent! #{parent_selection.class}")
menu = {'Burger' => 1, 'Fries' => 2, 'Shake' => 3}
value = {}

case parent_selection
  when menu['Burger'].to_s
    value[1] = 'Black Bean'
  when menu['Fries'].to_s
    value[1] = 'Sweet Potato'
  when menu['Shake'].to_s
    value[1] = 'Vanilla'
  else
    value[1] = 'Nothing selected for parent dialog'
end

$evm.log(:info, "DIALOG_DEBUG: child_dialog is returning values hash of #{value}")
$evm.object['values'] = value

- Observe as the 'child' dialog will never properly update, and forever show the output of "Nothing selected for parent dialog" when attempting to refresh the button.  Note that in the automate logs we do get the updated 

[----] I, [2018-05-21T13:18:42.415183 #2696:378933c]  INFO -- : Updated namespace [TestDialogs/TestDyanamicDialogs/child_dialog  TEST/TestDialogs]
[----] I, [2018-05-21T13:18:42.427181 #2696:378933c]  INFO -- : Invoking [inline] method [/TEST/TestDialogs/TestDyanamicDialogs/child_dialog] with inputs [{}]
[----] I, [2018-05-21T13:18:42.428334 #2696:378933c]  INFO -- : <AEMethod [/TEST/TestDialogs/TestDyanamicDialogs/child_dialog]> Starting 
[----] I, [2018-05-21T13:18:43.047862 #2696:51dbc8]  INFO -- : <AEMethod child_dialog> DIALOG_DEBUG: child_dialog received 1 from parent!
[----] I, [2018-05-21T13:18:43.048743 #2696:51dbc8]  INFO -- : <AEMethod child_dialog> DIALOG_DEBUG: child_dialog is returning values hash of {1=>"Black Bean"}
[----] I, [2018-05-21T13:18:43.081597 #2696:378933c]  INFO -- : <AEMethod [/TEST/TestDialogs/TestDyanamicDialogs/child_dialog]> Ending
[----] I, [2018-05-21T13:18:43.081775 #2696:378933c]  INFO -- : Method exited with rc=MIQ_OK

Despite the above log, observe that no change happens in the UI or via selection, in both the classic UI and the self-service UI.

Actual results:
===============
Child dialog never updates with new information from parent despite refreshing.

Expected results:
=================
Child dialog should update with new options based on option of parent dialog upon refreshing.

Comment 3 Tina Fitzgerald 2018-05-24 21:42:21 UTC
We think issue has been fixed with latest PRs. Waiting for QE to validate.

Comment 4 Shveta 2018-05-31 18:49:01 UTC
Not fixed in master.20180531005435_f827149

Appliance : https://10.8.199.197
Service - generic

Comment 5 eclarizi 2018-06-04 15:34:10 UTC
Shveta, I adjusted the automate method in your master reproducer and it appears to work to me. The automate method was referencing "dialog_dynamic_dialog_parent" but the name of the dialog field was simply "menu". After changing that, it behaves as expected.

Comment 6 Shveta 2018-06-04 17:53:32 UTC

The dialog works now after the changes made by Erik.

Method used 
====================
#parent_selection = $evm.root.attributes["dialog_dynamic_dialog_parent"]
parent_selection = $evm.root.attributes["dialog_menu"]

$evm.log(:info, "DIALOG_DEBUG: child_dialog received #{parent_selection} from parent! #{parent_selection.class}")
menu = {'Burger' => 1, 'Fries' => 2, 'Shake' => 3}
value = {}

case parent_selection
  when menu['Burger'].to_s
    value[1] = 'Black Bean'
  when menu['Fries'].to_s
    value[1] = 'Sweet Potato'
  when menu['Shake'].to_s
    value[1] = 'Vanilla'
  else
    value[1] = 'Nothing selected for parent dialog'
end

$evm.log(:info, "DIALOG_DEBUG: child_dialog is returning values hash of #{value}")
$evm.object['values'] = value

Comment 7 Shveta 2018-06-04 17:55:29 UTC
Created attachment 1447583 [details]
disabled submit

There is one issue though .
After pressing the second refresh , Refresh button for 'topping' dropdown, 
The submit button gets disabled .
master.20180531005435_f827149

Comment 8 Tina Fitzgerald 2018-06-04 18:40:41 UTC
Hi Shveta,

Thanks for the update.  We would track the new issue you encountered separately.
I'm going to update this issue as working in master, and we can retest on 5.9 when the new build is available.

Thanks,
Tina

Comment 9 Shveta 2018-06-07 21:53:27 UTC
Created attachment 1448898 [details]
dialog

Comment 10 Shveta 2018-06-07 21:54:38 UTC
Fixed in 5.9.3.1.20180606184006_8d120c0

Comment 12 errata-xmlrpc 2018-07-12 13:15:10 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:2184