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?
   - What are the other privileges user get when he assigned as
   taskInitiator other than deleting that ht?

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

Reply via email to