I’m building an application where I’m allowing users to flexibly search for tasks on a variety of criteria and using many of the TaskQuery methods to perform the search. But I have two searches I haven’t found a way to do short of doing native task queries.
The first is querying for tasks assigned to multiple users. TaskQuery.taskAssignee only takes one, and while there are “IN” methods on TaskQuery for a number of other items that take Lists, there is not a taskAssigneeIn. Also, using multiple taskAssignee within an or/endOr only searches for the last one specified. Is there a way to search for multiple assignees? Or is an enhancement to add taskAssigneeIn needed?
Second, to support scenarios where there are multiple users in the same group and one user has claimed a task but goes on vacation, I’d like a way to be able to search for candidate tasks where the task has already been assigned, e.g. user A and user B are in the same group, a task has that group as a candidate group. When the task is not assigned, it is a candidate for both users. But as soon as it is assigned to user A, it no longer shows up as a candidate for user B. Is there a way to search for tasks that would be candidates for one user but are assigned to another? Or is there a better approach to allowing other users in the same group to access tasks assigned to others if they are unavailable?
For searching on multiple assignees we would need to add a taskAssigneeIn option, which is good to do of course.
In the second scenario is taskCandidateOrAssigned not the query option you are looking for? This will return all candidate tasks + the tasks assigned to the given user.
Hi,
we ran in the same issue as Kevin describes . I also remember some threads on the activiti forum about this.
In short: The logic of the existing method seems to imply: whenever a task is assigned to somebody, nobody else can see that task. I’m not sure if this is really intended design, or just a historical thing. Imagine you cannot see issues in github or jira when they are assigned to somebody… that’s not really practical.
We have used custom SQL to work around that problem (e.g. for the usecase : task is assigned to user x ; but user x is on holiday for 3 weeks).
Thanks for the reply. It would be great if taskAssigneeIn was added. I’ll open an issue for it.
Like Pieter says, I’d like a way for one person to see the tasks that were candidates for them but were claimed by another user. Using taskCandidateOrAssigned would require doing that for each person that was a member of the candidate group(s). The scenario is someone claimed a task and then goes on vacation, a co-worker needs to be able to see the tasks to be able to pick them up and complete them.
Also like Pieter says, I could do custom SQL, but then I also have to do custom SQL for all the other methods I’m using to do other qualification and filtering. It would really be easier if there was an optional flag for taskCandidateOrAssigned that returned tasks that would be candidates if they weren’t assigned, or another method that did that.
I understand that it would be good to add this query option. Although I do think that when a task has been assigned it should not appear in a task list when searching on a candidate group by default. So I think we need to add an additional non-default option to search for all tasks belonging to a candidate group (assigned and non-assigned tasks). We need to think of a good name for this option. Any suggestions are welcome.
we bumped into this issue again, but now on the historic task query (act_hi_tasksinst). We want to build a view on which administrators can search in the task history on various task properties - candidateGroup or candidateUser . But just like in the running tasks query, this causes the '… AND RES.ASSIGNEE_ = null ’ to be injected.
I don’t really think this behavior is makes sense when searching in the history of tasks, but I understand it could break existing user’s logic.
So we could make an option in both the runtime and historic tasks query, of which the naming is not easy (testified by the 280 days of silence …)
So here is my proposal, with some help text. I try to adhere to the seeming convention that optional parameters are false by default. And it starts with ‘candidate’ to show
candidateAssignedToOthers (boolean) (default: false) This option only has effect when used together with the parameters “candidateOrAssigned”, “candidateGroups”, “candidateGroup”, “candidateUser”. If false (default), filtering on candidate user/group does not return tasks that are assigned to other users, because they are considered as 'already claimed’ If true, the tasks that are assigned to other users are returned by the query instead of being filter out
candidateIncludeAssignedToOthers would seem more clear, but that conflicts a bit with the concept of the ‘includeProcessVariables’ option.
“candidateExcludeAssignedToOthers” with default true would also be more clear, but might break the convention (?) of having options false as default.
It still doesn’t feel ideal, but it’s a start to revive the discussion. We could probably submit a PR once we have the naming problem figured out.
