GUI user friendly Array input Job templates

Job templates can require user supplied parameters at the time of execution.

Currently the available GUI elements for this parameter input include a drop down list, a check mark, and a free from text field.

This only leaves the free form text field for user supplied arrays. When users should supply an array comprised of some subset of a fixed list of allowed values, this is really error prone.

What are your thoughts on introducing some kind of “multiple selection” GUI elements for user supplied arrays at job template execution time?

Does anyone have any ideas how much work that would be? Do you consider it a worthwhile feature? Should I open a feature request for it in the issue tracker?

The “multiple selection” input field I know from elsewhere in the Foreman UI, is the one that allows you to add entities to Organizations and Locations for example (two lists where selection means moving elements from the list on the left to the list on the right). If we were to go ahead with this feature would we reuse that same UI element or something else? (Perhaps a drop down list that allows multiple selection).

Looking forward to your thoughts.

1 Like

What would be the use case? When would I as an user would want to select multiple items from a predefined list?

I’m not a huge fan of the dual list approach, especially if the number of options can be high. It also wouldn’t really fit neither into the form we have right now nor into the new one which is in the works. Having something like multiple select from pf4 could be nice and hopefully would scale better and fit into the form better than the dual list.

I read this as something where you have free form multiple inputs. Let’s say you have some input form to install multiple packages. Then you will have one entry with vim, the next with git and a third with xeyes. I don’t think we have such an element today but it makes a lot of sense to me. Today we often handle this in code by splitting on something but properly separating them makes sense to me.

I guess my understanding of job templates is that they can be used to do “arbitrary stuff” while also providing a GUI user friendly interface (like drop down lists) for interacting with the “arbitrary stuff” that they contain. My thinking is that since “arbitrary stuff” could easily involve user supplied arrays, it would be nice to have something equally user friendly as a drop down list for array input. (Rather than demanding a comma separated list in a free form text field for example). Our concrete use case that prompted our internal discussion was a Job template that runs an Ansible role which requires some list type parameters. (I am aware there are other ways to run Ansible roles within Foreman).

+1 to preferring something more widely used to the dual list approach. I only wanted to mention the dual lists as an existing example and a starting point for discussion. :wink:

I think both “free form multiple inputs” as well as “multiple inputs from a pre-defined list” could independently make sense. Like I said, to me Job templates are something where an advanced user or administrator can write arbitrary code, that is then executed by an ordinary user via an easy to use GUI interface. The proposal is just to have a full range of options for what that “easy to use GUI interface” can contain as input elements.

I went to look for input types on PatternFly 4 but it’s really hard. Bootstrap does it much better by having Forms · Bootstrap v5.0.

I tried to find an input element where items are grouped but I’m not sure if it’s good UX in this case, but it’s what’s often used in fields with multiple tags. Would that make sense here?

I think the good input type we already sort of have in the app is patternfly typeahead. @ezr-ondrej added something like that for bootable devices list in vmware form based on dnd JS library, I think @lstejska is looking to how to use it in the registration form for activation keys selection. Perhaps they could point you to some existing code. The form inputs I believe is already react based (at least some types)