Define candidate users dynamically

Hi!
how can I exclude a dynamic list of users members of a defined Candidate Group?

For instance, giving this task definition:

user1 and user3 should be excluded after some evaluations

thanks in advance

Hi @antonior
I think what you are looking for is documented in detail here:
https://docs.camunda.org/manual/7.8/reference/bpmn20/tasks/user-task/#assignment-expressions

In short:
Your candidateGroup or candidateUsers field of the UserTask can have an expression (e.g. ${myUsers}).
In my example you would have to define the variable “myUsers” before the execution of the UserTask.

Best
Felix

1 Like

And if you need to do the evaluation in place, you can invoke the logic in a bean as described here:
https://docs.camunda.org/manual/7.8/reference/bpmn20/tasks/user-task/#invoking-a-service-bean

1 Like

thanks for reply @tiesebarrell @felix-mueller but I’ve only a list of not allowed users that I need to exclude

Can I use it for the assignment expression?

@antonior One way you could handle a “blacklist” of users is to assign all potential users (or groups), but on task creation use the mechanism I pointed to to compile the blacklist for that task instance and store it as a task local variable. Then when querying for a list of tasks, make sure to also retrieve the local variables and filter based on your blacklist whether the user gets to see the task in the list. Should they circumvent it somehow, you can use the same blacklist variable to double-check on assignment (claim) of the task.

Thanks @tiesebarrell
I 'm trying using the service bean quering memebership table using a native user query…

but I’m encountering a problem, probably I’m wrong :frowning:

I’ve opened a new topic for this problem

OK, good luck with that then :+1:t2:

Hi @tiesebarrell I fixed (mine) query issue, now I can retrieve candidate users dynamically to use as expression invoking the service bean.

I have some doubts about two solutions, I ask you what can be the best solution(in term of performance too) between this two solutions:

  1. revoke user access using authorizations within a task creation listener

  2. provide a dynamic candidate users list expression and also does NativeUserQuery work enabling LDAP?

For both solutions authorization service creates entries for a task id resource, denying one and allowing for the other case…

Thanks a lot, regards

@antonior I’m not sure I quite understand what you’re trying to achieve. Based on the original description I thought you meant that by default, a group is assigned. But, for each instance of the task, you want to block some of the users within that group from seeing the task, even though they are in the group. That’s why I pointed to a way to create a blacklist along with each task and filter in listings and check when claiming the task as an extra precaution.

Is that what you mean by 1.?

If you can dynamically determine a list of candidate users on task creation, which seems to be what you mean by 2. then you would put an expression for candidate users in the task creation going out to the bean and determining any whitelisted users up front. Performance wise, this is probably the best since no evaluation is done when retrieving tasks, but it really depends on how the logic is written to determine either the whitelisted or blacklisted users.