nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

unknown type of task candidate

christoph_retti

Hi, is there a way to set a task's candidates without specifying that the candidates are users or groups?

I would like to have a user task where the user specifies the possible candidates for the next task from a list and it would
be very convenient if I could just set a task variable ${assignee} to something like "fozzie,management,support" (where
fozzie is a user and the two others are groups) without having to create a specifiy TaskListener that splits the types
of candidates and does something like

delegateTask.addCandidateUser("fozzie");
delegateTask.addCandidateGroup("management");
‍‍‍‍

Activiti itself should know from the id what type of entity I am passing in and aith this auto-detect I could
skip the delegate implementation.

regards, Chris

Find more posts tagged with

Comments

ronald_van_kuij

These are just strings… What about name clashes then?

christoph_retti

Hi Ronald, I guess they could be handled exactly the same as documented in

If no specifics are given whether the given text string is a user or group, the engine defaults to group. So the following would be the same as when group(accountancy) was declared.<br><formalExpression>accountancy</formalExpression><br>

(taken by http://www.activiti.org/userguide/index.html#10minutetutorial). For me its perfectly ok if you prefer groups over users and I think normally you don't have name clashes with groups and users.

regards, chris

frederikherema1

Documentation says if no "user(XX)" or "group(XX)" is used in the BPMN, group is presumed. This is something else than "in case of name clash, use the group". So using "user(john), test" is actually seen by the engine as "user(john), group(test)".

On top of that, checking the user-management on each assignment to see if it's a user or a group is an unneeded penalty to perform by default. On top of that, no explicit check is done to see if the candidate user/group actually exists.

Why not add this little piece of functionality in your application layer? It's only one call to identityService to check if it's a user/group…

christoph_retti

Ofcourse I can add this call myself but what I don't like about the solution is that on one side I can let the user choose the delegate
in a user task (we have a Java Swing based application) from a select list, so I have all this information in this place, but in the next task
where the candidates should be set I have to provide two (or three) variables to split each of them in

- assignee
- candidate user
- candidate groups

so (as far as I understand) I would need 3 task variables to properly set the assigment for the next task.

Or is there an approach where I can provide a variable in a list, lets say

"user(frog), group(engineering), group(management)"

and assign this one single task variable? I am not sure if there is a construct where I can specify all types of assignment/candidates in
one task variable and pass it on to the next task?

regards, Chris

frederikherema1

If you use a single variable, containing "user(frog), group(engineering), group(management)", you can use it in the <formalExpression> without any problem…

christoph_retti

ok, I will try this; many thanks for your help

c