How to know whether a task has been completed versus deleted

Flowable Engine
1

Hi,
We are building a visualization of the running and finished task (so mainly a view on ACT_HI_TASKINST ; using the HistoricTaskInstance Query). When receiving questions for the business, or when investigation problems, it is important for administrators to known which tasks have been completed by which user at what time.

Our problem: It is appearantly not trivial to find out whether

  • a task has been completed by a user,
    versus:
  • a task has been ‘deleted’ (due to an interrupting boundary event, a termination of the subprocess scope, or a complete cancel of the process instance, … ).

Before flowable 6 , we could 'sort of ’ rely on the fact that the string “completed” was set for the delete_reason. In flowable 6, that seems to have changed, and a “NULL” delete_reason seems to imply that the task was effectively completed.

I’m not sure that this change was intentional. So for now, we’ll assume that a task has been completed if delete_reason = “completed” or delete_reason is null .

But such string comparison feels like a workaround for what should better be a structured piece of data.
What is the recommended strategy?
In my opininion, a valuable feature would be to add a column “completed_by” ; which would contain the userid of the person who completed a task. That would make our query easier : if completed_by is not null -> it was completed ; if null -> it was deleted.

That would also leave it open for Flowable users to choose whether it is permitted to complete a task by a user who is not the assignee. (because now, the only way to know who completed a task ; is to make sure you always call task.claim() before task.complete() ) .
I can image scenarios where an administrator needs to complete a task in place of the real ‘business user’ assignee ; but that you still want to see that original assignee instead of making the administrator the assignee.

Pieter

2

Hi Pieter,

All your proposals are good from my point of view. The simple process instance preview can use TaskHistory. There are few limitations there (e.g. multiinstance tasks, loops, time axe).


This example still uses History service, but if you want to really see what was happening in the engine you have to use event log.

Martin

3

Thanks Martin for your reply.

@tijs , @joram : Could you give your opinion? Would this be accepted as a contribution?

4

@pieterclaeys : missed this ping, apologies!

  • I agree with the completed by
  • I think the deleteReason should be properly filled for all use case and the collection of potential strings should be part of the API even.