1 Reply Latest reply on Apr 19, 2006 4:49 PM by Ronald van Kuijk

    usage/implementation of group tasklist / pooledactor / ...

    Ronald van Kuijk Master

      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.