On 29/03/2013 14:01, Walker, David R. (JMD) wrote:
Here is the bpmn we're using. Corrected for roles meant that the roles in the
default bpmn were not created at installation so I created new ones and
modified the bpmn to use the new role IDs. Pretty trivial and I shouldn't have
mentioned it. Also, it looks like we're on 1.0.6.
I will try to reproduce the problem you are experiencing with embedded
environment [3] and let you know but... after Easter ;-)
A comment on the workflow: the use of a single workflow to describe the entire
user lifecycle may not be scalable. I am curious as to why that approach was
taken. Is there a way to define additional processes and bind them to
resources and organizations? We are in a large organization composed of many
thousands of personnel residing in many tens if not hundreds of independent
and semi-independent components. Each of these has at least one and sometimes
many different approaches (procedures) to grant/remove access to systems and
facilities and permissions (authorized to carry a gun, for example). This is
not practical using the approach Syncope has taken, unless I'm missing
something. I would think that the ability to bind separate workflows to
assigned resources would introduce the flexibility we need to implement
processes that handle access to a resource for our organization.
Well, first of all let me say that you organization is challenging.
The workflow approach that you outline above is quite different from the
one implemented in 1.0.X and 1.1.X - I'd be happy if you can start a
[DISCUSS] thread about this topic on this mailing list, but nevertheless
this is not going to change anytime soon.
In principle, however, one could write a custom workflow adapter [4] for
the workflow engine that an organization like yours might have already
in place.
Regards.
-----Original Message-----
From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
Sent: Friday, March 29, 2013 4:07 AM
To: dev@syncope.apache.org
Subject: Re: Activiti approval fails on deny
Hi David,
you will find my replies embedded below.
Regards.
On 28/03/2013 21:23, Walker, David R. (JMD) wrote:
When using the default workflow (corrected for roles)
I guess you are running 1.1.0-SNAPSHOT: correct? What does "corrected for
roles" mean? Can you provide your userWorkflow.bpmn20.xml (or relevant fragments)
via http://apaste.info/?
the approval task will accept a response of "No" but the user is provisioned to
the denied resource anyway. What is the correct approach to denying access to one
resource but granting access to others?
Since the approval is currently implemented - in the default workflow
definition, at least - as a whole acceptance / reject, you would need to
implement this requirement by providing your own service tasks (e.g.
Java classes similar to [1] - in the hypotesis you are on 1.1.0-SNAPSHOT).
Scenario:
1. Admin creates a new user and with a resource of "Active Directory-IP" and a role
of "Active Directory User".
2. The role routes the action to a user task.
3. Another participant, the approver, picks up the user task on her ToDo
list and claims it.
4. The approver selects "No" on the Boolean
5. The task completes
6. The user is provisioned to Active Directory anyway.
Attempts to modify the workflow to delete the syncopeUser on a denial fail in that the
task ignores the "No" selection and remains on the ToDo list for the assignee.
In the default workflow definition [2], a "No" moves the user in a 'Rejected'
state and no propagation occurs at all: I think then that the problems you are observing
are highly dependent on the customization introduced. I need more details about these for
being able to provide some hints.
[1]
https://svn.apache.org/repos/asf/syncope/trunk/core/src/main/java/org/apache/syncope/core/workflow/user/activiti/task/Create.java
[2] https://cwiki.apache.org/confluence/display/SYNCOPE/Default+Workflow
[3]
https://cwiki.apache.org/confluence/display/SYNCOPE/Run+Syncope+in+embedded+mode
[4]
https://cwiki.apache.org/confluence/display/SYNCOPE/Choose+workflow+engine
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/