Bug 1393001

Summary: [RFE] Add calling element ID to Dynamic Dropdown environment
Product: Red Hat CloudForms Management Engine Reporter: Jeff Warnica <jwarnica>
Component: AutomateAssignee: John Hardy <jhardy>
Status: CLOSED WONTFIX QA Contact: Shveta <sshveta>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.7.0CC: ekin.meroglu, jhardy, mkanoor, obarenbo, tfitzger
Target Milestone: GAKeywords: FutureFeature
Target Release: cfme-future   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: dialog:service
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-12-18 14:27:11 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Jeff Warnica 2016-11-08 16:38:49 UTC
add to $evm.root[attributes], e.g. `calling_ui_element`


Consider a multi-tiered service, with 3 VM's. The VM's themselves can be in different locations, and available templates are location dependent. The template dropdown is dynamic, and populated by code; the code itself is the same, but for knowing where to look up its search criteria. In this example, dialog_N_template is always keyed off dialog_N_location.

Currently, to implement, one would need to create three instances, e.g. list_vms_for_location_1, list_vms_for_location_2, list_vms_for_location_3, which have an instance variable like `fieldid`, calling into list_vms_for_location_n.

If the dynamic dropdown builder environment included the calling elements name, then this indirection would be unnecessary, and N could be found in code.

Alternatively, maybe even better, would be if the service dialog could pass in arbitrary URL args or JSON or something through the form builder.

Comment 2 Greg McCullough 2016-11-08 20:16:52 UTC
https://www.pivotaltracker.com/story/show/133956121