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