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.
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. Regards, Dave. -----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 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
