topic Re: Select tasks by candidateUser or candidateGroups in Alfresco Archive

Select tasks by candidateUser or candidateGroups

fersmi — Tue, 18 Sep 2012 08:50:23 GMT

Hi,I tried select all task by candidateUser or candidateGroups in TaskQuerytaskService.createTaskQuery().taskCandidateGroupIn(roleNames).taskCandidateUser(user.getUsername()).orderByDueDate().asc().list();‍but I got ActivitiException - Invalid query usage: cannot set both candidateUser and candidate

Re: Select tasks by candidateUser or candidateGroups

jbarrez — Wed, 19 Sep 2012 08:13:12 GMT

The activiti query api has an 'AND' semantics for all its queries: so your query would basically read "give me all people that are in this group AND that are called like this".

Is that what you'd want?

I agree that the query seems to indicate otherwise… but the or seems definitely misplaced there, given the regular query semantics.

Re: Select tasks by candidateUser or candidateGroups

fersmi — Tue, 02 Oct 2012 15:09:50 GMT

I understand that the activiti query API has an 'AND' semantics for all its queries, but I need OR just as described in iBatis mapping.
I want select all tasks where the user is listed as a candidate (username or groupname) but the API does not allow me.

taskService.createTaskQuery().taskCandidateGroupIn(user.getGroups()).taskCandidateUser(user.getUsername()).list();

Re: Select tasks by candidateUser or candidateGroups

kafeitu — Tue, 02 Oct 2012 15:58:27 GMT

I understand that the activiti query API has an 'AND' semantics for all its queries, but I need OR just as described in iBatis mapping.
I want select all tasks where the user is listed as a candidate (username or groupname) but the API does not allow me.

taskService.createTaskQuery().taskCandidateGroupIn(user.getGroups()).taskCandidateUser(user.getUsername()).list();

I have a same demand :!: :?:

In our projects, we mapping activity's tables to entities that like task/processInstance/historyProcessInstance use jpa, and Integrate in our business entities. Then use hql to query workflow and business datas.

Re: Select tasks by candidateUser or candidateGroups

mschaefer — Tue, 02 Oct 2012 18:56:52 GMT

I have a similar problem. I want to query tasks by candidateGroup using taskCandidateGroup(). But this adds automatically a restriction that an assignee is not set:
… and T.ASSIGNEE_ is null and I.TYPE_ = 'candidate' …Why must assignee be null? There is s seperate method taskUnassigned() to achieve this.

The tasks i need to query have a candidateGroup and an assignee. I have no chance to get them. I think it would make sense to remove "T.ASSIGNEE_ is null" when using taskCandidateGroup()

Regards
Martin

Re: Select tasks by candidateUser or candidateGroups

frederikherema1 — Wed, 03 Oct 2012 07:58:49 GMT

I think it would make sense to remove "T.ASSIGNEE_ is null" when using taskCandidateGroup()

Our reasoning is that a task isn't "claimable" by a group-member if it's already assigned. So the query is built this way…

Re: Select tasks by candidateUser or candidateGroups

jbarrez — Wed, 03 Oct 2012 08:04:01 GMT

The idea behind is that you don't need candidate groups once you set the assignee. It's only until the user gives up the task (assignee is set to null), that the task is put back into the pool if the group.

Which use case are you thinking of that would invalidate that?

Re: Select tasks by candidateUser or candidateGroups

kafeitu — Wed, 03 Oct 2012 09:12:39 GMT

The idea behind is that you don't need candidate groups once you set the assignee. It's only until the user gives up the task (assignee is set to null), that the task is put back into the pool if the group.

Which use case are you thinking of that would invalidate that?

What do you think about add a new api like below?


taskService.createTaskQuery().taskCandidateUserOrGroup("kermit", "manager");

Re: Select tasks by candidateUser or candidateGroups

mschaefer — Wed, 03 Oct 2012 20:15:57 GMT

Which use case are you thinking of that would invalidate that?

