Hi Himasha, If a user has TASK UPDATE permission, he can do TASK_ASSIGN, TASK_WORK plus any other task updates such as updating a task variable, changing priority etc.
Regards, Vinod On Thu, Aug 18, 2016 at 4:06 PM, Himasha Guruge <[email protected]> wrote: > Thanks for the explanation Vinod. It's clear now. But given this > explanation what is the use of UPDATE? Either the user has one of > TASK_ASSIGN and TASK_WORK or has both. > > On Thu, Aug 18, 2016 at 3:56 PM, Vinod Kavinda <[email protected]> wrote: > >> Hi Himasha, >> >> There is no point of having permission for only claiming tasks if he >> can't complete it. >> >> TASK_WORK is important when we need to assign a task to a user to work on >> it, but he is not allowed assign it to someone or change task details. >> >> Regards, >> Vinod >> >> On Thu, Aug 18, 2016 at 3:44 PM, Himasha Guruge <[email protected]> >> wrote: >> >>> Hi Vinod, >>> >>> Can't we include complete task under UPDATE ? Then maybe we can have >>> TASK_CLAIM and UPDATE actions instead of TASK_WORK. >>> >>> Thanks, >>> Himasha >>> >>> On Thu, Aug 18, 2016 at 3:31 PM, Vinod Kavinda <[email protected]> wrote: >>> >>>> Hi all, >>>> >>>> Our existing implementation had only a few permissions on managing BPMN >>>> related tasks which are not sufficient for our REST based implementation. >>>> With the introduction of new REST APIs, we need to provide more >>>> fine-grained resource authorizations. So I have prepared the following >>>> permission scheme for our C5 based implementation. >>>> >>>> Resource Type Allowed Actions >>>> Deployment READ >>>> CREATE >>>> DELETE >>>> Process Definition READ >>>> UPDATE >>>> READ_HISTORY >>>> DELETE_HISTORY >>>> Process Instance CREATE >>>> READ >>>> UPDATE >>>> DELETE >>>> Task CREATE >>>> READ >>>> UPDATE >>>> DELETE >>>> TASK_ASSIGN >>>> TASK_WORK >>>> >>>> Most of the above terms are self-explanatory. >>>> >>>> TASK_WORK permission is required for claim and complete tasks. >>>> TASK_ASSIGN permission is required to change the assignees and candidate >>>> users related to tasks. However, the UPDATE permission is sufficient for >>>> both of these operations. >>>> >>>> In an implementation point of view, I believe we can load resources and >>>> actions through a policy file (Policy related component is still under >>>> development by IS team) and we can use the CAAS APIs to authorize users >>>> against each REST API method. >>>> >>>> -- >>>> Vinod Kavinda >>>> Software Engineer >>>> *WSO2 Inc. - lean . enterprise . middleware <http://www.wso2.com>.* >>>> Mobile : +94 (0) 712 415544 >>>> Blog : http://soatechflicks.blogspot.com/ >>>> [image: http://wso2.com/signature] >>>> <http://wso2.com/signature> >>>> >>>> >>> >>> >>> -- >>> Himasha Guruge >>> *Software Engineer* >>> WS*O2* *Inc.* >>> Mobile: +94 777459299 >>> [email protected] >>> >> >> >> >> -- >> Vinod Kavinda >> Software Engineer >> *WSO2 Inc. - lean . enterprise . middleware <http://www.wso2.com>.* >> Mobile : +94 (0) 712 415544 >> Blog : http://soatechflicks.blogspot.com/ >> [image: http://wso2.com/signature] >> <http://wso2.com/signature> >> >> > > > -- > Himasha Guruge > *Software Engineer* > WS*O2* *Inc.* > Mobile: +94 777459299 > [email protected] > -- Vinod Kavinda Software Engineer *WSO2 Inc. - lean . enterprise . middleware <http://www.wso2.com>.* Mobile : +94 (0) 712 415544 Blog : http://soatechflicks.blogspot.com/ [image: http://wso2.com/signature] <http://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
