Hi Harsha, Noted. Regards, Vinod
On Tue, Sep 22, 2015 at 2:23 PM, Harsha Thirimanna <[email protected]> wrote: > Hi Vinod, > Thanks for doing this again and > When you do this, please add the role as we did now and add an user that > is reading from the request. Then there will be a role to add any user to > get this rights except the user who initiated the request. > > > *Harsha Thirimanna* > Senior Software Engineer; WSO2, Inc.; http://wso2.com > * <http://www.apache.org/>* > *email: **[email protected]* <[email protected]>* cell: +94 71 5186770 * > *twitter: **http://twitter.com/ <http://twitter.com/afkham_azeez>* > *harshathirimannlinked-in: **http: > <http://lk.linkedin.com/in/afkhamazeez>**//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122 > <http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122>* > > *Lean . Enterprise . Middleware* > > > On Tue, Sep 22, 2015 at 2:08 PM, Vinod Kavinda <[email protected]> wrote: > >> Hi Chamila, >> I'll send the updated human task and bpel archives ASAP. >> >> Regards, >> Vinod >> >> On Tue, Sep 22, 2015 at 2:04 PM, Chamila Wijayarathna <[email protected]> >> wrote: >> >>> Hi Vinod, >>> >>> I have changed the request sent when a new workflow request is created >>> by adding logged in user's name as follows. >>> >>> <p:ProcessRequest xmlns:p=" >>> http://schema.bpel.mgt.workflow.carbon.wso2.org/";> >>> <p:uuid>c90be0a4-6c1a-4bc1-960a-c5f3ed97d001</p:uuid> >>> <p:eventType>ADD_USER</p:eventType> >>> <p:taskInitiator>admin</p:taskInitiator> >>> <p:parameters><p:parameter name="REQUEST >>> ID"><p:value><p:itemValue>4d79d641-b8f0-400d-86f8-c5ccd192249b</p:itemValue></p:value></p:parameter><p:parameter >>> name="Username"><p:value><p:itemValue>test50</p:itemValue></p:value></p:parameter><p:parameter >>> name="User Store >>> Domain"><p:value><p:itemValue>PRIMARY</p:itemValue></p:value></p:parameter><p:parameter >>> name="Roles"><p:value/></p:parameter><p:parameter >>> name="Claims"><p:value/></p:parameter></p:parameters> >>> < p:configuration> >>> <p:approvalStep> >>> <p:stepName>Step 1</p:stepName> >>> <p:humanTask> >>> <p:humanTaskSubject></p:humanTaskSubject> >>> <p:humanTaskDescription></p:humanTaskDescription> >>> </p:humanTask> >>> <p:role>admin</p:role> >>> </p:approvalStep> >>> </p:configuration> >>> </p:ProcessRequest> >>> >>> Can you please advice with necessary changes needed to be done at bpel >>> and humantask side? >>> >>> Thanks >>> >>> On Sun, Sep 13, 2015 at 7:18 AM, Hasitha Aravinda <[email protected]> >>> wrote: >>> >>>> Hi Chamila, >>>> >>>> Please find my answers inline. >>>> >>>> >>>> On Fri, Sep 11, 2015 at 10:02 PM, Chamila Wijayarathna < >>>> [email protected]> wrote: >>>> >>>>> Hi Harsha/Hasitha, >>>>> >>>>> So when creating a request, we are assigning the user who initiated it >>>>> as the taskInitiator for human tasks associated with it. If so I need >>>>> to clarify following points regarding that. >>>>> >>>>> - Is the 'taskInitiator' per ht role/property? >>>>> >>>>> Task initiator Configuration will look like this. >>>> >>>> <htd:taskInitiator> >>>> >>>> <htd:from>...</htd:from> >>>> </htd:taskInitiator> >>>> >>>> >>>>> >>>>> - What are the other privileges user get when he assigned as >>>>> taskInitiator other than deleting that ht? >>>>> >>>>> Please refer Operation Authorization table in >>>> http://docs.oasis-open.org/bpel4people/ws-humantask-1.1-spec-cs-01.html#_Toc261430341 >>>> >>>> >>>> Thanks >>>>> >>>>> On Fri, Sep 11, 2015 at 6:48 PM, Harsha Thirimanna <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> I discussed this with Hasitha, and above approach is possible. There >>>>>> is one change should be done that use taskInitiator instead of >>>>>> businessAdministrators >>>>>> because businessAdministrators has more permission than we expect. >>>>>> Then we can call 'skip' operation against taskid to exit the workflow >>>>>> request (*HumanTaskClientAPIAdmin*). After we exit from the human >>>>>> task, it should be release the bpel process and to do that we have to >>>>>> enable TaskCoordinationEnabled option in b4p-coordination-config.xml >>>>>> and humantask.xml files. >>>>>> >>>>>> @Chamila, We need to prepare bpel/ht package for this and call >>>>>> *HumanTaskClientAPIAdmin* from the IS to skip the workflow request. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> >>>>>> >>>>>> *Harsha Thirimanna* >>>>>> Senior Software Engineer; WSO2, Inc.; http://wso2.com >>>>>> * <http://www.apache.org/>* >>>>>> *email: **[email protected]* <[email protected]>* cell: +94 71 5186770 * >>>>>> *twitter: **http://twitter.com/ <http://twitter.com/afkham_azeez>* >>>>>> *harshathirimannlinked-in: **http: >>>>>> <http://lk.linkedin.com/in/afkhamazeez>**//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122 >>>>>> <http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122>* >>>>>> >>>>>> *Lean . Enterprise . Middleware* >>>>>> >>>>>> >>>>>> On Fri, Sep 11, 2015 at 6:11 PM, Harsha Thirimanna <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> adding Hasitha >>>>>>> >>>>>>> >>>>>>> *Harsha Thirimanna* >>>>>>> Senior Software Engineer; WSO2, Inc.; http://wso2.com >>>>>>> * <http://www.apache.org/>* >>>>>>> *email: **[email protected]* <[email protected]>* cell: +94 71 5186770 * >>>>>>> *twitter: **http://twitter.com/ <http://twitter.com/afkham_azeez>* >>>>>>> *harshathirimannlinked-in: **http: >>>>>>> <http://lk.linkedin.com/in/afkhamazeez>**//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122 >>>>>>> <http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122>* >>>>>>> >>>>>>> *Lean . Enterprise . Middleware* >>>>>>> >>>>>>> >>>>>>> On Fri, Sep 11, 2015 at 5:53 PM, Harsha Thirimanna <[email protected] >>>>>>> > wrote: >>>>>>> >>>>>>>> Hi Prabath, >>>>>>>> >>>>>>>> I went through this and as you said it should be possible to >>>>>>>> suspend the workflow request by the one who initiate the request (Not >>>>>>>> the >>>>>>>> one who create the workflow). According to the existing human task >>>>>>>> definition we can't do that. But as I feel it is not the limitation >>>>>>>> of the >>>>>>>> BPS. >>>>>>>> It is possible to do that with reading user name within the human >>>>>>>> task definition in run-time. To do that, what I did was, I pass user >>>>>>>> name >>>>>>>> as parameter with the workflow request and set it to the human task [1] >>>>>>>> element value. Then it is possible to suspend the workflow request who >>>>>>>> initiate that. >>>>>>>> >>>>>>>> @Nandika, is this correct approach to do that ? >>>>>>>> >>>>>>>> >>>>>>>> [1] peopleAssignments -> businessAdministrators >>>>>>>> >>>>>>>> >>>>>>>> *Harsha Thirimanna* >>>>>>>> Senior Software Engineer; WSO2, Inc.; http://wso2.com >>>>>>>> * <http://www.apache.org/>* >>>>>>>> *email: **[email protected]* <[email protected]>* cell: +94 71 >>>>>>>> 5186770 * >>>>>>>> *twitter: **http://twitter.com/ <http://twitter.com/afkham_azeez>* >>>>>>>> *harshathirimannlinked-in: **http: >>>>>>>> <http://lk.linkedin.com/in/afkhamazeez>**//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122 >>>>>>>> <http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122>* >>>>>>>> >>>>>>>> *Lean . Enterprise . Middleware* >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Sep 11, 2015 at 10:40 AM, Chamila Wijayarathna < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hi Prabath, >>>>>>>>> >>>>>>>>> Yes currently only the user who initiated workflow can delete it. >>>>>>>>> In human tasks side we have a different role per each workflow who has >>>>>>>>> authority to delete a human task. But we can't give permission for >>>>>>>>> that >>>>>>>>> role to delete a request since there can be several workflows >>>>>>>>> associated to >>>>>>>>> single requests. In that case where 'user1' try to delete a request >>>>>>>>> associated with two human tasks, he may have permission to delete >>>>>>>>> only one >>>>>>>>> human task. >>>>>>>>> >>>>>>>>> Thank You! >>>>>>>>> >>>>>>>>> On Fri, Sep 11, 2015 at 10:32 AM, Prabath Siriwardena < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> I guess the question here is related to deleting a workflow >>>>>>>>>> request itself - and as if I understood correctly from your >>>>>>>>>> description at >>>>>>>>>> the moment its user based. Only the user who initiate the workflow >>>>>>>>>> request >>>>>>>>>> can delete it ? This looks like a limitation.. Nandika/Chathura, >>>>>>>>>> WDYT..? >>>>>>>>>> >>>>>>>>>> Thanks & regards, >>>>>>>>>> -Prabath >>>>>>>>>> >>>>>>>>>> On Thu, Sep 10, 2015 at 9:12 PM, Chamila Wijayarathna < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Prabath/Pulasthi, >>>>>>>>>>> >>>>>>>>>>> Currently we are having some confusion about how to address >>>>>>>>>>> $subject. >>>>>>>>>>> >>>>>>>>>>> For now we support delete request operation and only the user >>>>>>>>>>> who initiated the request can delete it. >>>>>>>>>>> >>>>>>>>>>> For example let's assume we have a worflow associated with add >>>>>>>>>>> user operation. Then if a user called 'admin' add a new user to the >>>>>>>>>>> userstore 'user1'. Since a workflow is associated with this >>>>>>>>>>> operation user >>>>>>>>>>> will not directly added to the user store until the request get >>>>>>>>>>> accepted. >>>>>>>>>>> For the user who initiated the request, in this case 'admin' can >>>>>>>>>>> delete >>>>>>>>>>> (abort) the request if he needed before the human tasks associated >>>>>>>>>>> to it >>>>>>>>>>> get approved/rejected. >>>>>>>>>>> >>>>>>>>>>> For now how we handle this as follows. We keep a 'STATUS' >>>>>>>>>>> attribute with each request (here request means 'add user1 to user >>>>>>>>>>> store, >>>>>>>>>>> etc) and when user delete request we move the 'PENDING' request to >>>>>>>>>>> 'DELETED' state. This doesn't do any change at human task engine >>>>>>>>>>> side. >>>>>>>>>>> Associated human task will still be available there and relevant >>>>>>>>>>> authorities can still approve/disapprove them. When the task get >>>>>>>>>>> approved, >>>>>>>>>>> at call back we check if request has deleted and if deleted we >>>>>>>>>>> ignore the >>>>>>>>>>> callback received. >>>>>>>>>>> >>>>>>>>>>> The issue of this approach is for a deleted request, human tasks >>>>>>>>>>> associated with it at BPEL side is still available there and for >>>>>>>>>>> the person >>>>>>>>>>> who approve/reject it don't get any clue of that request has >>>>>>>>>>> deleted. Once >>>>>>>>>>> task is approved, we only show a console info that >>>>>>>>>>> 'approved/rejected >>>>>>>>>>> request has been deleted'. >>>>>>>>>>> >>>>>>>>>>> To address this [1] has reported that associated human tasks >>>>>>>>>>> should be deleted when request is deleted. >>>>>>>>>>> >>>>>>>>>>> Following is the approach that we can use to do this. When we >>>>>>>>>>> delete request, we send request id as parameter. But at IS side we >>>>>>>>>>> don't >>>>>>>>>>> keep details of human tasks associated with a request since Human >>>>>>>>>>> Task >>>>>>>>>>> engine does not support such thing. So we can extract all the >>>>>>>>>>> available >>>>>>>>>>> human tasks and check each and every tasks parameters (each human >>>>>>>>>>> task has >>>>>>>>>>> parameters such as operation type i.e. ADD_USER, ADD_ROLE, etc and >>>>>>>>>>> other >>>>>>>>>>> details related to it for example for a add user operation >>>>>>>>>>> username, roles, >>>>>>>>>>> claims, etc) with parameters we saved with request and request to >>>>>>>>>>> delete >>>>>>>>>>> tasks. Even though this is inefficient AFAIU this is the only way >>>>>>>>>>> we can >>>>>>>>>>> address this with out changing the BPEL and Human task APIs. >>>>>>>>>>> >>>>>>>>>>> Also when creating a workflow for example 'workflow1' a role >>>>>>>>>>> named 'Internal/workflow1' is created and only this role can delete >>>>>>>>>>> a human >>>>>>>>>>> task related to that workflow. So for a user who wants to delete a >>>>>>>>>>> request >>>>>>>>>>> he initiated,he may not have the permission to delete the workflow >>>>>>>>>>> associated with it. >>>>>>>>>>> >>>>>>>>>>> So how should we address above scenario? Please advice on how to >>>>>>>>>>> proceed. >>>>>>>>>>> >>>>>>>>>>> Thank You! >>>>>>>>>>> >>>>>>>>>>> 1. https://wso2.org/jira/browse/IDENTITY-3552 >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> *Chamila Dilshan Wijayarathna,* >>>>>>>>>>> Software Engineer >>>>>>>>>>> Mobile:(+94)788193620 >>>>>>>>>>> WSO2 Inc., http://wso2.com/ >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Thanks & Regards, >>>>>>>>>> Prabath >>>>>>>>>> >>>>>>>>>> Twitter : @prabath >>>>>>>>>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena >>>>>>>>>> >>>>>>>>>> Mobile : +1 650 625 7950 >>>>>>>>>> >>>>>>>>>> http://blog.facilelogin.com >>>>>>>>>> http://blog.api-security.org >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> *Chamila Dilshan Wijayarathna,* >>>>>>>>> Software Engineer >>>>>>>>> Mobile:(+94)788193620 >>>>>>>>> WSO2 Inc., http://wso2.com/ >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Chamila Dilshan Wijayarathna,* >>>>> Software Engineer >>>>> Mobile:(+94)788193620 >>>>> WSO2 Inc., http://wso2.com/ >>>>> >>>> >>>> >>>> Thanks, >>>> Hasitha >>>> >>>> >>>> -- >>>> -- >>>> Hasitha Aravinda, >>>> Senior Software Engineer, >>>> WSO2 Inc. >>>> Email: [email protected] >>>> Mobile : +1 201 887 1971, +94 718 210 200 >>>> >>> >>> >>> >>> -- >>> *Chamila Dilshan Wijayarathna,* >>> Software Engineer >>> Mobile:(+94)788193620 >>> WSO2 Inc., http://wso2.com/ >>> >> >> >> >> -- >> Vinod Kavinda >> Software Engineer >> *WSO2 Inc. - lean . enterprise . middleware <http://www.wso2.com>.* >> Mobile : +94 (0) 712 415544 >> Blog : http://soatechflicks.blogspot.com/ >> >> > -- Vinod Kavinda Software Engineer *WSO2 Inc. - lean . enterprise . middleware <http://www.wso2.com>.* Mobile : +94 (0) 712 415544 Blog : http://soatechflicks.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
