1 2 Previous Next 20 Replies Latest reply on May 2, 2014 1:43 AM by Maciej Swiderski

    Having both ActorId and GroupId for HumanTask

    Arif Mohammed Novice

      1) If we have only 1 ActorId defined for a task the task will be assigned directly to that actor and it will be in Reserved state. PEOPLEASSIGNMENTS_POTOWNERS will have only 1 entry for that task(assigned to actor).

      2) If we have only 1 GroupId defined for a task the task will not be assigned to any user and it will be in Ready state - PEOPLEASSIGNMENTS_POTOWNERS will have only 1 entry for that task(assigned to group)

       

      The above 2 conditions are fine but if I define both ActorId and GroupId the task is not assigned to any user and it is in Ready state - PEOPLEASSIGNMENTS_POTOWNERS will have 2 entries(1 for a group and another for actor)

       

          In the above case task should have been in Reserved state and assigned to that actor since there is only one ActorId. Of course having GroupId will make sure that only the users from that group can claim that task in future with the help of UserGroupCallback. In this case I don't want the user to go and claim the task it should have been done automatically since ActorId is defined.

       

          Is this a bug ?

        • 1. Re: Having both ActorId and GroupId for HumanTask
          Demian Calcaprina Master

          I am not sure what the HT spec says about this. But both group and actor ids are put as potential owners and someone will have to claim it to work in this task. 

          • 2. Re: Re: Having both ActorId and GroupId for HumanTask
            Arif Mohammed Novice

            Hi Demian. I agree with you from potential owners point of view. If there are more than one potential owners(excluding the group) then it should go into Ready state. But why group is considered as individual potential owner ? Group should be there to restrict users i.e, any user from another group should not be able to perform any operation on that task.

            • 3. Re: Having both ActorId and GroupId for HumanTask
              Maciej Swiderski Master

              this is not a bug, it works as expected. If there are more than one potential owner it will always be in ready state so all potential owners have equal right to claim it. Otherwise we could end up in task being reserved by an individual and then any other potential owner would not have chance to claim and work on it.

               

              HTH

              • 4. Re: Re: Having both ActorId and GroupId for HumanTask
                Arif Mohammed Novice

                Hi Maciej,

                      I see 2 parts in your answer.

                        1) When you say "all potential owners have equal right to claim it", Does it mean a group can also claim a task ? No it can not. Lets go by example

                              Users : ARIF, JOHN

                              Groups: 10, 15

                              User to Group mapping which is dictated by UserGroupCallback

                                  10 ==> ARIF, JOHN

                                  15 ==> no users but this group exist

                             And organizationalentity table

                                dtype                    id

                                -------------------------------

                                User                     ARIF

                                User                     JOHN

                                Group                   10

                                Group                   15

                 

                              In this case when a task is created(taskId:1) and if its initially assigned to group 10  then it will be in Ready state and if you see PEOPLESASSIGNMENTS_POTOWNERS table you will see the entry as

                            task_id    entity_id

                            -------------------------

                            1              10

                          

                           Now as a group 10 if I claim the task as follows taskService.claim(1L,"10") It will fail with PermissionDeniedException. But as a user ARIF if I claim the task, I can do because I belong to that group 10. Now coming to your point, though there is only one potential owner(10) the task didn't went to Reserved State and also I can't claim the task with entity_id 10.

                 

                   2) When you say "If task is being reserved by an individual and then any other potential owner would not have chance to claim and work on it" . If I understood correctly that is how it should work. At any point of time only one user can work on a partcular task when its in Reserved state. If at all some one has to work on it, first it should be released by the owner and then other potential owner(User) can claim and start working on that task.

                  

                     So my understanding is when we say potential owner it holds good only for an individual not for a group, Group can't own a task it will be there in PEOPLEASSIGNMENTS_POTOWNERS table to enforce the rule that only the users from that group can claim/start etc. Correct me if Iam wrong.

                • 5. Re: Having both ActorId and GroupId for HumanTask
                  Maciej Swiderski Master

                  group by itself cannot claim a task only members of that group, that's why group is considered as potential owner to allow runtime resolution of members belonging to that group. Otherwise once task is created it would have fixed number of users so changes to group would not take effect.

                  Moreover if you need direct assignment to an actor you should specify only that actor, what is the reason to give the groups as well if members of that group won't be able to see that task as it is directly assigned to someone. Unless that person explicitly releases the task then the group assignment is useless. And because of that case when there is both actor and group given task is ready and eligible to be claimed by all potential owners.

                   

                  HTH

                  • 6. Re: Re: Having both ActorId and GroupId for HumanTask
                    Arif Mohammed Novice

                    OK l have a valid business use case where a task need to be assigned by default to a user of that group(say team lead or head of the group) and also it should be assigned to that group so that in future if that task can not be completed by that lead(say team lead or group left the organization) some one from that group should be able to claim and continue.If this is not possible( having both a owner and group) can I delegate a task to a group later by an Administrator(in my case he will be considered as super user)

                    • 7. Re: Having both ActorId and GroupId for HumanTask
                      Maciej Swiderski Master

                      for such cases there is a way to use rules that are triggered on add task operation which will allow you to change the assignment ands tat us, take a look at this test case for more details.

                       

                      HTH

                      1 of 1 people found this helpful
                      • 8. Re: Re: Having both ActorId and GroupId for HumanTask
                        Arif Mohammed Novice

                        Ok I understood the tricky part i.e, to add a rule which will take care of auto assignment. Following is the rule in the test case pointed by you. But user name is hardcoded in rule, I want the user name to be read from process variable, how can I do that ? sorry I am not much familiar with rules. Let me explain you little bit more in detail.

                         

                            1) I have different Business processes in my application

                            2) I am using session per process instance strategy.

                            3) Business process "approval-process" (attached) has 2 different types of user tasks (Build-Send, Approve)

                            4) While starting a new approval-process I will populate the process variable owner=ARIF [ ksession.startProcess("approval-process", initialParams); ]

                            5) The auto assignment rule should trigger only for the task "Build-Send" of this approval-process and should read the value of assignee from process variable "owner"

                            6) This one is related to getting group specific tasks I have 2 kinds of lists in my application myInprogressTasks list(tasks owned by me which are in InProgress) and myGroupTasks list (All tasks belonging to my logged in group say group 10, please note that I may belong to multiple groups(10,20,30) but I don't want the tasks of other groups say 20,30 ). I can get myInprogressTasks by using getTasksAssignedAsPotentialOwnerByStatus("ARIF", statusList, locale); But how do I get myGroupTasks list ?

                            7) Lastly as you can see in approval-process diagram "Boudary error catch event" is not working Can not create "boundary catch error event" on multi instance subprocess. Sorry I am asking all questions together because they are interrelated.

                         

                             Thanks in advance for the valuable help.

                           

                        rule "Assign to mary"

                            when

                                $task : Task()

                                PeopleAssignments(potentialOwners contains new UserImpl('mary')) from $task.getPeopleAssignments()

                            then

                                ((TaskDataImpl)$task.getTaskData()).setActualOwner(new UserImpl('mary'));

                                ((TaskDataImpl)$task.getTaskData()).setStatus(Status.Reserved);

                        end

                        • 9. Re: Having both ActorId and GroupId for HumanTask
                          Maciej Swiderski Master

                          you can reason based on task variables, see here for the rule and here for test case. So to make sure you have the owner available just make sure you add that process variable as task variable using data input and make use of it in rule. Include check for task name in the rule to only act on certain types of tasks and that should do what you need.

                           

                          when it comes to multi instance with boundary event, if you can create reproducer for just that case (simple test case to isolate the problem) - then file a jira with this test case and I'll try to take a look and if it's a bug fix it.

                           

                          HTH

                          • 10. Re: Having both ActorId and GroupId for HumanTask
                            Arif Mohammed Novice

                            Thanks Maciej for the help, I will try to write that rule. But it would be nice if jBPM can support this feature (assign the task to owner if there is only one owner no matter how many groups it has). As Demian stated above even I am not sure what WS-HT says about this.

                             

                               Also can you please help me with question 6 above ?

                            • 11. Re: Having both ActorId and GroupId for HumanTask
                              Arif Mohammed Novice

                              Hi Maciej.

                               

                                   I tried to implement the rule as you suggested but I am wondering how the Task object will be inserted as fact in working memory, I thought I could insert the Task as fact in task event listener i.e, TaskLifeCycleEventListener.afterTaskAddedEvent but I can't get reference to ksession object in that method. And also how the rule will be triggered(fireAllRules) on session since I don't have a rule node in my process.

                               

                                I see that in the pointed test case you are using RuleContextProvider and adding some jBPM internal services(AssignmentService), I didn't understood how this whole stuff works, could you please explain a little bit more ?  By the way Is this a new feature in version 6 ? and if so is this completed functionality which is ready to use ?

                               

                                Also can you please help me with question 6 above ?

                              • 12. Re: Having both ActorId and GroupId for HumanTask
                                Maciej Swiderski Master

                                rules evaluation for tasks is independent of the ksession used for processes. It relies on dedicated knowledge base that is built based on drl file found on classpath - so make sure you put default-add-task.drl on the root of the classpath and that file will be loaded automatically and rules will be used for every task. Alternatively you can configure rule context provider manually same way as it was done in the test cases. So the only thing you need to do is to write a rule and supply it to the rule context provider and that's it. Insert and fireAllRules will be done by task service on the time task instance is added to the service.

                                This was in 5.4 as well but slightly different implementation now it should be much easier to make use of it. And yes, that's complete functionality.


                                When it comes to question 6, the same method will give you group tasks when you query for Ready state although you will get tasks for all groups your user belongs to. This is by design to rely usergroup callback implementation to get all groups for a given user and return all tasks eligible for such user. There are some deprecated methods that allows you to provide group of users but it's considered as best practice to by pass user group callback as it's sort of going around the principle.


                                HTH

                                1 of 1 people found this helpful
                                • 13. Re: Re: Having both ActorId and GroupId for HumanTask
                                  Arif Mohammed Novice

                                  Hi Maciej,

                                      Awesome the rule is triggered by just placing the default-add-task.drl in classpath however the rule is not satisfying its LHS part due to the condition  $params : HashMap(this["owner"] != null) .  Following is the rule definition, If I remove the second line from LHS it works. I tried the option $params : HashMap(this["owner"] == null) just to make sure that there is no issue with task variable owner, but still it is not fired.

                                   

                                  package defaultPackage

                                  import org.kie.api.task.model.Task;

                                  import org.kie.api.task.model.User;

                                  import org.kie.api.task.model.Status;

                                  import org.kie.api.task.model.PeopleAssignments;

                                  import org.jbpm.services.task.rule.TaskServiceRequest;

                                  import org.kie.internal.task.api.model.InternalTaskData;

                                  import org.jbpm.services.task.impl.model.*;

                                  import org.jbpm.services.task.internals.lifecycle.*;

                                  import java.util.HashMap;

                                  import java.util.List;

                                  //declare any global variables here

                                  global TaskServiceRequest request;

                                   

                                  rule "Auto Assign To Owner"

                                      when

                                          $task : Task()

                                          $params : HashMap(this["owner"] != null)

                                      then       

                                          ((TaskDataImpl)$task.getTaskData()).setActualOwner(new UserImpl('AMOHAMMED'));

                                          ((TaskDataImpl)$task.getTaskData()).setStatus(Status.Reserved);

                                  end

                                  • 14. Re: Having both ActorId and GroupId for HumanTask
                                    Maciej Swiderski Master

                                    you need to make the owner to be task variable meaning it needs to be moved via data input and data input association on the given user task otherwise no data will be available there.

                                     

                                    HTH

                                    1 2 Previous Next