In the Camunda web modeler it is impossible to remove the value from a dropdown after a value has been selected or if it has a default value (unless you use the inspector which is surely not the intended way). We need to be able to remove values either by having an x to the right inside of the field on which you can click and/or press backspace when the dropdown is opened could remove the value too. Empty dropdowns is the desired behavior for some fields in our connectors, e.g. when specifying the order of the response in one request there can be a custom view id or standard columns and direction (both provided as dropdowns, so e.g. ID asc could be selected), but they are mutually exclusive (which is written in the description of the fields and validated in the connector).
Hi @cma - that is a great question and something I do not think you can do currently. I will send this to the team working on Connector templates as feedback!
In the meantime, one possible workaround might be to add a blank choice in the dropdown? It’s not particularly elegant, and you would need to handle the possibility of an empty variable value in your logic, but maybe it’s a viable workaround for now?
"choices": [
{
"name": "",
"value": ""
},
// ...
}
Hi @nathan.loding - this could work indeed, because unknown enum constants seem to be deserialized to null by gson. Thank you for informing the relevant people, although I think it is an issue of the modeler frontend and not the connector templates.
Is it possible to share a bit more information about your templates and where you are looking to reset the value sometimes? It will help our engineering team as they look into this feature request.
Yes. I’m talking about dropdowns of connectors in the properties panel in the modeler. But maybe this is how all dropdowns are implemented in the properties panel, I don’t know.
The way it is now you can save an empty dropdown if it is not required and you never selected a value and it has no default value. I can see the advantages of not being able to remove dropdown values, however in this case the first dropdown value should become the default if there is none, so that it is not possible to save empty dropdowns (never, also not under some special circumstances) and an empty value has to be added manually to the dropdown if that is needed.
On the other hand the dropdown values could be made removable, which also makes a lot of sense. If a field is required you cannot save the empty dropdown anyway, so you have a way to ensure it. Additionally the possibility to remove dropdown values could be removed for required fields. Usually deleting dropdown values is implemented by having a clickable x right in the field and you can also press backspace to remove the dropdown value.
@cma What would be really helpful is if you could attach additional context to this topic:
- A screenshot
- If you refer to element / connector templates
an example template
This way it is easier for us to understand your feature request.
In the context of connector templates I’m not sure we need more than what @nathan.loding calls a workaround.
It is the connector template authors responsibility to decide whether an empty value is accepted as valid input, and what the empty value is supposed to bind to. For example empty could bind to = null for input mappings, or empty could be represented through a None label (i.e. authentication type is None).
@nikku Here is a screenshot. I didn’t provide any because I thought it’s clear what I’m talking about: the properties panel in the web modeler. Sorry, but I’m not going to provide the complete template JSON, it is irrelevant, it happens for all dropdowns in the connector template.
I think the question whether you need something or not is the wrong question. More important would be: Is it intuititve? Is it eays to use? Is it consistent? And I would argue that it is certainly not consistent if you can save an empty value but cannot remove it after selecting something (just imagine a text field which can be saved empty but as soon as you have written something in it you cannot make it empty again, in my opinion that would be absurd, same for dropdowns). Either the value is never empty (make first value default if none is specified in the connector template) or what I think is the much better solution is to make dropdown values removable. There is absolutely no reason having to add empty values manually. You can make dropdowns required if you don’t want that an empty value can be saved. With the first solution you make dropdowns implicitly required.
Btw. Why there is a not empty and an optional in the connector template is another mystery to me. Not empty implies not optional and possibly empty implies optional. Two properties for the same thing?
Thanks for the screenshot. That helps me confirm what I thought you have in mind.
So let’s consider any of your examples, i.e. Module. What would an empty state look like? And why would you not want to model it explicitly?
Optional is a workaround for a current engine limitation. You simply cannot model an empty input mapping at the moment.
@nikku The empty state would look the same as for any dropdown where you don’t specify a value in the template (empty white field if not required otherwise empty red field saying that the field is required).
The problem is not that I cannot get it to work. But I have dropdowns that can be empty. I could think of several reasons for having empty values, e.g. all dropdowns that override something and if empty inherit from some parent somewhere or in our case here Zoho allows to specify a view ID but then you cannot select a sort column and a sort direction (both optional dropdowns), so in this case they have to be empty. Of course we could handle everything in the backend and there are plenty of workarounds, but I don’t think that they are satisfying. It could be much nicer. I usually translate or generate classes from the API spec and from those classes I generate the connector template (including all the validation) etc. But now I have to manually add an empty field for all optional dropdowns. The comparison to text fields shows why it is ugly and inconsistent at least in my opinion. Also making dropdowns required seems to be superfluous then.
The way we think about dropdowns, supported how element templates currently work:
- Dropdowns need to provide all values that a user can enter. If empty is an option, then you have to model it explicitly.
- Showing an empty value as a selection when the dropdown does not support it is not a feature we’re going to implement. You always have to choose between one of the available options.
- If a field is optional (I mentioned optional is a hack) then we allow you to remove the value by offering you an empty selection.
Hope this helps you to better understand why we’re building what we’re building.
I’d still apprechiate if you’d share an element template that shows your current use of dropdowns, and what you’re missing.
@nikku Thanks, I think I got it now. So there are two solutions (tested it):
- Add an empty option to the dropdown
- Make the dropdown optional (so the empty choice is added as first option)
For me 2. is the easier option and exactly what I was looking for (just implemented differently than proposed). The problem was I was only using not empty for required properties but not optional for optional ones. You say it is a hack, does this mean it will be removed in future versions?
I follow your explanations and reasoning and understand it. And I still think there could be a small improvement. As mentioned: if in the template no value was specified for the dropdown, then the first option becomes the initially selected one (and not nothing). This would be exactly like dropdowns work in HTML. Also because the empty option is added as first one the optional dropdowns (with no value in the template) would still be empty initially.
Sorry I cannot share the template unless we publicly release the connector. Also the template is generated and very large, for every action several common and unique fields are visible.
You say it is a hack, does this mean it will be removed in future versions?
No, it will remain available as a feature. However, as empty input mappings become available there will be no dire need for optional anymore.
If in the template no value was specified for the dropdown, then the first option becomes the initially selected one (and not nothing). This would be exactly like dropdowns work in HTML. Also because the empty option is added as first one the optional dropdowns (with no value in the template) would still be empty initially.
If this is not what happens for non-empty dropdowns, then we may want to consider it. Thanks for the suggestion.
Thanks a lot for all the answers. The problem is solved but I don’t know which answer should be marked as solution, many contributed something. Nevermind, I figured it out.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.