Allow conditional choices in dropdowns in Connector templates #3682
Description
Problem you would like to solve
Many REST APIs support multiple entities and operations, and trying to build out a larger base template is cumbersome currently. That leaves us with the option of a very messy and very hard to maintain JSON template (with some junk like what you see below), or not being able to support multiple operations in a single template.
Supporting conditional options in dropdowns makes the Connector templates easily maintained while still keeping the same flexibility. The example below is from experimenting with an AirTable Connector. AirTable's API supports multiple entity types that could be reasonably used within a workflow. To support all these currently, it is either a messy, hard to maintain template, or multiple templates.
{
"type": "Hidden",
"value": "get",
"binding": {
"type": "zeebe:input",
"name": "method"
},
"condition": {
"property": "recordsEndpoints",
"oneOf": [
"listRecords",
"getRecord"
]
}
},
{
"type": "Hidden",
"value": "get",
"binding": {
"type": "zeebe:input",
"name": "method"
},
"condition": {
"property": "commentsEndpoints",
"oneOf": [
"listComments"
]
}
},
{
"type": "Hidden",
"value": "get",
"binding": {
"type": "zeebe:input",
"name": "method"
},
"condition": {
"property": "basesEndpoints",
"oneOf": [
"getBaseSchema"
]
}
},Proposed solution
Use the same condition syntax/property to make dropdown choices conditional. In the event that another property changes and hides (therefore invalidating) an existing selection in a dropdown, the dropdown could default to a null state (with nothing selected, similar to how dropdowns work if the template doesn't provide a default value).
"choices": [
{
"name": "Something",
"value": "something"
},
{
"name": "Something conditional",
"value": "sometimesHidden",
"condition": {
"property": "aProperty",
"equals": "hideThatOneOption"
}
}
]Alternatives considered
An alternative that would achieve the same result is allowing multiple property keys to be used in conditions, but that seems more complex in the long run, both from a development perspective as well as a maintenance once.
Additional context
Related Slack threads: https://camunda.slack.com/archives/CKGH9LR40/p1686942106019649