Implement Camunda Platform Properties

[barmac]

Implement Camunda Platform Properties

Goal

As a developer implementing BPMN, I want to use Camunda Platform specific properties in the properties panel.

What should we do?

Migrate groups with Camunda Platform properties.

• Build foundation for Camunda Platform properties implementation #10
• Migrate general group
  • id part of BPMN props
  • name part of BPMN props
  • process props part of BPMN props
  • Implement version tag property #18
  • executable part of BPMN props
  • element template This will be implemented separately; outside of the scope.
• Migrate externalTask group #36
  • Task priority
• Migrate async continuation group #38
  • Async before
  • Async after
  • Exclusive
  • Set camunda:exlusive flag to true, when not async anymore via custom behavior camunda/camunda-bpmn-js#29
  • Delete camunda:jobRetryTimeCycle when async is disabled camunda/camunda-bpmn-js#30
• Migrate jobConfiguration group #28
  • Job priority
  • Job retry time cycle
• Migrate candidateStarter group #12
  • Candidate starter groups
  • Candidate starter users
• Migrate historyTimeToLive group #19
  • History time to live
• Migrate tasklist group #22
  • IsStartableInTasklist
• Migrate documentation group
  • Element documentation
  • Process documentation
• Migrate process variables group #25
• Migrate field injection group #23
  • field name
  • field type
  • field value
• Migrate extension elements group #32
  • Not sure if this belongs to Camunda Platform properties. This is more like BPMN general props but only in the implementation phase.
• Migrate details group Each of the items should become a separate group. "Details" is too generic.
  • Service Task delegate props (implementation) #41
  • Implement user task props #43
  • Implement script props #47
  • Call Activity props #55
  • Event props (several props inside, cf. BPMN provider?)
    • Message Event Definition #68
    • Error Event Definition
    • Signal Event Definition #69
    • Escalation Event Definition #70
    • Timer Event Definition #71
    • Link props #50
    • Compensation event #78
  • Error props (overriding existing BPMN props) #51
  • Conditional props - sequence flow #52
  • implement Start Event initiator group #45
  • Conditional props - condition event #62
• Implement list entry properties-panel#92
• Migrate BPMN generic multiInstance group #84
  • Loop cardinality
  • Completion condition
• Camunda multi-instance props #85
  • Collection
  • Element variable
  • multiInstance asyncBefore
  • multiInstance asyncAfter
  • multiInstance exclusive
  • multiInstance retry time cycle
• Migrate variables mapping group #89
  • In mapping
  • Out mapping
• Migrate form group
  • camunda:FormKey #91
  • Generated form section (camunda:FormData) #93
    • field type
    • field label
    • default value
    • field id
    • value (for enums)
    • constraint (validation)
    • property
  • Implement camunda:FormData#businessKey for Start Events #110
  • Implement Behavior that Cleans Up camunda:formData#values on Type Change camunda/camunda-bpmn-js#46
  • Implement Behavior that Updates camunda:formData#businessKey on ID Change or Removal of Referenced Form Field camunda/camunda-bpmn-js#48
  • Allow Configuring Camunda Forms #96 (new)
• Migrate listener group #48
  • listener props
  • listener details
  • listener fields
  • Migrate field injection inside listeners group:
    • field name
    • field type
    • field value
• Migrate Task listener #106
• Implement inputs & outputs group #54
  • Input
  • Output
• Implement Errors group for external service tasks #99
  • Behavior that cleans up errors if implementationType is switched away from external
• Migrate connector group #101
  • connector details (part of implementation group)
  • input ==> preferably only re uses existing Inputs props
  • output ==> preferably only re uses existing Outputs props

Why should we do it?

We want to use the properties panel in Camunda Modeler / Camunda Platform BPMN tab.

Potential for user tests

Once we implement a significant number of Camunda Platform properties, we can test their discoverability.

Maybe we want to re-arrange the items.

