Bug 1408482 - A tag control element in a dialog called from a button is not passed to the button method
Summary: A tag control element in a dialog called from a button is not passed to the b...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Automate
Version: 5.7.0
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: GA
: 5.8.0
Assignee: Shveta
QA Contact: Shveta
URL:
Whiteboard: tag:dialog
Depends On:
Blocks: 1414014
TreeView+ depends on / blocked
 
Reported: 2016-12-23 16:54 UTC by Peter McGowan
Modified: 2017-06-12 16:19 UTC (History)
5 users (show)

Fixed In Version: 5.8.0.0
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1414014 (view as bug list)
Environment:
Last Closed: 2017-06-12 16:19:52 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
TagControl dialog field data in a text box (56.14 KB, image/png)
2017-01-09 07:27 UTC, eclarizi
no flags Details
Dialog to get TagID from a selected Tag (3.84 KB, text/x-vhdl)
2017-01-10 23:21 UTC, mkanoor
no flags Details
Automate Method to Fetch Tag ID given a Tag (171 bytes, text/plain)
2017-01-10 23:25 UTC, mkanoor
no flags Details
Tag ID (78.78 KB, image/png)
2017-04-28 17:55 UTC, Shveta
no flags Details

Description Peter McGowan 2016-12-23 16:54:30 UTC
Description of problem:
If I have a tag control element in a dialog that is called from a button, the tag value selected at the element does not seem to be passed to the called method (I would expect as either $evm.root['dialog_element_name'] or $evm.root['dialog_tag_<category>']). There seems to be no way of accessing the selected tag value from the called method.

Version-Release number of selected component (if applicable):
5.7.0.17.20161219135818_725f92f

How reproducible:
Every time


Steps to Reproduce:
1. Create a simple service dialog containing a single tag control element
2. Create a simple method that lists the attributes of $evm.root
3. Create a button on a VM object that calls the new service dialog, and runs the new method

Actual results:
Observe that $evm.root in the called method does not contain any reference to the tag control dialog element.


Expected results:
The value entered at the tag control element should be visible as $evm.root['dialog_<element_name>'] or $evm.root['dialog_tag_<category>']


Additional info:
The value entered from a service dialog tag control element called from a service (rather than a button) appears correctly as:

$evm.root['miq_request'].options[:dialog] = {"Array::dialog_location"=>"Classification::2"}

Comment 2 eclarizi 2017-01-09 07:27:25 UTC
Created attachment 1238576 [details]
TagControl dialog field data in a text box

Usually, from other elements within the dialog, you would access an element by doing:
$evm.root.attributes['dialog_<other_dialog_name>']. I was able to display a tag control field's contents in a text box by using that even after I tied the dialog to a button, but I'm not sure if that's similar to what you're expecting to do. See attached screenshot for what mine looks like.

How exactly are you setting up the button that calls the dialog that only contains the tag control and then running the method that is supposed to be able to access the dialog?

Comment 3 Peter McGowan 2017-01-09 15:28:29 UTC
Hi

The issue is not accessing the tag control element from another element's dynamic method, it's accessing the input of the tag control element from the method that's run when the button/dialog's 'Submit' button is pressed (i.e. the method implementing the button logic)

Comment 4 Peter McGowan 2017-01-09 15:31:44 UTC
For example, say I have button dialog that contains 2 elements, a tag control called 'tag', and a text box called 'text'. From the button method I can access the content of the text control box using $evm.root['dialog_text'], but there seems to be no corresponding $evm.root['dialog_tag']

Comment 5 eclarizi 2017-01-10 17:48:29 UTC
Hey Peter, I've talked it through with Greg and Madhu a bit, we're working on nailing down the exact cause, but for now as a workaround, can you try using $evm.root.attributes['dialog_tag'] and see if that works? In all of my local testing this seems to resolve the issue as a workaround, but it is definitely odd that the other field types work without the .attributes and tag is the only one that doesn't.

Comment 6 eclarizi 2017-01-10 21:37:17 UTC
Madhu and I have been trying to track this down and there's some difference in behavior from when I had my tag control field named "TagControl" versus "tag_control". Can you attach the automation.log after you run the custom button so we can see what's happening? Or perhaps even better, an export of the dialog you used along with the automate method?

