REST API /runtime/tasks not working with candidateUser?

miguel.pereira · March 26, 2019, 4:03pm

Hi,

I have defined several groups and users with Flowable IDM. Using the Flowable Workflow UI everything works as expected. I can see the user tasks for which my user ‘noc-tester’ is a candidate (tasks in my process are assigned to groups such as ‘nocran’, not directly users).

Using REST, I am able to filter tasks by candidateGroups with success.

Example:
http://localhost:8080/flowable-rest/service/runtime/tasks?candidateGroup=nocran returns the task “Create WO to 2nd Line” correctly.

User “noc-tester” is part of group “nocran” in IDM (and confirmed by using Flowable Workflow).

But using the same REST API, I am not able to filter tasks by candidateUser in the way I was expecting:

http://localhost:8080/flowable-rest/service/runtime/tasks?candidateUser=noc-tester

Always returns

{“data”:[],“total”:0,“start”:0,“sort”:“id”,“order”:“asc”,“size”:0}

Am I doing something wrong ? Why is the behaviour different between API and Flowable Workflow UI ? Is this the wrong API call?

Note: I am using REST with basic authentication and the default ‘rest-admin’ user. Postgres db, Flowable 6.4.1.

filiphr · April 1, 2019, 8:14pm

Hey @miguel.pereira,

The Flowable REST API doesn’t apply any permission resolution. This means that when you are querying over the REST API with candidateUser only it will only query for tasks where that candidateUser is directly involved. However, it won’t query for the groups. In order to query for the groups you would need to pass the candidateGroup(s) as well.

The Flowable Task UI Application performs a different query (includes the groups and user) for returning the data.

Cheers,
Filip

miguel.pereira · April 2, 2019, 8:23am

Hi Filip,

Many thanks for your clarification.

Well, maybe then the documentation should be improved.

Under the REST API “GET runtime/tasks” it states (see **)

candidateUser -> Only return tasks that can be claimed by the given user. This includes both tasks where the user is an explicit candidate for and task that are ** claimable by a group that the user is a member of **.

This was what led me to believe that the API did apply permission resolution.

Again, many thanks. I will use candidateGroups instead.

Cheers,
Miguel

miguel.pereira · April 2, 2019, 8:25am

Hi Filip,

Also note that my process had been migrated from activiti 5.22, and that the REST API in activiti did work as documented… So compatibility with activiti was broken in this case.

Best regards,
Miguel

carbon_60 · January 31, 2020, 10:20pm

I have downloaded the latest flowable 6.5.0. I tested the candidateuser on REST API interface, it seems working now. Here is what I did

I created two tasks, one is assigned to candidateGroup=managers, the other is to candidateGroup=approvers. I also created users admin and admin-approver in managers group and users approver and admin-approver in approvers group. So when I query with these users individually via REST API (POST to query/tasks), the correct set of tasks are returned.

However, when I tried to query with candidateGroups and candidateUsers, ALL the tasks are returned. That is not correct.

Robinyo · February 1, 2020, 10:19pm

Also, see: POST /runtime/tasks/{taskId}

filiphr · February 3, 2020, 8:22am

Hey @carbon_60,

Are you using query parameters or body when doing the query? When using the POST you should put the parameters in the body request (Query for Tasks). When doing a GET then as query parameters (List of Tasks).

Cheers,
Filip

carbon_60 · February 3, 2020, 6:09pm

Hi, Filip,

I used POST with json in the body.

Thanks, Joey

filiphr · February 4, 2020, 8:12am

Can you please share the entire body you used?

carbon_60 · February 14, 2020, 2:09pm

Hi, Filip,

Sorry for taking me this long. My DB was corrupted and I had to rebuild it. Now I have it.

Here is what I have. I built my spring boot by following the blog: https://blog.flowable.org/2018/12/19/building-your-own-flowable-spring-boot-application/

As far as I can tell, this blog builds almost identical application as flowable-rest.war is.

In my system, I have two groups: managers (admin, admin.approver) and approvers(approver, admin.approver). admin.approver user is in both groups.

I started two process instances, one is waiting for user task with candidategroup=managers and the other one with candidategroup=approvers.

