Hi Vinod, Can you create a table with each permission and the actions allowed under the given permission. Then it will be easier to understand.
Regards Nandika On Thu, Aug 18, 2016 at 4:28 PM, Vinod Kavinda <[email protected]> wrote: > 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> > > -- Nandika Jayawardana WSO2 Inc ; http://wso2.com lean.enterprise.middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
