"Claim" vs. "Set Assignee" vs. "Identity Links" REST API

Camunda 7 Topics Discussion & Questions
1

Can anyone provide a clear distinction and purpose of these REST APIs?

Basically, I want to assign/unassign/reassign a User Task to a particular user. Now I am not clear which one I should use. As part of assigning the User Task the User should also get the Authorization for that Task Instance.

1 Like
2

I am using Camunda 7.13 version.

In my case, I am using custom Authentication and Authorization means Users/User Groups do not exist in Camunda Database. But that comes from outside and is just a String for the Camunda engine.

Here are my findings for these Rest APIs. I hope it may help others:

== Claim Task ==

  1. Claim API does not work if the Task Id is already Assigned, which means the assignee is not null.
  2. If Task Id is not assigned then the given UserId in the payload will become the assignee.

Request Payload:
{“userId”: “newUser”}

will set the “newUser” as the assignee for the Task.
3. It will also add the required Authorization for the “newUser” in the ACT_RU_AUTHORIZATION table so that the assigned user can complete it.

== Unclaim Task ==

  1. It will unassign the User for the given Task Id.
  2. It will return HTTP Status Code 204, whether it is assigned or not assigned.
  3. This will not remove the Authorization for the previous assigned User in the ACT_RU_AUTHORIZATION table, so the previous User will still be able to Complete the Task from REST API because he has the authority to complete it.

== Set Assignee ==

  1. It will assign the new User for the given Task Id. It will work in both cases whether the Task is assigned or not assigned.
  2. Request Payload:
    {“userId”: “newUser”}

will set the “newUser” as the assignee for the Task.
3. It will also add the required Authorization for the “newUser” in the ACT_RU_AUTHORIZATION table so that the assigned user can complete it.
4. This will not remove the Authorization for the previous assigned User in the ACT_RU_AUTHORIZATION table, so the previous User will still be able to Complete the Task from REST API because he has the authority to complete it.

== Delegate Task ==

  1. The task is assigned to the newUser but the previous User becomes the Owner, and the Delegation State is changed to Pending.
  2. It will also add the required Authorization for the “newUser” in the ACT_RU_AUTHORIZATION table so that the assigned user can complete it.
  3. This will not remove the Authorization for the previous assigned User in the ACT_RU_AUTHORIZATION table, so the previous User will still be able to Complete the Task from REST API because he has the authority to complete it.

Note: All the above REST APIs work with only User Ids, and Group Id is not used anywhere.

== Add Identity Link ==

  1. This can be used to add a User or a User Group as a Candidate for the Task Id.
    You can provide only a groupId or a userId in the payload

Below Payload
{“groupId”: “aNewGroupId”, “type”: “candidate”}

adds a new group as candidate User Group
whereas below payload
{“userId”: “aNewUserId”, “type”: “candidate”}

adds a new user as a candidate User.

Trying these requests multiple times will just add the new User/User Group.
2. It will also add the required Authorization for the “newUser” in the ACT_RU_AUTHORIZATION table so that the assigned user can complete it.
3. Value for “type” can be “assignee” or “owner” and that works similar to assignee REST Task. But in this case, you can only use a User Id in the payload and not a Group Id.

== Delete Identity Link ==

  1. The same payload similar to Add Identity Link can be used, and it will get deleted from the assigned type, candidate or assignee, or owner.
  2. This will not remove the Authorization for the previous assigned User in the ACT_RU_AUTHORIZATION table, so the previous User will still be able to Complete the Task from REST API because he has the authority to complete it.

Note: Based on the above experiments my understanding is that

  • “candidate Users” and “candidate User Groups” are able to take action or you can say authorized to take action on the Task.
  • whereas an “assignee” is one particular User who is supposed to work on the assigned Task.
2 Likes
3

Hi @Himanshu_Singh,

thank you for writing this down!

I will save this thread as a bookmark and refer it to any training or workshop participant when they ask about the details of user assignment and candidates.

Cheers, Ingo

1 Like
4