Help getting all tasks for a user

[bsmithjj]

Hello,

I am trying to get all the tasks for a user.

By all tasks, I mean any task for which the user is:

a.) the actual actor

b.) a pooled actor

Is there a method in the API's that supports this? for example,

 jbpmContext.setActorId(someId);
 List tasks = jbpmContext.getEVERYTASK();

No, I don't mean, give me the tasks for which the user is a pooled actor and the actorId is null (as I've seen recommended in other posts on this topic in this forum - that approach seems a bit too obscure me speaking as user/consumer of this framework).

Thanks

[kukeltje]

If what there is is not sufficient for you and the proposed solutions are obscure (your words, not of many, many other users), then implement your own hibernate query et voila....

[bsmithjj]

kukeltje - are you a committer on this project?

[bsmithjj]

It looks like you are - I'll keep your response in mind when we're thinking about our which JBoss products we buy support for.

Thanks!

[kukeltje]

Please enlighten me what the relation to buying support is.
And yes, I am a committer but rarely do so. I mainly focus (voluntarily) on the forum and give feedback on the directions of developing features. That way the people more specialized in the internal workings of jBPM can focus on that area.

[estaub]

Ronald,

Brad thought you were being less than helpful, and was indicating that if that was a sample of what paid support would be like, he didn't think it would be worth the money. At least that's how I interpreted it.

Brad,

I'm puzzled... how are JbpmContext.getTaskList and JbpmContext.getTaskMgmtSession.findPooledTaskInstances different from what you need?
Were you looking for a single call that combined these two lists?

-Ed Staub

[bsmithjj]

Ed,

Were you looking for a single call that combined these two lists?

Yes - After scanning the documentation (no luck on this subject), and trying the various getTask*() method calls via several lengthy deployments, and then searching these forums, I finally figured out that I need to make the several calls. It also took me ... oh 2-3 hours to do what I 'feel' should have taken 20-30 minutes with decent docs and or API methods.

Obviously, I was a bit frustrated - mainly because I think findPooledTaskInstances

JbpmContext.getTaskMgmtSession.findPooledTaskInstances( .. )

is misleadingly named - here's the javadocs:

findPooledTaskInstances

public java.util.List findPooledTaskInstances(java.lang.String actorId)

 get the taskinstances for which the given actor is in the pool.

This documentation says nothing about requiring the actorId on a task to be null in order for the query to return results. I think it would be more aptly named:

findPooledTaskInstancesForTasksHavingActorIdEqualToNull()

- this is where my 'obscure' comment is coming from. In order for that call to work, when I add pooled actors to a task, I have to know to set the actorId on the task to null - figured out once I looked at the HQL query in the jBPM source code.

Anyway - I think jBPM is a great software component - It has a lot of promise for implementing workflow-type systems - I also think the documentation is horrible - in contrast, the Seam documentation (which led us to using jBPM on my current project) is great.

Thanks

[estaub]

Brad,

I disagree about findPooledTaskInstances, but that may be because we're coming from different assumptions about intended use. I'm new at this, so I could easily be confused.

I assume that a task with a null actorId has not been picked up by a particular actor, but may be picked up by anyone in the pool. A task instance with the actor Id set has been "locked" for completion by a particular user, and thus is no longer assigned to the pool as a whole.

So to my thinking, the implementation is correct, and as expected; once a task has been locked to a particular user, it's no longer in the pool. For the common use-case of creating a list of pooled tasks that actors may grab a task from, this is certainly the desired behavior.

I agree that the docs could be improved!

-Ed Staub

(P.S. Did we work together in Nashua?)

[kukeltje]

@Ed

Thats how I interpreted it to, but a public forum is different from paid support, anyone should know that, and being a committer is yet another subject.... that's why I was surprised.

@Everybody
People should take more time with an initial post, don't assume the reader has the same context as you has (hmm... I see a link to http://www.catb.org/~esr/faqs/smart-questions.html cumming up again..

@Brad: If you would have initially posted what you posted now, I would have agreed with you to a large extend. I even mentioned this to Tom a few months ago that this part of jBPM needs some refactoring. It realy does.... At least the names of some methods, variables etc... I agree with Ed that the implementation is correct.

[bsmithjj]

Ed,

We may have worked together - I haven't worked in Nashua, but I have worked with many developers from Nashua over the years in Boston and some of the the other surrounding towns. What are some projects you think we might have been on together?

On the jBPM stuff - I see now why you disagree - I am coming at the problem from the other direction (i.e. opposite the 'commone use-case'):

- I have a task that is assigned to an actor initially
-- A timer wakes up and if certain conditions are not met, the task gets moved to a pool of actors consisting of the original actor and someone else
- I incorrectly assumed all I had to do was add a pooled actor to the task and then the task could 'easily' be found for presentation in both users' work queues.
-- when this assumption proved to be incorrect and then I had to dig deeper into the jBPM system - that's where my frustration arose.

Anyways - thanks for the discussion