Update @pinussilvestrus (22nd July): We want to do it rather sooner than later (cf. https://github.com/bpmn-io/internal-docs/issues/330)

How to proceed

Because the list is so long, I have decided to not create issue for each group up front. Let's keep it tidy as the list already allows to track the progress.

Here's the flow how to work on this epic:

1. Pick up a group or a selected item from the group.
2. Convert it to an issue using the recent GitHub feature (issue from list item).
3. Implement it. Once the issue is closed, GitHub will automatically mark the item as done.

To clarify basic questions during the translation from old to new properties panel, please check the Summary of principles for current Properties Panel development

About the structure of the new panel, please check https://github.com/camunda/camunda-modeler-design/issues/27

Context

• Properties panel vision
• UX guidance for sections

[barmac]

I have updated the list with the remaining properties. This should be complete now.

[MaxTru]

Should we in the epic also indicate how the structure changes with the implementation? (I think this mainly affects the details group)

Example: I think the Details Group should be split up.

Why:

• The new properties panel has the groups collapsed per default. Data Markers would show if a group is filled or not.
• If therefore makes sense to make the groups as small as possible (combining only what from an implementation perspective belongs together)
• I think a generic label as-is (details) is not helpful from a UX perspective / does not guide the user

as-is

Migrate details group
 Service Task delegate props (several props inside)
 User Task props (several props inside)
 Script Task props
 Link props
 Call Activity props
 Event props (several props inside)
 Error props
 Conditional props
 Start Event initiator

to-be (example)

Old structure group	Old structure item	New structure group
Details	Service Task Delegate	Delegate
Details	User Task Props	User Assignment
Details	Script Task Props	Script
Details	Link props	Link
Details	...	...
Details	...	...

[barmac]

Indeed, details is a generic name which could be replaced by specific names related to the edited properties. I've updated the issue accordingly. Let's decide on the exact names during the implementation, though.

[andreasgeier]

I added the reference to the Summary of principles for current Properties Panel development in the issue section "How to proceed". Please consider.

[andreasgeier]

I added the reference: Properties structure for new properties panel Camunda Scope in the issue section "How to proceed". Please consider.

[MaxTru]

To consider for later on improvements (topic description as a UX improvement): add description for external task priority

[andreasgeier]

Today we reviewed the UI of nested lists and agreed on the solution.
Participants: @barmac @MaxTru @volkergersabeck @philippfromme @andreasgeier

We decided to use the default nested list (second level almost equal to first level) on all places except for variable assignment type:list. There, we use a specific pattern without expanding/collapsing list items but showing a single input field only.

Find all cases in the prototype: https://fluffy-fiesta-212e1c7c.pages.github.io/prototypes/visual-ide/v12/

default nested list:

single input list:

[barmac]

Summary of the meeting @pinussilvestrus, @MaxTru, and I had today:

• The list entry is blocking so we prioritise it over the templates topic.
• Max and Niklas will pick up the event props as the next topics.
• We have a common understanding on how we want to approach the templates topic later on:
  • The templates logic (setting the properties) will probably be a 1:1 migration.
  • There will be a templates provider of lower priority than the Camunda Platform provider. It will re-adjust the groups and entries according to the templates logic.

[barmac]

For the compensation, note that there is a bug ticket in Camunda Modeler repo: camunda/camunda-modeler#2397

[barmac]

I've checked some of the places where the list ordering is relevant for the execution.

Found:

• camunda:errorEventDefinitions are evaluated in order as in XML; thus it's relevant for the execution which expression is first
• In case of camunda:inputOutput, only the first syntax error in an expression is reported by the engine; XML order matters
• In a generated form, the XML order determines the order of the fields.

[barmac]

I've added Task listener as this can be implemented separately from Execution listener.

[barmac]

It's hard to believe but we have finished all of the tasks in this issue. Thanks everyone for collaboration!

[andreasgeier]

That achievement is worth a celebration 🍾

[philippfromme]

Congrats!