Select tasks by candidateUser or candidateGroups

[fersmi]

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

taskService.createTaskQuery().taskCandidateGroupIn(roleNames).taskCandidateUser(user.getUsername()).orderByDueDate().asc().list();‍

but I got

ActivitiException - Invalid query usage: cannot set both candidateUser and candidateGroupIn‍

My question is: If this select is not allowed why in iBatis query mapping is this:

    <if test="candidateUser != null || candidateGroups != null">
        and T.ASSIGNEE_ is null
        and I.TYPE_ = 'candidate'
        and 
        ( 
          <if test="candidateUser != null">
            I.USER_ID_ = #{candidateUser}          
          </if>
          <if test="candidateUser != null &amp;&amp; candidateGroups != null &amp;&amp; candidateGroups.size() &gt; 0">
            or
          </if>
          <if test="candidateGroups != null &amp;&amp; candidateGroups.size() &gt; 0">
            I.GROUP_ID_ IN
            <foreach item="group" index="index" collection="candidateGroups" 
                     open="(" separator="," close=")">
              #{group}
            </foreach>
          </if>
        )
      </if>
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

The mapping allows both candidateUser or candidateGroups at the same time.

And I need taht query!!

[mschaefer]

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.

[haja]

Thanks Martin for this use case and Joram. Indeed very required functionality.

I  have seen this functionality in Tibco iProcess and AMX BPM.

[fersmi]

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);


[kafeitu]

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.

[dognose]

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?

[frederikherema1]

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

[dognose]

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)

[frederikherema1]

OMG, indeed… Inventive workaround

[fersmi]

OMG… excelent! 

[bam]

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.