Candidate Groups for User Tasks apparently not taking effect

Camunda 8 Topics Discussion & Questions
1

Hi,

Please excuse me if this is a trivial question but I’m stuck on this and I’m unsure about the root cause. I’ve set Camunda 8 with Zeebe in my local by running this docker-compose config. So far so good. I was able to run user tasks, system tasks with nest.js, etc. The problem comes when I try to test how task assignation works for different user groups: if I have users A, user B and group G1, and A belongs to G1 but B does not, then I wouldn’t expect B to see task instances assigned to the G1 candidate group (B does not only see it; he can claim and execute them).

I tried different alternatives and read different sources but I can’t get it working.

How I set up my scenario:

I’ve created two users jpcarlino and jdoe and assigned the former to the Reviewer group. I did this using Keycloak (other places mentioned Camunda Console but it is not available in the official docker-compose, so I assume the way to do it in Camunda 8 is via Keycloak, please correct me if I’m wrong).

My workflow consists on a single user task called “test”.

The “test” task is configured with the candidate group “Reviewer” in the Assignment section (in Camunda Modeler).

However the user jdoe, who doesn’t belong to the Reviewer group can see it in Camunda Tasklist:

image
image2086×610 52.7 KB

Please note that in order to let jdoe access TaskList console, I had to give him the default Tasklist role in Keycloak, otherwise he will fail to login.

Any help on this will be appreciated.

Regards

1 Like
2

The way I evaluated it, the C8 Tasklist does not provide group functionality. This was still the case in the C7 Tasklist. The candidateGroups field is thus exclusively intended for the GraphQL Api. But I would like to have this confirmed again by an employee

For this reason, our companies are also asking themselves whether it makes sense to use C8 at all yet. The evaluation so far has not been in favor of C8.

1 Like
3

Thanks Anri for the quick answer. That would explain the issue I have. In such case I think the documentation could be updated. Hopefully we will get confirmation about this soon.

4

Update: I tried the TaskList GraphQL API. This is the sequence of steps:

  1. updated the tasklist client and set “Direct Access Grants Enabled” to ON in Keycloak
  2. Sent curl --location --request POST 'http://localhost:18080/auth/realms/camunda-platform/protocol/openid-connect/token' --header 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'client_id=tasklist' --data-urlencode 'client_secret=<secret>' --data-urlencode 'grant_type=password' --data-urlencode 'username=jdoe' --data-urlencode 'password=<pass>' to get a user JWT for jdoe (who is NOT a member of Reviewer).
  3. Got the JWT that I’ve subsequently used to issue curl --location --request POST 'http://localhost:8082/graphql' --header 'Content-Type: application/json' --header 'Authorization: Bearer <token>' --data-raw '{"query":"{\n tasks(query:{\n state: CREATED,\n candidateGroup: \"Reviewer\"\n })\n {\n name,\n assignee,\n taskState,\n candidateGroups\n }\n}","variables":{}}'
  4. I can see the pending tasks even if jdoe doesn’t belong to the candidateGroup.
1 Like
5

Hi @jpcarlino,

Thank you for mentioning it. We don’t have this feature implemented on the frontend side - it’s just implemented on the backend (API) side.

We have this item on the roadmap and will update you one we start working on this.

As the workaround, you would need to create your custom frontend and get the data via GraphQL.

Best,
Alex

2 Likes
6

Thank you @aleksander-dytko that clarifies the initial question.
I wonder why I couldn’t make it work using the GraphQL. See my previous reply for more details.

Regards

7

hey
is this functionality implemented in c7?