Thank you.

On Thu, Jan 21, 2016 at 11:17 AM, Francesco Chicchiriccò <
[email protected]> wrote:

> On 21/01/2016 15:59, Dhairya wrote:
>
> Thank you for a quick response. I was able to resolve the user login issue
> as per your fix but I'm still having hard time figuring out what needs to
> be done for multiple independent approval requests.  Could you please
> provide some suggestions/clues on what needs to be added/modified in the
> workflow to get multiple approval requests working?
>
>
> You essentially need to figure out first how to draw your wokflow with
> Activiti - possibly using the modeler which you can enable in the admin
> console [1] - then understand which tasks need custom implementation in
> Java, and write them down.
>
> As said, it is not easy and require consistent Activiti skills, but it's
> doable.
>
> Regards.
>
> [1]
> https://cwiki.apache.org/confluence/display/SYNCOPE/Enable+Activiti+Modeler
>
> On Thu, Jan 21, 2016 at 8:59 AM, Francesco Chicchiriccò <
> <[email protected]>[email protected]> wrote:
>
>> On 21/01/2016 14:49, Dhairya wrote:
>>
>>> I've been evaluating Syncope (v1.2.6) for about 3 weeks. I was able to
>>> figure out most of the stuff we need to do (like syncing, provisioning,
>>> basic role approval)
>>>
>>
>> Hi Dhairya,
>> this looks good.
>>
>> but we also have a requirement that user be able to submit multiple
>>> independent approval requests. I did setup basic approval as indicated on
>>> <http://blog.tirasa.net/approval-process-syncope.html>
>>> http://blog.tirasa.net/approval-process-syncope.html but it seems the
>>> user can only submit one approval request and once the user is waiting
>>> approval, he is unable to login into his own profile.
>>>
>>
>> You need to add the status in which the user is brought after the first
>> approval request to the "authentication.statuses" parameter - from admin
>> console go under Configuration then click on itemized list icon on top
>> right corner.
>>
>> The scenario we have is like this...
>>>
>>> We have several approval roles based on the application you're
>>> requesting access to.
>>>
>>> app-a-approver-role
>>>       app-a1-role
>>>       app-a1-role
>>>
>>> app-b-approver-role
>>>       app-b1-role
>>>       app-b2-role
>>>
>>> app-c-approver-role
>>>       app-c1-role
>>>       app-c2-role
>>>
>>> So if the user selects app-a1-role, app-b1-role, and  app-c2-role then
>>> we need to generate three independent approval request to
>>> app-a-approver-role, app-b-approver-role and app-c-approver-role.
>>>
>>> if app-a-approver and app-b-approver approve then the user will be
>>> assigned app-a1-role and app-b1-role and if app-c-approver-role rejects
>>> then the user won't be assigned app-c2-role.
>>>
>>> How do I setup something like this?
>>>
>>
>> Essentially, you'll need to expand the logic introduced in the post
>> mentioned above: it is indeed feasible, but not elementary.
>>
>> Regards.
>>
> --
> Francesco Chicchiriccò
>
> Tirasa - Open Source Excellencehttp://www.tirasa.net/
>
> Involved at The Apache Software Foundation:
> member, Syncope PMC chair, Cocoon PMC, Olingo PMC, CXF 
> committerhttp://home.apache.org/~ilgrosso/
>
>

Reply via email to