Issue #JBPM-2537

[sebastian.s]

Hello Joram, hello everyone

https://jira.jboss.org/jira/browse/JBPM-2537

I have a question regarding this issue. I just saw that you have started to work on this in the trunk and I have two questions.

1) I don't understand the test case you've supplied. What's the reason for task2 and the second end state? They are not even connected to the start?? At first I thought I had misread the definition and so I copied it into a process definition file to visualize it with the GPD.

2) I did not know you've started to work on this and I tried to resolve this issue with my limited knowledge on my own right now. Within TimerImpl I checked if the activity of the execution was of type task and in case of this was true I retrieved the task-object and called OpenTask.delete().

 boolean activityIsTask = false;
 OpenTask task = null;
 ActivityImpl activity = execution.getActivity();

 // TODO: Is there a constant or something to access the element's XML-name??
 if(activity.getType().equals("task")) {
 task = execution.getTask();
 if(task == null) {
 // this should not happen or something is really wrong
 throw new JbpmException("activity is of type task but task could not be retrieved");
 }
 }

.. after execution has moved on ..

 if(activityIsTask) {
 task.delete(this.getEventName());
 }

Afterwards I saw your test case failing since the task was now deleted and not completed but your test case checks if the task is closed/completed when the timer fires.

Wouldn't it make more sense to delete the task? Completing it does not seem right since it was open and not completed when the timer fired. Especially in from a reporting perspective it does not make sense, does it?
When you run a report on the gathered process data it seems as if this task was completed by its assignee although it was not.

Actually I thought you agreed on this view because you stated in the comments that deleting would be logical. :)

Thanks for any clarifications.

Have a nice weekend

Sebastian

[sebastian.s]

The source code posted is faulty. I did not set activityIsTask to true. However I have 2 problems:

I don't manage to retrieve the task. I can get the execution but getTask() returns null. Furthermore the constructor of TaskDelete which is fired when delete() is called on a task-object checks if the task is related to an execution and prevents deletion in such case.

 public TaskDelete(TaskImpl task, String reason) {
 if (task.getExecution()!=null) {
 throw new JbpmException("tasks related to an execution must be completed. they cannot just be deleted");
 }

 this.task = task;
 this.reason = reason;
 }

The task I intend to delete is related to an execution. So what about checking if it belongs to an active execution but allow deletion of it in case the execution has ended which should be the case when the timer has fired, right?

[jbarrez]

"sebastian.s" wrote:

1) I don't understand the test case you've supplied. What's the reason for task2 and the second end state? They are not even connected to the start?? At first I thought I had misread the definition and so I copied it into a process definition file to visualize it with the GPD.

The test process is just the one that is attached to the issue you mention. So it may not make sense, but I didn't want to change it because I wanted to replicate the issue as the poster intended

"sebastian.s" wrote:

2) I did not know you've started to work on this and I tried to resolve this issue with my limited knowledge on my own right now. Within TimerImpl I checked if the activity of the execution was of type task and in case of this was true I retrieved the task-object and called OpenTask.delete().

I didn't start working on the issue, I only made a test case to verify if the issue was correct. Which is the case.

"sebastian.s" wrote:

Afterwards I saw your test case failing since the task was now deleted and not completed but your test case checks if the task is closed/completed when the timer fires.

So the test was almost perfect ... almost ;-)

"sebastian.s" wrote:

Wouldn't it make more sense to delete the task? Completing it does not seem right since it was open and not completed when the timer fired. Especially in from a reporting perspective it does not make sense, does it?
When you run a report on the gathered process data it seems as if this task was completed by its assignee although it was not.

At first, I indeed assumed deleting the task was enough. But now I'm thinking about it: from a history perspective, the task existed for a while. So the task may be deleted (runtime data), but the history should reflect that the task has been open for a while, but a timer interrupted it.

I triggered Tom to take a look at the issue.

[kukeltje]

may I suggest thinking about introducing the cancelled state. Whatever will be implemented, I'll never change my opinion ;-)

[sebastian.s]

I think deleting a task (belonging to a process execution) is a basic and necessary thing. I see no problem from the side of reporting because there would still be a trace of the task in the history showing the deletion action and the reason. But maybe still important information is lost like the assignee of the task. If we don't want to lose information and more important if the deletion of tasks representing an activities within executions leads to difficulties or problems I would go for the cancelled state. I pretty much like Ronald's idea of an additional task state.

[kukeltje]

if (deleted == cancelled && relevantHistoryData.present() == true) {
 ronald.setHappy(true);
 ronald.whineMode(off);
}