On 27/04/2012 08:08, Bob Lannoy wrote: > > On Apr 26, 2012 5:45 PM, "Francesco Chicchiriccò" <[email protected] > <mailto:[email protected]>> wrote: > > No: one should first read the UserRequest object, then get UserTO / > UserMod / userId (depending on the nature of the UserRequest: create / > update / delete), next call the corresponding REST method on > UserController, finally remove the UserRequest object. > > > > Are you proposing to encapsulate the logic reported above in a > single REST method? > > It think it would make more sense to have a real workflow like for > user objects underneath. That way the handling of the user request > can be more configurable and would be more integrated in core. If I > want a userrequest without the intervention of some conversion I have > to implement this in the front end. It seems more logical to me to > have that as a process in core. > Of course at that point userrequest and user look very similar. >
Exactly: if you don't want "conversion" from UserRequest to User, then just give anyone the possibility to create / update / delete users: ...a bit weak security-wise, isn't it? Anyway, as said above, it could make sense to encapsulate the logic of executing an UserRequest (either create / update / delete), under the approval of an admin user, instead of letting the admin console handle the different steps. In this way, if you want to customize anything about UserRequest execution, you can just override this method from the correspondent REST controller (customizing REST methods will be much easier and consistent than now in the future, according to our roadmap). Regards. -- Francesco Chicchiriccò Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/
