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/ > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