Comment 7 mkanoor 2017-01-10 22:45:14 UTC
Peter,

There are a couple of key points when accessing tag from Automate Objects especially in use with dialogs

(1) The value is an Array of Tag objects, I am guessing this is because Tags can be multi selected
(2) To get a description you would have to fetch the description from the Tag object

e.g.

description = $evm.root['dialog_tag_control'].first.description

There is one bug in Automate Engine where it doesn't lowercase the special attribute names (the ones with the ::) which have the embedded class type.

e.g.
Array::dialog_Tag_Control=Classification::10000000000041&MiqServer::miq_server=10000000000016

dialog_Tag_Control is not being lowercased we are fixing that.

Thanks,
Madhu

Comment 9 mkanoor 2017-01-10 23:21:48 UTC
Created attachment 1239271 [details]
Dialog to get TagID from a selected Tag

Comment 10 mkanoor 2017-01-10 23:25:17 UTC
Created attachment 1239272 [details]
Automate Method to Fetch Tag ID given a Tag

In a new domain under /System/Request create a FetchTagID instance and point it to a FetchTagID automate method with the contents of the above file, which is basically

dialog = $evm.object
tag = $evm.root['dialog_TagControl'].first
if tag
  $evm.log(:info, "Tag ID #{tag.id} Description #{tag.description}")
  dialog["value"] = tag.id
end

Comment 11 CFME Bot 2017-01-12 14:06:15 UTC
New commit detected on ManageIQ/manageiq/master:
https://github.com/ManageIQ/manageiq/commit/c3379ae14e1daf8dccfe068883206e59a46dbec3

commit c3379ae14e1daf8dccfe068883206e59a46dbec3
Author:     Madhu Kanoor <mkanoor>
AuthorDate: Tue Jan 10 17:24:09 2017 -0500
Commit:     Madhu Kanoor <mkanoor>
CommitDate: Wed Jan 11 10:02:05 2017 -0500

    Inconsistent attribute names inside Automate Engine
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1408482
    
    Inside the Automate Engine we convert the attribute name for
     simple data types to lowercase, but for vmdb or Array types we dont
     convert the attribute name to lowercase.
    
    This PR converts all attribute names to lowercase.
    
    This is inconsistent.
    e.g. VM::VM=100&Name=fred
    
    would yield 2 attribute names VM and name. The "name" got converted to
    lowercase but VM didn't.
    
    When the methods access these variables using $evm.root we internally
    convert it to lowercase at access time
    
    $evm.root['VM']        gets converted to $evm.root['vm']
    $evm.root['vm']        gets converted to $evm.root['vm']
    $evm.root['Name']      gets converted to $evm.root['Name']
    
    If the caller passed in VM::VM=100&Name=fred
    $evm.root['VM'] fails because the method layer converts it to lowercase
    and internally it has preserved its original case
    
    This is not that prevalent since most of the attribute names that embed
    the class type are generated internally and they always lowercase the
    name. We have seen this manifest itself when using Tag controls using
    dialogs and the user names the tag with mixed case e.g.
    TagControl would be stored in the engine as dialog_TagControl but when
    the methods try to access $evm.root['dialog_TagControl'] the method
    layer would lowercase it and not find the attribute.

 .../engine/miq_ae_engine/miq_ae_object.rb                     |  4 ++--
 spec/lib/miq_automation_engine/miq_ae_object_spec.rb          | 11 +++++++++++
 2 files changed, 13 insertions(+), 2 deletions(-)

Comment 12 Peter McGowan 2017-01-15 17:19:09 UTC
I think you've fixed it, my mistake I was also using mixed-case element names for my testing. Thanks.

Comment 14 Shveta 2017-04-28 17:55:06 UTC
Created attachment 1274984 [details]
Tag ID

Using the method and dialog attached , created button on a VM .
Button uses the dialog attached .
When the button is executed , Tag Id's are correctly displayed .

Verified in 5.8.0.12-rc1.20170425180304_4f35996


Note You need to log in before you can comment on or make changes to this bug.