I've not realy used the pooled actors functionality in jBPM and the restructuring of the webapp, in combination with realy using it in our company was a reason for me to look into this a little more.
My findings so far, working from cvs-head, is that 'we' seem to be thinking in two different directions. Let me explain why by showing the flow of a call to show the group tasklist where indentation is the nesting in the calls
* The new ui page mentiones a 'group task list'
* The method on the participantBean to display this tasklist is called 'getPooledTaskInstances'
---- o This method retrieves calls the method getUserPoolIds on the identity bean
-------- + In this method the getGroupNamesByUserAndGroupType on the identitySession which returns groupNames from the identity component (so the userPoolIds are in fact groupnames)
---- o From the taskMgmtSession the method findPooledTaskInstances is called with a parameter called poolIds (which in fact are groupnames)
-------- + In this findPooledTaskInstances the parameter is not called poolIds anymore, but actorIds. The named query is called "TaskMgmtSession.findPooledTaskInstancesByActorIds" in this named query, there is the pooledActor object with actorIds as parameter (remember the actorIds was a list of poolIds which in fact were groupNames)
This leads me to the conclusion that on one hand we want to really assign to a group and decide the moment the tasklist is shown how belongs to a group and on the other hand, like to have a list of actors who were member of the group the moment the task was assigned.
For me personally, I am in favour of the first, but if not the current mixture should be changed.
