feat(cloud-templates): conditions on dropdown choices

[smbea]

Depends on camunda/element-templates-json-schema#107 ✅
Related to camunda/camunda-modeler#3682

Fell free to use the gitlab connector in the demo to test it, it was the perfect use case:

Screen.Recording.2023-08-25.at.13.47.33.mov

[marstamm]

It seems that we do not handle cleanup/chained conditions properly. In the example below, the options for "Create a release" are still present even when the operation type can only be "Issue" related.

What was our previous behavior for these kind of "dependent" optional values? I would assume that we clean up the XML when an option is hidden again, so the properties panel reflects the XML and not simply hide the UI but keep the values in the XML.

[smbea]

Ah, maybe it isn't as easy as I made it. I will leave this "in progress" and check this when I'm back from FTO (see if I can fix it easily or just leave it since it's a spring cleaning topic)

[smbea]

In theory, the conditions mechanism should work. What I suspect might be happening is the timing between re-renders (and therefore setting the dropdown values in xml) and the conditions checks is off. I move this to backlog and pick in the next spring cleaning or such

[smbea]

I found that the problem here is with the xml property cleanup. When changing a parent property, the child dropdown retains the old XML value, which isn't even in the current options:

Screen.Recording.2023-10-10.at.09.49.35.mov

This happens because we trigger xml updates when updating element templates, which is not the case here

[smbea]

This theoretically actually acts according to our element template expectations, which is that we don't override the existing value. Let's imagine if this were a string value:

Screen.Recording.2023-10-10.at.16.35.07.mov

Makes sense to keep that. This is the same thing that happens with dropdown. The issue is that the underlying value does not match the options presented in the UI so it looks like a bug. We can change it for these cases, so that it doesn't look broken (e4e0ef5):

Screen.Recording.2023-10-10.at.16.37.58.mov

But it would go against our general way of doing it. Any thoughts @marstamm ?

Note: if this isn't a simple choice moving forward, I will drop it as spring cleaning

[nikku]

Potentially related is this bug report, where we see wired behavior with dropdowns (and their initial value not being applied): https://github.com/camunda/web-modeler/issues/7649#issuecomment-1884983039.