Add _Binding_ entry to busines rule task, call activity and user task

[philippfromme]

Proposed Changes

• adds a Binding entry to business rule tasks implemented as DMN, call activities and user tasks with linked form

Check out the branch and run npm start to test.

Business rule tasks

Call activities

User tasks

Depends on https://github.com/camunda/camunda-bpmn-js-behaviors/pull/78 Depends on https://github.com/bpmn-io/properties-panel/pull/376

Tooltip

Checklist

To ensure you provided everything we need to look at your PR:

• [x] Brief textual description of the changes present
• [x] Visual demo attached
• [x] Steps to try out present, i.e. using the @bpmn-io/sr tool
• [x] Related issue linked via Closes {LINK_TO_ISSUE} or Related to {LINK_TO_ISSUE}

---

Related to https://github.com/camunda/camunda-modeler/issues/4385

[nikku]

I'm cross posting a concern from the upstream PR here:

The design sketches seem to imply we now start to recommend best actions for users (in italic). I don't like this for two reasons:

• We don't usually give best practices in the tooltips, but are descriptive and add a clear call to action ("learn more"). The tooltips should give people enough context to understand what is happening, but not do full education.
• The good practices are misleading. If I'm developing a process application (which is the default in the future), then from the start deployment is the safe and recommended option. This becomes especially evident the design sketches propose versionTag to be the best solution for production environments. Which is just wrong (cf. above). Inside of a process application deployment is always the best and safest choice, in my opinion.

My proposal is that we leave it to the documentation to give advice, and ensure that we properly apply sensible defaults, based on the context (ref). At best a user should not need to touch this property at all in order to be successful.

---

CC @lmbateman @philippfromme @RomanKostka

[philippfromme]

@nikku I drastically simplified the tooltip.

[nikku]

@philippfromme Don't get me wrong: A short and concise factual description, if correct can help. I'd just want to keep out any detailed "recommendation" out of these tooltips.

[lmbateman]

I think we should either leave out "The default is latest" from the tooltip, or add a reason why. If they haven't changed it, the default should be obvious, so that sentence isn't helpful; and if they have, then it would be useful to know why the default is what it is. Also, based on Nico's comments, is latest the best default?

Ideally, we should keep the user in the application, rather than forcing them to go visit the documentation. To that end, I'd prefer a tooltip with a little more explanation, because the meanings and benefits of the options may not be obvious from their titles. How about a middle-of-the-road version along these lines? We could probably tighten the text up even more. Conversely, if we can nail down the right recommendations, I'd be OK with adding them back in.

[nikku]

@lmbateman I think your proposal works well; I'd add deployed to the mix. Some minor suggestions:

• Latest = most recent **deployed** version
• Deployment = Uses the linked resource in the same deployment.
• VersionTag = Uses the latest deployed version with a specific version tag.

[philippfromme]

The Version tag option is not going to be supported according to https://github.com/camunda/product-hub/issues/1920#issuecomment-2168146584 so I didn't implement that. I assume, this would be added as part of https://github.com/camunda/product-hub/issues/435.

[philippfromme]

I've left out the documentation link since there is none yet.

[philippfromme]

Ok, adjusted.