If I do a GET http://winchester:8080/demo-flowable/process-api/runtime/tasks/, I saw both of the tasks:

Here is my POST query:

POST http://winchester:8080/demo-flowable/process-api/query/tasks

{ “candidateUser” : “approver” }

I got back one task:

{
“data”: [
{
“id”: “272613d1-4f31-11ea-9393-00155d7357f8”,
“url”: “http://winchester:8080/demo-flowable/process-api/runtime/tasks/272613d1-4f31-11ea-9393-00155d7357f8”,
“owner”: null,
“assignee”: null,
“delegationState”: null,
“name”: “Approve or reject”,
“description”: null,
“createTime”: “2020-02-14T08:51:51.703-05:00”,
“dueDate”: null,
“priority”: 50,
“suspended”: false,
“claimTime”: null,
“taskDefinitionKey”: “approveOrReject”,
“scopeDefinitionId”: null,
“scopeId”: null,
“scopeType”: null,
“tenantId”: “”,
“category”: null,
“formKey”: null,
“parentTaskId”: null,
“parentTaskUrl”: null,
“executionId”: “2704a918-4f31-11ea-9393-00155d7357f8”,
“executionUrl”: “http://winchester:8080/demo-flowable/process-api/runtime/executions/2704a918-4f31-11ea-9393-00155d7357f8”,
“processInstanceId”: “2702380d-4f31-11ea-9393-00155d7357f8”,
“processInstanceUrl”: “http://winchester:8080/demo-flowable/process-api/runtime/process-instances/2702380d-4f31-11ea-9393-00155d7357f8”,
“processDefinitionId”: “AccountOperation:1:ff1126d9-4f30-11ea-9393-00155d7357f8”,
“processDefinitionUrl”: “http://winchester:8080/demo-flowable/process-api/repository/process-definitions/AccountOperation:1:ff1126d9-4f30-11ea-9393-00155d7357f8”,
“variables”: []
}
],
“total”: 1,
“start”: 0,
“sort”: “id”,
“order”: “asc”,
“size”: 1
}

If I POST http://winchester:8080/demo-flowable/process-api/query/tasks

{ “candidateUser” : “admin” }

I got back the other task:

{
“data”: [
{
“id”: “5d553b7b-4f31-11ea-9393-00155d7357f8”,
“url”: “http://winchester:8080/demo-flowable/process-api/runtime/tasks/5d553b7b-4f31-11ea-9393-00155d7357f8”,
“owner”: null,
“assignee”: null,
“delegationState”: null,
“name”: “Approve or reject request”,
“description”: null,
“createTime”: “2020-02-14T08:53:22.607-05:00”,
“dueDate”: null,
“priority”: 50,
“suspended”: false,
“claimTime”: null,
“taskDefinitionKey”: “approveTask”,
“scopeDefinitionId”: null,
“scopeId”: null,
“scopeType”: null,
“tenantId”: “”,
“category”: null,
“formKey”: null,
“parentTaskId”: null,
“parentTaskUrl”: null,
“executionId”: “5d553b77-4f31-11ea-9393-00155d7357f8”,
“executionUrl”: “http://winchester:8080/demo-flowable/process-api/runtime/executions/5d553b77-4f31-11ea-9393-00155d7357f8”,
“processInstanceId”: “5d553b73-4f31-11ea-9393-00155d7357f8”,
“processInstanceUrl”: “http://winchester:8080/demo-flowable/process-api/runtime/process-instances/5d553b73-4f31-11ea-9393-00155d7357f8”,
“processDefinitionId”: “holidayRequest:1:143bb34c-4f31-11ea-9393-00155d7357f8”,
“processDefinitionUrl”: “http://winchester:8080/demo-flowable/process-api/repository/process-definitions/holidayRequest:1:143bb34c-4f31-11ea-9393-00155d7357f8”,
“variables”: []
}
],
“total”: 1,
“start”: 0,
“sort”: “id”,
“order”: “asc”,
“size”: 1
}

If I POST with body { “candidateUser” : “admin.approver” }, I got both tasks back:

{
“data”: [
{
“id”: “272613d1-4f31-11ea-9393-00155d7357f8”,
“url”: “http://winchester:8080/demo-flowable/process-api/runtime/tasks/272613d1-4f31-11ea-9393-00155d7357f8”,
“owner”: null,
“assignee”: null,
“delegationState”: null,
“name”: “Approve or reject”,
“description”: null,
“createTime”: “2020-02-14T08:51:51.703-05:00”,
“dueDate”: null,
“priority”: 50,
“suspended”: false,
“claimTime”: null,
“taskDefinitionKey”: “approveOrReject”,
“scopeDefinitionId”: null,
“scopeId”: null,
“scopeType”: null,
“tenantId”: “”,
“category”: null,
“formKey”: null,
“parentTaskId”: null,
“parentTaskUrl”: null,
“executionId”: “2704a918-4f31-11ea-9393-00155d7357f8”,
“executionUrl”: “http://winchester:8080/demo-flowable/process-api/runtime/executions/2704a918-4f31-11ea-9393-00155d7357f8”,
“processInstanceId”: “2702380d-4f31-11ea-9393-00155d7357f8”,
“processInstanceUrl”: “http://winchester:8080/demo-flowable/process-api/runtime/process-instances/2702380d-4f31-11ea-9393-00155d7357f8”,
“processDefinitionId”: “AccountOperation:1:ff1126d9-4f30-11ea-9393-00155d7357f8”,
“processDefinitionUrl”: “http://winchester:8080/demo-flowable/process-api/repository/process-definitions/AccountOperation:1:ff1126d9-4f30-11ea-9393-00155d7357f8”,
“variables”: []
},
{
“id”: “5d553b7b-4f31-11ea-9393-00155d7357f8”,
“url”: “http://winchester:8080/demo-flowable/process-api/runtime/tasks/5d553b7b-4f31-11ea-9393-00155d7357f8”,
“owner”: null,
“assignee”: null,
“delegationState”: null,
“name”: “Approve or reject request”,
“description”: null,
“createTime”: “2020-02-14T08:53:22.607-05:00”,
“dueDate”: null,
“priority”: 50,
“suspended”: false,
“claimTime”: null,
“taskDefinitionKey”: “approveTask”,
“scopeDefinitionId”: null,
“scopeId”: null,
“scopeType”: null,
“tenantId”: “”,
“category”: null,
“formKey”: null,
“parentTaskId”: null,
“parentTaskUrl”: null,
“executionId”: “5d553b77-4f31-11ea-9393-00155d7357f8”,
“executionUrl”: “http://winchester:8080/demo-flowable/process-api/runtime/executions/5d553b77-4f31-11ea-9393-00155d7357f8”,
“processInstanceId”: “5d553b73-4f31-11ea-9393-00155d7357f8”,
“processInstanceUrl”: “http://winchester:8080/demo-flowable/process-api/runtime/process-instances/5d553b73-4f31-11ea-9393-00155d7357f8”,
“processDefinitionId”: “holidayRequest:1:143bb34c-4f31-11ea-9393-00155d7357f8”,
“processDefinitionUrl”: “http://winchester:8080/demo-flowable/process-api/repository/process-definitions/holidayRequest:1:143bb34c-4f31-11ea-9393-00155d7357f8”,
“variables”: []
}
],
“total”: 2,
“start”: 0,
“sort”: “id”,
“order”: “asc”,
“size”: 2
}

However, If I POST with { “candidateUsers” : “foo” } or { “candidateGroups” : “foo” }, I also got ALL the tasks back, but according to document, only tasks assigned to group foo or user foo should have been returned. So I think this is a bug.

Topic		Replies	Views
Is it possible to restrict task query results to candidate groups over REST api? Flowable Engine	4	838	November 20, 2019
Able to claim task with user not in candidate group Flowable Engine	1	429	September 22, 2020
Querying candidate users / groups from TaskService Flowable Engine	0	859	January 17, 2020
Can I use candidateGroups to restrict user access to a task? Flowable Engine	2	551	November 27, 2019
Flowable user authorization on tasks Flowable Engine	1	396	October 2, 2019

REST API /runtime/tasks not working with candidateUser?

Related topics