Who Approved?

[ashkumar]

We can assign a task to a pool of actors. If any one of these actors log in, he/she can see a set of tasks assigned to him. But we would like to know who completed the task. I think nowhere in jBPM can we get inormation about who (actor) completed the task when it is assigned to a pool of actors.

Would this be a Jira issue?

Thanks,

[camunda]

This already works with jBPM.

You can assign a task to a special actor (not the pool):

taskInstance.setActorId(actorId)

Then the actorId is set (and kept after ending a task), so that is al you need, that you know who has completed a task.

[ashkumar]

Thanks for you reply.

I do not want to assign a task to an actor. I want to assign to a pool.

But I want to know, which actor in the pool actually executed the task.

[m_ok]

I don't know if this can help, but what I did is set the actor id (setActorId()) on the TaskInstance before calling saveProcessInstance (you could modify the save() method of the webapp, if this is what you use).
It's not perfect, but that way, when a user clicks save or save and close, his id/name is set on the task instance.
Since the actor id on the task instance isn't null anymore, then it won't be retreived by the get pooled actors method and it won't appear on the other users tasks lists (if the user clicked save).
Then when you retreive the task instance from a task end log, for example, you have a good guess at who ended the task ; ).

[ashkumar]

m_ok ,
Thanks for your reply. But I am afraid your solution may not work. You see, when I assign a task to a pool of actors, and when I query to retrieve all the tasks an actor in the pool has, it checks to see if there is an actor assigned in the taskinstance table. If there is an actor assigned to the taskinstance, findPooledTaskInstancesByActorId returns no records.

Here is the corresponding Hibernate query.

"select distinct ti " +
"from org.jbpm.taskmgmt.exe.PooledActor pooledActor " +
" join pooledActor.taskInstances ti " +
"where pooledActor.actorId = :swimlaneActorId " +
" and ti.actorId is null " +
" and ti.end is null " +
" and ti.isCancelled = false";


Yes, we need to have a JIRA issue to remove the line

and ti.actorId is null

from the above query. That wold be the solution to this problem.
Does anybody in jBoss recommend opening a JIRA issue for this?

Thanks.

[m_ok]

My apologies, I guess I didn't understand your problem well? You said you wanted to know who completed a specific task. If you set the actorId to the actor that saved the task (there are much much better ways to do this I'm sure) , then when you get the TaskInstance from the TaskEndLog, you can call getActorId and you'll know who completed the task.

Short answer:
If what you really want is to know which tasks are assigned to a specific user, you should call both findTaskInstances(userId) and findPooledTaskInstances(userId). Because you want to know which task is assigned to that user and which pool of actors has that user.

Long answer/rambling/discussion:
Here's how I see (ie interpreted) how that part of jbpm is designed versus how I see it being applied.
In my app, a task's pool becomes irrelevant once a user as started working on that task. ie Other users shouldn't have to care about that task anymore.
For example, in a customer relationship situation where a user's problem is assigned to a customer support team, once a support agent takes that user's problem under his wing I wouldn't want the others to have that task assigned to them.
Setting the actorid in the task instance to that agent's name does exactly that and what you say it does: it isn't returned by getPooledActors anymore and that is exactly what I want.
If the agent should be discharged from the case (he's sick for example or keeps yelling at the customer : ) and the problem made available again for assignment, then setting the actor to null would again make it available to the team through getPooledActors and would not make it available to the sick agent through findTaskInstances(agentId). That is again exactly what I want.
I don't think it is a bug as the engine was thought up like that as that's what the doc says.
Feel free to correct me if I'm wrong, misunderstandings are so easy. : )