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 <cham...@wso2.com> 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 <hasi...@wso2.com> > wrote: > >> Hi Chamila, >> >> Please find my answers inline. >> >> >> On Fri, Sep 11, 2015 at 10:02 PM, Chamila Wijayarathna <cham...@wso2.com> >> 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 <hars...@wso2.com> >>> 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: **hars...@wso2.com* <az...@wso2.com>* 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 <hars...@wso2.com> >>>> wrote: >>>> >>>>> adding Hasitha >>>>> >>>>> >>>>> *Harsha Thirimanna* >>>>> Senior Software Engineer; WSO2, Inc.; http://wso2.com >>>>> * <http://www.apache.org/>* >>>>> *email: **hars...@wso2.com* <az...@wso2.com>* 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 <hars...@wso2.com> >>>>> 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: **hars...@wso2.com* <az...@wso2.com>* 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 < >>>>>> cham...@wso2.com> 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 < >>>>>>> prab...@wso2.com> 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 < >>>>>>>> cham...@wso2.com> 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: hasi...@wso2.com >> 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/
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
