REST API - including candidateGroup param

I have a user task is configured as follows:

camunda:assignee=“admin” camunda:candidateGroups=“admin”

I am seeing peculiar behavior with the REST API… specifically with the Task List API where the I am testing out two different get requests:

The first is simply:

GET - “/task”

This returns all of the tasks associated with active process instances for the my task.

and the second is:

GET = “/task?candidateGroup=admin”

This call returns empty.

Further more if I look at debug logging that generates the sql output for these two calls I get the following:

GET - “/task”

… from ACT_RU_TASK RES order by RES.ID_ asc LIMIT ? OFFSET ?

GET = “/task?candidateGroup=admin”
…from ACT_RU_TASK RES inner join ACT_RU_IDENTITYLINK I on I.TASK_ID_ = RES.ID_ WHERE RES.ASSIGNEE_ is null and I.TYPE_ = ‘candidate’ and ( I.GROUP_ID_ IN ( ? ) ) order by RES.ID_ asc LIMIT ? OFFSET ?

So obviously the problem is WHERE RES.ASSIGNEE_ is null

My questions follow:

1- why does the REST API inject an assignee value when we ask for specific candidate groups?
2- If they are adding it for the candidate group parameter… why not add it for GET all?
3 - Where does the REST API get this value from?
4- Is there any way for me to override this behavior?

Thanks in advance for any help with this matter!

See https://docs.camunda.org/manual/7.6/reference/rest/task/get-query/ and the parameter includeAssignedTasks.

Cheers,
Thorben

2 Likes

Thanks. This solved the problem.

Good to know. The API is like that for historic and backwards compatibility reasons. I guess when this API was built, there was a use case where assigned tasks should not match the candidateX filters. Later on, we added includeAssignedTasks to offer the desired functionality and remain backwards compatible.

Ran into this problem today.

@thorben would you guys be open to a docs update in the CandidateGroup and CandidateUser params that indicate/note to look at the includeAssignedTasks param?

Sure. Please go ahead :slight_smile: