Support for custom WIH parameters

[matus-m]

hi with the workaround from #52 (removing drools imports) the VS Code extension correctly recognises custom WIH definitions from the workspace .wid file. However, the BPMN editor does not provide possibility to set any of the custom parameters that my custom WIH has:

[
        "name" : "MyCoolWIH",
        "displayName" : "Process message Driven WIH",
         "parameters" : [
             "autoRetryEnabled" : new BooleanDataType(),
             "autoRetryMaxCount" : new IntegerDataType()
         ]
    ],

Is that also related to the imports issue? Or does the properties panel simply not support custom attributes? Thanks

[hasys]

Hi @yntelectual,

looks like there is missing opening and closing brackets.

[
   [
        "name" : "MyCoolWIH",
        "displayName" : "Process message Driven WIH",
         "parameters" : [
             "autoRetryEnabled" : new BooleanDataType(),
             "autoRetryMaxCount" : new IntegerDataType()
         ]
    ]
]

When I added it, all works just fine for me. Please, let me know if there is something else I am missing there. Thank you!

[hasys]

Hi @yntelectual, did my answer help? Can we close this thread as solved, or you have it still doesn't work for you?

[matus-m]

hi @hasys the brackets where just a copy paste error when I created the issue. I have re-tested it, and it does work indeed, though the custom attributes are rendered as Data Assignment not as dedicated props(compared to JBoss dev tools editor), And when opening task for some existing old process, where some custom property was not filled, the editor will not longer show it(presumably because it only shows data assignments that have some value, and no longer shows all params from the corresponding work item definition) So I presume that it will work fine, but I would definitely prefer, if custom attributes were rendered in the properties panel explicitly, not as implicit data assignment.

[ederign]

@hasys when you have a chance, could you please take a look at this?

[hasys]

Hi @yntelectual, good point, I like this approach, however I think current approach is more stable and flexible at the same time. It's not fully clear how should we solve conflicts between different versions of WID, should we remove already defined properties if they are missing in the new WID version? Should we add new ones? Should we allow to remove/add optional properties if needed and how it should look like?

[matus-m]

hi @hasys thanks for the comment - yes I see that even with that approach there are corner cases, which might be confusing. In the end, the custom attributes end up as data assignments, so the UI would always show dedicated UI inputs for attributes defined in WID, if some attributes were removed from WID in newer version, but were filled before, they would still be visible in the data assignment dialog. From UI point of view, having dedicated inputs(optionally with description, type checks, if it is supported by wid definition..) would be much nicer, but we can also live with the data assignment based approach.

[hasys]

Hi @yntelectual, good point, thank you! We have in our plans to revisit all properties and editors in BPMN Designer, it isn't in our current short terms plan however. Anyway I added our descussion to Jira tracker so we can consider it when the time comes.

Thank you for your collaboration @yntelectual!

[hasys]

@ederign, I guess we can close this ticket now and move discussion to our planning Jira issue: https://issues.redhat.com/browse/KOGITO-5407 thank you!