cancel
Showing results for 
Search instead for 
Did you mean: 

Participant expression syntax

lsmall
Champ in-the-making
Champ in-the-making
Activiti supports both the standard participant XML (humanPerformer and potentialOwner) as well as activiti extension attributes (assignee, candidate users, candidate groups, etc.). We prefer to use the more standard syntax with the addition of the custom resource feature. This way, the same formal expression syntax can be shared across all participant types (except humanPerformer which is a single user by nature).

<formalExpression>user(sam), user(frank), group(engineering), admins</formalExpression>

where any none prefixed values are assumed to be groups

We intend to extend it to support additional identity types (role, privilege). Our current product supports JSON syntax of the form:

  {"users":["user1","user2"],"groups":["group1","group2"],"roles":["role1","role2"],"privileges":["priv1","priv2"]}

This syntax also allows sets of identities as opposed to adding a prefix for each.

Any thoughts? If you agree this syntax is useful, we can open a Jira issue and propose an implementation.
2 REPLIES 2

frederikherema1
Star Contributor
Star Contributor
Lori,

I'm interested in the way you're going to implement this. Currenlty, it's handled by the PotentialOwnerParser, a child parser of the UserTaskXMLParser. In case you extend the UserTaskXMLConverter and add your custom parser that handles "potentialOwner" element, you can support any format you want. Not sure if shipping a JSON-based parser by default would be a good improvement, as the format you're describing is pretty usecase-specific… Unless I'm missing something, off course Smiley Wink

lsmall
Champ in-the-making
Champ in-the-making
I have already extended the UserTaskXMLConverter to only use the extended participant syntax (instead of the Activiti attribute extensions). We will likely extend it further to parse JSON, but just wanted to know if you saw any benefit to adding it to the code base.