Introduce taskState to runtime and history task API

[jyotisahu9]

User Story (Required on creation)

As a Operations engineer, I can keep track of the task state via Java or REST API.

Functional Requirements (Required before implementation)

• taskState field is exposed to the runtime and history task API

Technical Requirements (Required before implementation)

• Add taskState column to the runtime and historic task tables
• Populate the field along with the lifecycleState and reuse it as much as possible
• Expose the field in the task APIs*

Limitations of Scope

Hints

Goal for the request

Update Get Task API to add lifecycleState as output
Current API that retreives a task by id : /task/{id}
Current Response:

Proposed solution

Add taskState as response parameter

Current api returns details from ACT_HI_TASKINST table for a specific task id.
Task state is stored in ACT_HI_OP_LOG table. We will have to join ACT_HI_TASKINST with ACT_HI_OP_LOG table for ENTITY_TYPE_ = 'Task' to get task state.

Possible output:
Init
Created
Completed
Deleted
Updated

Alternatives considered

Create new api that returns taskState as response parameter.
In that case we will have to make 2 api calls, one is get api call to get task details
& other one is new api call to retrieve the task lifecycleState.

Links

• https://forum.camunda.io/t/task-state-in-camunda-7-vs-camunda-8/48746/3

Breakdown

Pull Requests

Beta Give feedback

1. Git issue 4046 : Persist taskState/lifeCycleState & return in get task and get history task api #4218
   +0
   

Dev2QA handover

• Does this ticket need a QA test and the testing goals are not clear from the description? Add a Dev2QA handover comment

[jyotisahu9]

I am working on this feature but unable to assign the issue to myself.

Could someone look into it.

Thanks

[yanavasileva]

Hi @jyotisahu9,

Thank you for raising this feature request.
Please fill out the details of User stories in the ticket's description and don't forget the reason/goal behind the request. What value the feature will add to your use case?

I am working on this feature

That's great, please don't forget to link the ticket to your pull request.

unable to assign the issue to myself

The tickets are being process by the team, no need for an action here.

Best,
Yana

[jyotisahu9]

Hi @yanavasileva ,

I have updated the feature details. Could you please review the same.

Thanks,
Jyoti

[yanavasileva]

Hi @jyotisahu9,

Please note that the lifecycleState (can be INIT, CREATED, COMPLETED, DELETED) is different from the described user operation entity operation type field (can be Create, Update, Assign, Delegate, Set Owner, etc.).
The task's lifecycleState at the moment is not persisted in the database.

In order to query for user operation log entities you can use the following REST API:
https://docs.camunda.org/rest/camunda-bpm-platform/7.20/#tag/Historic-User-Operation-Log/operation/queryUserOperationEntries
Note there's a taskId and entityType parameters so you can filter out logs for Task entities.

I still am not sure what do you want to achieve? Once you have the lifecycleState what will you use it for? Can you tell more about the use case?

Best,
Yana

[HarishMalavade]

@yanavasileva I and Jyoti work for the same team, the value of this is, we are building a custom tasklist screen where state of task needs to be displayed to our business operations associates and currently we did not had easy way to retrieve state other than user operation logs entries at the same time we dont wanna make an additional API call from our custom tasklist UI which would be a problem for performance. Hence we wanna modify existing GET /task/{id} API to return state which we already invoke from our tasklist. I believe there are few discussion from others who require this state in the forum.

Please see a screenshot of our custom tasklist UI where we need this

[jyotisahu9]

Hi @yanavasileva

I am proceeding with changes to persist lifeCycle status in new column TASK_STATE_ in ACT_RU_TASK table.

Will do required changes in Task entity classes & Task xml files.

All the task related API's like create, complete, delete that updates the lifecycle status will require code changes to persist taskStatus in new column. Also Get task api will have required changes to return task State as response parameter.

Please do let me know if you have any review comments.

Thanks,
Jyoti

[yanavasileva]

Hi @jyotisahu9 and @HarishMalavade,

I am sorry for the late reply. Thank you for the provided information.

Let's iterate once more to be sure what specifics do you require in this feature request. It's better to ensure the expectations and design are approved before doing the implementation. Otherwise a contribution can be rejected.

You query the runtime task table (ACT_RU_TASK), right? Therefore the listed tasks are only for open (not completed) tasks.
After that, I assume you are interested in the two states:

• whether the task is assigned and someone will be working on it
• or is the task is still not assigned
  The assigned state can be verified by the assignee field, from the shared screenshot I see you already have this information.

Do you query completed tasks, or with other words historic data, to populate your task list?
If not, I don't see what other status information you will need.

The listed possible output (Assign, Claim, ...) in the ticket description refers to actions that can be done on a task and not so much of a state.

Best regards,
Yana

[HarishMalavade]

@yanavasileva

Thanks for your response.
To build our tasklist we query both historic and runtime task data.
Our operations team needs ability to view and filter what tasks are open/created, completed, cancelled/deleted, assigned/unassigned, updated etc
We do understand for other status like assigned/claim/due etc can be derived based on existing output from GET /task API.

So for the scope of this work we are thinking we will add new column both in ACT_RU_TASK and ACT_HI_TASK table to persist lifecycle state(Init, created, completed, deleted, updated)
and update both GET List /task API Get /history/task API to return the persisted lifecycle status

This will help us avoid computing these status values based on other parameters and simplify our tasklist UI so we dont have to query Operational log.

We feel this also should be reusable by other community members that are building tasklist in C7 and we are excited and looking forward to make the code changes and contribute back to community.

[yanavasileva]

Hi @HarishMalavade,

Thank you for your input.

I guess you imply that a new field will be created for the lifecycle state. After briefly looking at the code, reuse of the lifecycleState can be considered but might poses a risk to break the current implementation where it's used.

Also if you need to track completed and/or deleted state, the information can be populated only in the historic table.

We feel this also should be reusable by other community members that are building tasklist in C7 and we are excited and looking forward to make the code changes and contribute back to community.

I see the potential there as well.

Feel free to proceed with the contribution, I will try to support you on the way.

Best,
Yana

[yanavasileva]

I am closing the ticket due to inactivity.
We can reopen the ticket, once a pull request is raised on the topic.

[jyotisahu9]

Hi @yanavasileva ,

I am working on this issue. I have already done code changes, swagger docs changes and just left with test case changes.

I will be creating PR to review soon.

Thanks,
Jyoti

[jyotisahu9]

Hi @yanavasileva ,

I have created a PR #4218 for this change .

Requesting your review.

Thanks,
Jyoti

[yanavasileva]

Changes are merged and will be available to test with the next alpha release: 7.22.0-alpha3 scheduled for Edit: July June.

[yanavasileva]

Dev2QA handover.

Feature report test

1. Spin up distro + db of your choice
2. Start some instances with user tasks
3. Create a standalone user tasks
4. Work with the tasks
   a) assign/unassign/set follow up
   b) complete
   c) delete (for example via Cockpit delete process instance

After each operation check via REST API what's the taskState of the task in:

• runtime
• history

Possible output:
Init
Created
Completed
Deleted
Updated

Documentation

• https://docs.camunda.org/rest/camunda-bpm-platform/7.22/#tag/Task/operation/getTask
• https://docs.camunda.org/rest/camunda-bpm-platform/7.22/#tag/Historic-Task-Instance/operation/getHistoricTaskInstances
• feature paragraph in release post: link