The path towards more dynamic service dialogs

One of the more frequent feature requests that I have seen from ManageIQ end users is the ability to have more dynamic service dialogs. The dynamic drop-down field was recently added to address a certain use-case, but several other use cases are still unresolved. I am starting this thread to get the discussion flowing on how ManageIQ could better support the following use-cases that pop-up most frequently in my experience.

Unconstrained number of grouped fields
Using Foreman as an example, when you create a new host, you can keep adding network interfaces, resulting a new group of data fields appearing on the screen for specifying the details of the new interface (i.e. MAC, IP address, DNS). Attempting to do something similar in ManageIQ, you would have to pre-build and hard-code a limited set of network interface UI groups.

Several real-world requests for MIQ include the ability to deploy an N-tier service (where N is determined by the end-user); adding N number of database connection details to a PaaS appliance deployed via the service catalog; and N number of custom attributes / tags to apply to a service/VM.

One possible solution to address this use-case would be to add new attributes to the existing service dialog group to indicate that the group can be dynamically repeated and optionally a max number of times to support repeating it. If this option was enabled for a group, a new button for “Add New [Group Name]” would be placed near the bottom of the group, which would update the UI to add a new group. Any group dynamically created would have an “X” or remove button near the top to allow a user to undo his addition (similar to the Foreman behavior for NIC entry). The dialog field names would automatically have “_N” appended so that the dynamic UI values can be processed in automation.

All fields should support values and default values provided by automation
Currently, only the dynamic drop-down field can invoke automation. Instead, why not offer this feature for drop-down lists, radio buttons, text fields, text areas, and check boxes. The user would be offered a choice to provide static values (like current behavior), or they can specify that the field should be dynamically controlled via automation. Effectively this would mean the current dynamic drop-down field type would no longer be needed since the same behavior would be available with the standard list (or radio button).

Selecting a value in field A should automatically update the available choices in field B
The current dynamic drop-down list provides an optional refresh button. When pressed, it will re-invoke the associated automation, passing all current dialog values along with it. This allows a form to be created where the value of another field can impact the contents of the dynamic list (e.g. perhaps to filter the list using a substring from a text field). The field complaints about this current approach is that it requires the user to manually click the refresh button to see the new dynamic values. Instead, it would be desirable if a dynamic field could be tied to another field such that when the value of its associated field is updated, the dynamic field is automatically refreshed.

Disable fields that are not applicable for the current selections
Similar to the previous use-case, certain fields within a UI might only be applicable when other field has a specific value. For example, selecting that auto-scaling is disabled should automatically disable the fields relating to auto-scaling.


Hi Jason,

It sounds like there are 3-4 different feature requests in here related to dialogs.

Hopefully @gmccullough or @Fryguy can clarify if any of these features are possible today (perhaps with some customization) - for those which aren’t, I recommend creating an issue and tagging it as a feature request so that it can be considered for inclusion in a future roadmap.


@dneary I know none of these features exist at the moment. I wanted to start a discussion about the use cases and the possible ways to implement them within MIQ. I am looking to gather community consensus on a path forward.

Hey Jason, lots of great ideas here. Thanks for starting this topic.

Here are my initial thoughts:

Unconstrained number of grouped fields
The proposed solution here seems good. I think it would be good to add a counter variable for the group item when saving the fields to the options hash. We do not store information about the groups in the dialog options hash today, but I can see this being useful for the pending service-reconfigure PR when you need to reconstruction the dialog.

All fields should support values and default values provided by automation
Overall I like this idea as well. Performance through automate would be my biggest concern. If a user configured several fields we would likely need a way to do the work in parallel to achieve good UI response. However, that might conflict with your third item where fields are linked and interact with other fields. For example: If the automate script backing a UI element requires the values from other fields as input we will need to enforce an ordering or priority in which the fields get processed to ensure the require fields have been resolved first.

Selecting a value in field A should automatically update the available choices in field B
Two words: circular references. We need to ensure the UI does not allow fields to be configured in such a way that a circular reference of updates is introduced. Any thought to what would trigger the update for something like a text box? Each keystroke would be too often. (For some fields like drop-down lists and radio buttons it would simply be the selection changing.)

When implemented within the “Unconstrained number of grouped fields” feature I see 2 scenarios:

  1. All items are contained within the same group then they should only update items within that group. If a new copy of that group is created they would interact separately.
  2. If an item from one group is linked to an item inside another group. This gets complicated if one or both groups can be duplicated.

Disable fields that are not applicable for the current selections
Seems similar to the updating feature as far as configuration and would be exposed to similar concerns in relations to the “Unconstrained number of grouped fields” feature.