We are using the flowable extensions for multi-instance user assignment, but we would like to be able to support either a data object which contains a set of users or a string. For example, our design tool supports either a list of user/group ids associated with a role (e.g. potential owner) or a data object reference that contains a set of users/groups. We do not support a list type data object, so we are using JSON syntax:
[
{
"principalType" : "User",
"role" : "PotentialOwner",
"principal" : "wfuser1",
"version" : 1
},
{
"principalType" : "User",
"role" : "PotentialOwner",
"principal" : "wfuser2",
"version" : 1
}
]
We are using a JSON participant task listener to parse the string. We were able to use a string in the collection attribute, but it was quite ugly because we had to escape it:
<multiInstanceLoopCharacteristics isSequential="true" flowable:collection="[ { "principalType" : "User", "role" : "PotentialOwner", "principal" : "wfuser1", "version" : 1 }, { "principalType" : "User", "role" : "PotentialOwner", "principal" : "wfuser2", "version" : 1 } ]" flowable:elementVariable="participant"/>
Ideally, if the collection were an element instead of an attribute we could use an expression for the data object and CDATA for the string value:
<userTask id="usertask1" name="Task A-${loopCounter}">
<extensionElements>
<flowable:taskListener event="create" flowable:delegateExpression="${jsonParticipantListener}">
<flowable:field name="participants">
<flowable:expression>${participant}</flowable:expression>
</flowable:field>
</flowable:taskListener>
</extensionElements>
<multiInstanceLoopCharacteristics isSequential="true" flowable:elementVariable="participant">
<extensionElements>
<flowable:collection>
<![CDATA[
[
{
"principalType" : "User",
"role" : "PotentialOwner",
"principal" : "wfuser1",
"version" : 1
},
{
"principalType" : "User",
"role" : "PotentialOwner",
"principal" : "wfuser2",
"version" : 1
}
]
]]>
</flowable:collection>
</extensionElements>
</multiInstanceLoopCharacteristics>
</userTask>
I realize adding a new collection element might be confusing while continuing support for the collection attribute, but it could be more generically named.
Any thoughts? If you agree that this might be useful, I can extend the parser accordingly and submit a formal pull request.
