cancel
Showing results for 
Search instead for 
Did you mean: 

Select tasks by candidateUser or candidateGroups

fersmi
Champ in-the-making
Champ in-the-making
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!!
21 REPLIES 21

jbarrez
Star Contributor
Star Contributor
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.

fersmi
Champ in-the-making
Champ in-the-making
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();

kafeitu
Champ on-the-rise
Champ on-the-rise
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.

mschaefer
Champ in-the-making
Champ in-the-making
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

frederikherema1
Star Contributor
Star Contributor
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…

jbarrez
Star Contributor
Star Contributor
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?

kafeitu
Champ on-the-rise
Champ on-the-rise
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");

mschaefer
Champ in-the-making
Champ in-the-making
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, etcSmiley Happy
- 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

jbarrez
Star Contributor
Star Contributor
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