Cancelling task signals token over default transition.

[cpob]

See jira issue - http://jira.jboss.com/jira/browse/JBPM-710
and User Forums thread http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3960424#3960424

In short, when you cancel a task, it calls .end(); This calls the default transition. kukeltje recommended I reported it here as it might be seen by more developers.

Is there any specific reason why a cancel does this, or is it an oversight?

[kukeltje]

Chris,

imo it is an oversight. I can't think of a good reason.

What would you think of having an .cancel() take the default transition, having and .cancel(Transition trans) or .cancel(String transName) take the one specified. The required .end(...) methods are already available.

Not taking any transition is a difficult case. If this is the only task, the process would in in undefined state. If this task(node) is one of the teeth(?) of a fork, the join needs the token, so it has to take a transition for the join to work. Only if there are multiple tasks in a node this is an option. Let's leave this one out for the moment

[cpob]

I agree 100% with you. I saw your comments in the JIRA issue last night, and I would have suggested the same.

Thanks.

[tom.baeyens]

this is a tricky one.

currently, the cancel method indeed includes the call to end() on purpose. the desired behaviour in case one fo the task instances is cancelled depends on the process. it cannot be defined in a general manner.

in the current code, it would be the most logical to add the

.cancel(Transition trans)

and

.cancel(String transName)

methods

apart from that i have been thinking about abstracting the state machine inside of a task instance. states being: created, started, cancelled, suspended, and others are thinkable. i'm in doubt wether this justifies it's own statemachine (could be implemented in jpdl:-) or wether this just be a hard coded state machine.

[kukeltje]

I already added these in my local tree but I STILL HAVE TO WRITE TESTCASES TO PREVENT GETTING SPANKED ;-). Will check these in over the weekend.

Regarding the 'states' of a task, hardcoded would imo suffice for now. The started is interesting, it kind of allows the ok, I'm working on it, but do not leave the browser open. It can provide additional BI info since the actual duration of performing the task can be much shorter than the time between creation of the task and ending/cancelling it