Yes, according to the updates we cannot use the candidateGroups attribute because it results in showing the task to every other user in the role. (And not possible when users are in different roles)
Therefore, as an alternative, we can have the main user put in assignee attribute and rest of the candidate users in a variable within the process stored as a list. This will prevent the task visibility to other candidate users. When the main user fails to complete the task within the deadline, the timer boundary event will trigger the Java service task. Then within the Java service task, we can dynamically assign the task to next user by reading the list of candidate users saved inside the process variable. Best regards, Amal. On Thu, Apr 21, 2016 at 8:22 PM, Manuranga Perera <m...@wso2.com> wrote: > BTW, I have found a bit old discussion [1] on activity site. I am looking > to that options as well. > > [1] https://forums.activiti.org/content/dynamic-assignment > > On Thu, Apr 21, 2016 at 10:49 AM, Manuranga Perera <m...@wso2.com> wrote: > >> Hi Amal, >> Thanks for the suggestion. >> >> I have also considered that option. But I thought it had the following >> limitations: >> * When users are in different roles. Eg: "product lead" should take >> over when "team lead" is on vacation. But by default "team lead" shouldn't >> see all the tasks for "product lead" >> * Works when we want to specify 'candidateGroups' , but not when we >> need to specify 'assignee' >> >> May be these limitations are fine for the current use-case. I am also >> still gathering requirements. I'll keep this as the preferred option. Just >> wanted to see what are the other options. >> >> On Thu, Apr 21, 2016 at 10:29 AM, Amal Gunatilake <am...@wso2.com> wrote: >> >>> Hi Manuranga, >>> >>> What you have suggested is also possible. On the other hand, I have >>> another suggestion. >>> >>> When we assign user1 and user2 to the same role and then we define >>> only candidateGroups attribute to user task element, the tasks become >>> available to both users and who ever available can claim them and continue. >>> Also, we can have a timer boundary event to define a deadline and if the >>> first user fails to complete it on time then we could trigger a Java >>> service task that reassigns the task to next available user in the group. >>> >>> The above suggestion was given based on the details given in the thread, >>> not sure whether it best suits to all requirements. We can revisit the >>> scenario when there are more additional details. :) >>> >>> Best regards, >>> Amal. >>> >>> On Thu, Apr 21, 2016 at 7:16 PM, Manuranga Perera <m...@wso2.com> wrote: >>> >>>> I have the following requirement: >>>> >>>> * By default the given process's instance is claimable by user1 >>>> * But when user1 is on vacation (we have this data in a DB) we want >>>> user2 to be able to claim it >>>> >>>> I can think of two ways: >>>> >>>> 1. Create a temporary role and keep switching user1 and user2 in >>>> and out that role >>>> 2. Keep monitoring all claimable tasks and make it claimable to >>>> user2 if user1 is not there >>>> >>>> Is there a better way (eg: specify this requirement directly in BPMN). >>>> If not which is the better option? >>>> >>>> -- >>>> With regards, >>>> *Manu*ranga Perera. >>>> >>>> phone : 071 7 70 20 50 >>>> mail : m...@wso2.com >>>> >>> >>> >>> >>> -- >>> *Amal Gunatilake* >>> Software Engineer >>> WSO2 Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >> >> >> >> -- >> With regards, >> *Manu*ranga Perera. >> >> phone : 071 7 70 20 50 >> mail : m...@wso2.com >> > > > > -- > With regards, > *Manu*ranga Perera. > > phone : 071 7 70 20 50 > mail : m...@wso2.com > -- *Amal Gunatilake* Software Engineer WSO2 Inc.; http://wso2.com lean.enterprise.middleware
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
