Description for Property Groups

[Chris-Maechler]

Is your feature request related to a problem? Please describe.

I often encountered features that apply to all properties of a group. Sometimes also restrictions like "exactly one property of this group has to be filled out". Now there is only the option to put it in every description of every property of this group (or just the first), but none of the solutions seem to be satisfying. A description for groups would solve this.

Describe the solution you'd like

I would like that the property "description" is added to "groups" in the schema for templates and that this description is then displayed by the modeler (so that when a property group is expanded the first thing on top is the group description).

Describe alternatives you've considered

Haven't considered any alternatives. It works as is, but some connectors could be much nicer with this feature.

Additional context

Asked for it in Camunda Slack and was redirected here.

[nikku]

Thanks for opening this report. Could you share a real world example where this would be benefitial?

[Chris-Maechler]

Yes. I have a mail connector that works with thymeleaf and keycloak. It can be specified as which variable the sender and recipient gets injected in the thymeleaf template and much more like which variables should be injected or you could specify a keycloak attribute from which the locale is resolved for the recipient.

Email Template:

• Thymeleaf Template
• Fallback Locale
• Template Variables (comma-separated names of variables that should be available in the template)
• Sender Variable Name
• Recipient Variable Name

Subject:

• Message Key (if not found message key itself is returned, replacements still performed if possible, locale comes from template except if overridden by recipient)
• Replacement {0}
• Replacement {1}
• Replacement {2}
• ...

Sender:

• Email Address (supports extended syntax to be able to specify locale and sex for language and proper greetings)
• User by ID
• User by Username
• User by Email

For this group exactly one property has to be filled out. This could be written in the group description.

Recipients:

• Email addresses (extended syntax supported)
• Users by ID
• Users by Username
• Users by Email
• Groups by ID (all users of those groups)
• Groups by Name (all users of those groups)
• Role by Name (all users with this role)

Here I could write a lot in the group description, e.g.: Multiple values can be specified comma-separated. The mail is only sent once to each address (e.g. if a user is in multiple specified groups or roles). How keycloak users are resolved is defined in the Keycloak group and the injection of the user object (link) in the Template group.

Keycloak:

• Sender Variable Name
• Recipient Variable Name
• Locale Attribute
• Sex Attribute
• Male Sex Value
• Female Sex Value
• User Attributes (comma-separated list of attribute names that should be loaded, available on the user object (link) injected in the template)

Here I could add a link how keycloak connection is configured in the backend to the group description.

This is just a "summary" of one connector where it could have been useful.

[nikku]

Thanks for the comprehensive example.

Sender: For this group exactly one property has to be filled out. This could be written in the group description.

This, from my point of view, is a matter of "per group validation", i.e. ensure that at least one entry is selected, and indicate that accordingly through an (otherwise) error.

Recipients: Here I could write a lot in the group description, e.g.: Multiple values can be specified comma-separated. [...]

I think that parts of it could be solved by combining every address in a single field: recipient = "userId:Mike, foo@bar, role:marketing". If we had syntax highlighting for this, and/or autocompletion.

However general context you want to establish would require the group description.

Keycloak: Here I could add a link how keycloak connection is configured in the backend to the group description.

This would require the group description, and would be in line with "being able to link to external knowledge base".

[nikku]

As additional context, consider if tooltips (per group or element) would be a solution for you:

In the core properties panel we try to use tooltips over walls of description texts.

[Chris-Maechler]

Yes thanks for the hint. Tooltips would work too. I noticed you added tooltips for group and property, openByDefault to group and isActive to condition. I will add those to the template generator.

[nikku]

Moving this issue to our backlog. It is unlikely we'll follow-up with per group descriptions in the near future. Tooltips are better equipped to handle this.

[Chris-Maechler]

I agree tooltips are better suited except maybe for disabled people.

[nikku]

Closing this as tooltips is our solution.

Regarding "disabled people", let's evaluate how we can make tooltips accessible, if they are reported to not be accessible.

At least visually (for keyboard usage) they are at the moment: