Dynamic parameters in Horde templates

Development Pipeline & Plugins
, ,
1

Hey, I think this is a new feature request but correct me if I’m wrong if it’s already possible. For a better user experience and easier configuration, I’d be interested in dynamic parameters in Horde templates. There are two categories of dynamic parameters this could cover:

  1. Dynamic in the UX sense: parameters that hidden/shown to the user based on other parameters they have selected when they are running the template in Horde. For example if a bool parameter is ticked it shows a text box for input. Similar to how when you put a changelist number in the “Shelved Change” box it shows you the “Automatically submit preflight on success” checkbox, but extended to the template parameters.
  2. Dynamic list configuration: it would be helpful in some scenarios for the items in a list parameter to be fetched from somewhere else, e.g. XML config or a HTTP request to a service. We can have a job that updates the statically configured list items, but it’s a bit inconvenient. It would be great if we could have a custom C# task (similar to a custom BuildGraph task) that gets run to fill in the list.

Let me know what you think, and I’m curious if similar requests have come up internally in Epic. Thanks!

2

Hey there Patrick,

Thank you very much for reaching out, and with your feedback. This currently isn’t supported in the manner that you’ve outlined.

Regarding your first piece of feedback, the preflight “automatically submit preflight on success” checkbox is quite specific to that feature, so no such generalized workflow exists as is. I could inquire about the feasibility of this, but given the current schema for defining parameters, it’d be more complex to establish relationships & dependencies.

Regarding your second piece of feedback, we have received related feedback around configuration templates (and the reuse therein) which could be related to the “fetched from somewhere else” note - so I will re-route this feedback into that ask.

Kind regards,

Julian

3

Hey Patrick,

Thanks for that.

Re: re-routing feedback

  • There’s an existing internal JIRA that represents licensee feedback on configuration of Horde, and various improvements as such. I will be incorporating the feedback into this ticket as it seems to closely relate to it. As it’s a feature ask, we don’t reflect these on the public issue tracker (only bugs are mirrored).

Kind regards,

Julian

4

Yeah I totally understand the first one could get complex. I was thinking the schema could look something like:

"parameters": [ { "id": "myBool", "type": "Bool", "argumentIfEnabled": "-set:something=true", "default": false }, { "id": "myFirstTextBox", "type": "Text", "argument": "-set:somevalue=", "default": "" "visibleIf": "myBool=true" } { "id": "mySecondTextBox", "type": "Text", "argument": "-set:somevalue2=", "default": "" "visibleIf": "myBool=true and myFirstTextBox!='""" } ],

So in that example the first text box would be visible if the bool checkbox is ticked, and then the second would become visible one you fill in something for the first text box. There are more complex dynamic UX use cases like “change the available items in a list based on some other parameter”, but they could come later. Anyway, let me know how your inquiry goes.

For the second, could you clarify what you mean by “re-routing this feedback into that ask”? Just checking if there’s another UDN question I could track, or if you have another recommendation for checking in for updates.