"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. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4263431#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...