Question: defaultUserPermissionNameForTask = TASK_WORK difference in behvior between Legacy and CIB Seven Web Apps UI

[JavierPicon]

Hello,

Please excuse me if this is not the ideal place to raise this question. After reviewing the existing issues in this repository, this appeared to be the most appropriate location.
I am experiencing an authorization-related issue in the new cibseven Web Apps that I am unable to reproduce in the Legacy Web Apps.

Intended Authorization Behavior

For a User Task configured with an explicit Assignee:

The assignee should be authorized to:

• Query and view the task
• Claim (if applicable) and complete the task
  The assignee should not be authorized to:
• Update task metadata (e.g. change assignee or candidate users)
• Query or access tasks for which they are not authorized
  This authorization model behaves as expected in the Legacy Web Apps.

Observed Behavior in New Web Apps

• The task is created with the correct assignee.
• The “All Tasks” filter correctly reports the existence of one task.
• The task is not returned in task queries and therefore not rendered in the UI for:
• • The assignee, or
• • Any user who does not have the UPDATE permission on the Task resource.

Observed Behavior in Legacy Web Apps

• The task is created with an assignee.
• The assignee can:
• • Query and view the task
• • Complete the task
• The assignee cannot:
• • Reassign the task
• • Access tasks for which they are not authorized

Engine Configuration

According to the cibseven documentation on default task permissions (https://docs.cibseven.org/manual/2.1/user-guide/process-engine/authorization-service/#default-task-permissions), I configured the engine as follows:

• defaultUserPermissionNameForTask = TASK_WORK

I can confirm that, at runtime:

• An Authorization is created for the task with:
• • Resource type: Task
• • Resource ID:
• • Permissions: READ, TASK_WORK
• The correct user is set as the assignee of the task.

Authorization Setup

The following authorizations are configured for the assignee:
Application

• Resource type: Application
• Resource ID: tasklist
• Permissions: ALL

User

• Resource type: User
• Resource ID: *
• Permissions: READ

Authorization

• Resource type: Authorization
• Resource ID: *
• Permissions: READ

Filter

• Resource type: Filter
• Resource ID: All Tasks filter
• Permissions: READ

Process Definition

• Resource type: ProcessDefinition
• Resource ID: TestProcess
• Permissions:
• • READ
• • READ_TASK
• • CREATE_INSTANCE
• • READ_INSTANCE
• • TASK_WORK
• • READ_TASK_VARIABLE

Task
(automatically generated by the engine)

• Resource type: Task
• Resource ID: ID of the task created
• Permissions:
• • READ
• • TASK_WORK

Process Instance

• Resource type: ProcessInstance
• Resource ID: *
• Permissions:
• • READ
• • UPDATE
• • CREATE

No tenant-based authorizations are configured, as multi-tenancy is not enabled.

Key Observation

The task only becomes visible in the new Web Apps when one of the following is applied:

• defaultUserPermissionNameForTask is set to UPDATE, or
• The user is explicitly granted the UPDATE permission on the Task resource

Granting UPDATE permission allows the user to modify task properties (e.g. reassign the task), which conflicts with the intended authorization model.

Questions

1. Is the new Web Apps task query intentionally requiring UPDATE permission on the Task resource in order to return tasks?
2. Is READ + TASK_WORK expected to be sufficient for task visibility and completion in the new Web Apps?
3. Is there a recommended authorization configuration that allows:

• Task visibility and completion by the assignee
• Without granting UPDATE permission on the Task resource?

Thank you very much for your assistance.