On 31/05/2012 20:55, Bob Lannoy wrote:
> On May 31, 2012 4:41 PM, "Francesco Chicchiriccò" <[email protected]>
> wrote:
>> Hi Bob,
>> I've finally had chance to take a closer look at your requirements and
>> was able to spend some time looking at how such requirements could be
>> implemented in Syncope with as less modifications as possible.
> It seems that I went a bit wild on the modification side of things ;)
> I have still some remarks/questions.
>
>> I've just fixed (you have to wait for Jenkis to deploy new artifacts)
>> our standard UserController.activate() in order to be effective; here it
>> goes the (fixed) flow:
>>
>> 1. UserController.activate() is called via REST: just be sure to call
>> this method with an UserTO object where you actually put the token as
>> provided by the user (UserTO.setToken()).
> Ok this is what I needed, I'll change my frontend.
> I find it somewhat strange to pass a userTO just for the userid and the
> token. Wouldn't a simpler activate method make more sense e.g.
> activate/{userid}?token=...? This is similar to the link the user gets. Or
> is this against rest-principles?
Not at all, at least as far as I know :)
Anyway, I've opened SYNCOPE-91 for taking care of this suggestion of
yours (and more).
>> in your workflow XML. SyncopeUser.checkToken() will check if the token
>> is correct and still valid.
> As I explained in a previous post it makes sense to add a method to
> SyncopeUser that only checks for an expired token, e.g. hasTokenExpired().
> The workflow could then handle a wrong token and expired token as two
> different flows. I want to delete the user with an expired token. But I'm
> unable to, could you give an idea how this should be done in the Delete
> class of the workflow?
If you take a look at ActivitiUserWorkflowAdapter.delete() (this is
called by UserController.delete()):
doExecuteTask(user, "delete", null);
userDAO.delete(user);
This means that first the "delete" task is executed (possibly involving
the Delete class, if workflow XML says so), then user is effectively
deleted.
Unfortunately, I don't think that userDAO.delete() can be called by the
Delete class because it would be in a non-transactional scope; anyway,
you can give it a try.
Alternatively, you can think to put users to be deleted in a "sink"
status and to create a SchedTask for periodically cleaning up such
sinked users.
>> There is also a generic UserController.executeWorkflow() taking UserTO
>> and task name as parameters for this purpose.
> Ok this might be handy for my password reset flow. To be sure, an example
> from the default workflow:
> when the user is in "active" there are currently three paths. If I would
> want to push the user to the suspend state I call the executeworkflow with
> the userTO and "suspend" as taskId?
Correct in principle, but consider that suspend() and reactivate() have
their own methods. Such methods (alongside with activate()) will take
care of forwarding the given action to underlying workflow + propagating
the new user status to associated external resources, if requested /
necessary.
Regards.
--
Francesco Chicchiriccò
ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member
http://people.apache.org/~ilgrosso/
