[
https://issues.apache.org/jira/browse/SYNCOPE-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13473067#comment-13473067
]
Francesco Chicchiriccò edited comment on SYNCOPE-219 at 10/10/12 7:52 AM:
--------------------------------------------------------------------------
I don't see any particularly useful or not useful allowing by default suspended
users to get updated, hence for me this is a 0; customizing the workflow
definition is in my experience one of major tasks to be accomplished in any IdM
deployment, hence default workflow is likely to be changed anyhow.
Consider that allowing suspended users to get updated could impact in
propagation to / synchronization from external resources, especially when
syncope user status is mapped to external resources' status: this only to say
that your proposed change might involve some integration tests refactoring.
Regarding your questions about 'enabled', if you take a look at
ActivitiUserWorkflowAdapter's source, you'll see that this variable is given as
parameter to the create() method: this makes possible for caller to
discriminate whether an user should get created as active or not.
One can easily get rid of AutoActivate: it is there as commodity placeholder
when more elaborated activation condition need to be defined.
+1 for moving user-related classes under
org.apache.syncope.core.workflow.activiti.user (thus preparing for
org.apache.syncope.core.workflow.activiti.role for SYNCOPE-173)
was (Author: ilgrosso):
I don't see any particularly useful or not useful allowing by default
suspended users to get updated, hence for me this is a 0; customizing the
workflow definition is in my experience one of major tasks to be accomplished
in any IdM deployment, hence default workflow is likely to be changed anyhow.
Consider that allowing suspended users to get updated could impact in
propagation to / synchronization from external resources, especially when
syncope user status is mapped to external resources' status: this only to say
that your proposed change might involve some integration tests refactoring.
Regarding your questions about 'enabled', if you take a look at
ActivitiUserWorkflowAdapter's source, you'll see that this variable is given as
parameter to the create() method: this makes possible for caller to
discriminate whether an user should get created as active or not.
+1 for moving user-related classes under
org.apache.syncope.core.workflow.activiti.user (thus preparing for
org.apache.syncope.core.workflow.activiti.role for SYNCOPE-173)
> Changing attributes of inactive users
> -------------------------------------
>
> Key: SYNCOPE-219
> URL: https://issues.apache.org/jira/browse/SYNCOPE-219
> Project: Syncope
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.0.1-incubating
> Reporter: Jan Bernhardt
> Priority: Minor
> Attachments: syncopeWorkflow.xml, Workflow-new.png
>
>
> I attached a visual representation of a modified workflow allows changing of
> attributes of suspended users (relied to [1]). I also attached a modified
> BPMN workflow for this purpose.
> After applying this workflow to my syncope instance I’ve got the effect, that
> users will be set active after any user updates. The attention was to be able
> of changing inactive (suspended) user attributes while these users remain
> inactive. I believe that the root cause for this behavior is that an
> attribute “enabled” is checked (Line 80) which is not set at this point. Why
> is this attribute (enabled) used instead of ${syncopeUser. getSuspended()} ?
> If the second case would be true, this should solve the current issue and
> then there would be no need for the AutoActivate serviceTask…
> In my opinion it should be possible to change attributes of suspended users
> by default. So my proposal would be to deliver my modified version with the
> standard installation of syncope.
> I also changed the naming in the workflow whenever possible without effecting
> the implementation to distinct between user workflows and other (e.g. roles,
> see SYNCOPE-173). My suggestion would be to move (refactor) all user workflow
> serviceTasks from “org.apache.syncope.core.workflow.activiti” to
> “org.apache.syncope.core.workflow.activiti.user”. By doing so it will be
> easier for SYNCOPE-173 to add role serviceTasks.
> [1]
> http://syncope-user.1051894.n5.nabble.com/Issue-with-importing-suspended-user-td5706694.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
