bpmn-io / bpmn-js-properties-panel

Describe the Bug

As a user I define element template properties in a dedicated order. As it looks like that order is not uphelt as input mappings are created. In fact it seems like we attach the last saved last in the <zeebe:ioMapping> list. This leads to dependent mappings not being evaluated consistently (https://github.com/camunda/web-modeler/issues/3251).

The whole behavior is bogus to the user, and cannot worked around without knowing.

Steps to Reproduce

configure dependent-io.json template
Model Dependent Mapping task
Change values of First*
See that we move each one of them (zebee:input, zeebe:output, zeebe:property) below dependent property

Expected Behavior

Upon modification we uphold the order of properties defined in the template.
Upon entry addition (i.e. conditionally enabled) we uphold the order of properties defined in template.

Environment

Host (Browser/Node version), if applicable: Any
OS: Any
Library version: 1.12.0

I've investigated the issue and concluded this is not an easy fix.

Added failing test cases, and moving to ready to be picked up in an orderly manner next year.

Adding the blocker label just now.

This impacts Camunda connectors in a large scale, as it prevents real-world re-use of inbound webhook and outbound REST/JSON (ref, ref). We should pick this up with priority in early 2023.

CC @CatalinaMoisuc @christian-konrad

Adding the blocker label just now.

This impacts Camunda connectors in a large scale, as it prevents real-world re-use of inbound webhook and outbound REST/JSON (ref, ref). We should pick this up with priority in early 2023.

CC @CatalinaMoisuc @christian-konrad

+1 @nikku

@CatalinaMoisuc and @christian-konrad this really is a big thing and it would be great if you could prioritize this asap

@christian-konrad already bought into it. We'll prioritize this right as 2023 starts. 🎆

I'm looking into this.

Like Nico mentioned, the issue is that we always add the last edited value to the array of inputs:

bpmn-js-properties-panel/src/provider/cloud-element-templates/util/propertyUtil.js

Line 294 in 5e7e1fb

values.push(newZeebeInputParameter);

We need to ensure we add it at the index of the original input instead.

Interestingly, this is not an issue with the normal io-mapping list, as we just update the moddle element instead of creating a new one:

bpmn-js-properties-panel/src/provider/zeebe/properties/InputOutputParameter.js

Lines 83 to 89 in a8efd39

    
           commandStack.execute('element.updateModdleProperties', { 
        
             element, 
        
             moddleElement: parameter, 
        
             properties: { 
        
               source: value 
        
             } 
        
           });

Fyi, this is also the case for zeebe:property and zeebe:taskHeaders. #844 fixes this for all by inserting the property back in its original position

	commandStack.execute('element.updateModdleProperties', {
	element,
	moddleElement: parameter,
	properties: {
	source: value
	}
	});

Input mappings defined by templates not stable