-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(cloud-templates): conditions on dropdown choices #14
base: main
Are you sure you want to change the base?
Conversation
91cdf54
to
7c6c2de
Compare
6b41486
to
8df85da
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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) |
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 |
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.movThis happens because we trigger xml updates when updating element templates, which is not the case here |
8df85da
to
e4e0ef5
Compare
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.movMakes 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.movBut 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 |
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. |
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