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.