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