nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

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!!

Find more posts tagged with

Comments

jbarrez

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

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

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

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

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

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

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

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

jbarrez

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

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.

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:

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

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:

<br>List<Task> t1 = taskService.createTaskQuery().taskCandidateGroupIn(roleNames).orderByDueDate().asc().list();<br>List<Task> t2 = taskService.createTaskQuery().taskCandidateUser(user.getUsername()).orderByDueDate().asc().list();<br><br>foreach (Task t in t2){<br>&nbsp; if (!t1.contains(t){<br>&nbsp;&nbsp;&nbsp; t1.add(t);<br>&nbsp; }<br>}<br>return t1;<br>

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.

jbarrez

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

bam

OK great, I'll make a workaround until then.
Thanks.

haja

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

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