The use case i must realize is based on the requirements from one of our clients (insurance business):
- There are users handling incoming notifications of loss
- The users are organized in groups to replace each other in certain cases (illness, etc
- When a notification arrives, the process in Activiti is started and a UserTask is directly assigned to one of the users as "assignee" and the user's group is also set as "candidateGroup"
- Now there is the point: There is a manager which needs to see all tasks (one list per group) so he can reassign them if needed. There is no chance now to show such lists because taskCandidateGroup(String candidateGroup) removes all assigned tasks by adding "assignee = null" to the query.

I understand the idea that an assigned task should no more be visible by other users. But this is now hard coded into the query API and disallows other use cases like the one i described above. And i am sure this is a very common use case. If "assignee = null" would be removed both use cases could simply be realized like this:

taskCandidateGroup(String candidateGroup) -> would select all tasks having the given candidateGroup (No more "assignee = null")
taskCandidateGroup(String candidateGroup).taskUnassigned() -> would select all tasks having the given candidateGroup and have no assignee set.

I know, backward compatibility could be an issue here. But i think it would be huge gain for Activiti developers. I saw a lot of forum posts regarding this problem.

Regards
Martin

Re: Select tasks by candidateUser or candidateGroups

jbarrez — Thu, 04 Oct 2012 15:50:37 GMT

Ok, Martin I'm convinced that this is indeed a valid use case.
I created http://jira.codehaus.org/browse/ACT-1395 to implement the feature

Re: Select tasks by candidateUser or candidateGroups

mschaefer — Fri, 05 Oct 2012 15:23:16 GMT

Ok, Martin I'm convinced that this is indeed a valid use case.
I created http://jira.codehaus.org/browse/ACT-1395 to implement the feature

Hi Joram
Thousand Thanks! Makes me really happy because i can stick with Activiti's API (which i really like btw) without an ugly hack.

Re: Select tasks by candidateUser or candidateGroups

fersmi — Thu, 18 Oct 2012 11:04:50 GMT

The idea behind is that you don't need candidate groups once you set the assignee. It's only until the user gives up the task (assignee is set to null), that the task is put back into the pool if the group.

Which use case are you thinking of that would invalidate that?

What do you think about add a new api like below?

taskService.createTaskQuery().taskCandidateUserOrGroup("kermit", "manager");

Yes, and second one for more candidate groups:


List<String> groups = new ArrayList<String>();
groups.add("manager");
groups.add("ceo");
taskService.createTaskQuery().taskCandidateUserOrGroupIn("kermit", groups);

Re: Select tasks by candidateUser or candidateGroups

kafeitu — Thu, 18 Oct 2012 11:27:28 GMT

The idea behind is that you don't need candidate groups once you set the assignee. It's only until the user gives up the task (assignee is set to null), that the task is put back into the pool if the group.

Which use case are you thinking of that would invalidate that?

What do you think about add a new api like below?

taskService.createTaskQuery().taskCandidateUserOrGroup("kermit", "manager");

Yes, and second one for more candidate groups:
List<String> groups = new ArrayList<String>(); groups.add("manager"); groups.add("ceo"); taskService.createTaskQuery().taskCandidateUserOrGroupIn("kermit", groups);

But the native query in version 5.11 can be used, so you can use it to query anything by native sql.

Re: Select tasks by candidateUser or candidateGroups

dognose — Mon, 22 Oct 2012 11:58:46 GMT

Hi,
I tried select all task by candidateUser or candidateGroups in TaskQuery

Why not:


List<Task> t1 = taskService.createTaskQuery().taskCandidateGroupIn(roleNames).orderByDueDate().asc().list();
List<Task> t2 = taskService.createTaskQuery().taskCandidateUser(user.getUsername()).orderByDueDate().asc().list();

foreach (Task t in t2){
  if (!t1.contains(t){
    t1.add(t);
  }
}
return t1;

or am i getting your question wrong?

Re: Select tasks by candidateUser or candidateGroups

frederikherema1 — Mon, 22 Oct 2012 13:34:23 GMT

Dognose, that's a current workaround that can be used. However, it involves pulling all tasks in-memory and filtering there. Would be better to have DB do the heavy lifting and joining and not waste memory

Re: Select tasks by candidateUser or candidateGroups

dognose — Mon, 22 Oct 2012 14:48:23 GMT

Dognose, that's a current workaround that can be used. However, it involves pulling all tasks in-memory and filtering there. Would be better to have DB do the heavy lifting and joining and not waste memory

Yes, it will pull some tasks that are actually not required…

So…

Better Workaround:
don't use "candidateUser" field, but wrap all Users into (virtual) one-man-groups (so called "OMG"s ) (dognose is member of omg_dognose)

Then you just need to translate the username to the omg-name and can receive all tasks by just querying for candidateGroups :shock:
(Dunno if your architecture will quickly allow such a fix)

(According to your snipped, you need just add the "role" omg_dognose to dognose and that's it)

Re: Select tasks by candidateUser or candidateGroups

frederikherema1 — Mon, 22 Oct 2012 14:52:16 GMT

OMG, indeed… Inventive workaround

Re: Select tasks by candidateUser or candidateGroups

fersmi — Wed, 24 Oct 2012 14:59:14 GMT

OMG… excelent!

Re: Select tasks by candidateUser or candidateGroups

bam — Mon, 13 Jul 2015 15:07:02 GMT

Hello everyone,

I'm having the same requirements, but can't find any way to do it with the Task queries…

I would like to list all tasks for a specific group (taskCandidateGroupIn), whether they are already assigned or not.
Could you please tell me how can I do that? It looks impossible… unless doing two queries (!).

Thank you,
Regards.

Re: Select tasks by candidateUser or candidateGroups

jbarrez — Tue, 14 Jul 2015 19:29:12 GMT

The current master branch has a way to do this, using or() with the taskCandidateUsers and taskCandidateGroupIn. It will be part of 5.18 (planned for end this month).