Thanks I agree, option 1 is much better. As for my user case: I have a system that hosts a number or organizations orthogonally. What I need to do is associate each user to exactly 1 org so that he/she can only see and modify information belonging to that org.
After looking at the problem, I figure that the best way to do it would be to use the security module and add an Organization property to ApplicationUser. Unfortunately it seems I would have to fork the module and add my custom Orgnization domain object to it. On Wed, Nov 19, 2014 at 5:54 PM, Dan Haywood <[email protected]> wrote: > On 19 November 2014 16:41, Jeroen van der Wal <[email protected]> wrote: > > > Just double-checked: the master branch of isis-module-security uses the > > latest and greatest version of Isis, 1.8.0-SNAPSHOT > > > > [1] > > > > > https://github.com/isisaddons/isis-module-security/blob/master/pom.xml#L32-L36 > > > > > (though the screenshots in the README are still of 1.7.0) > > > > > > > On Wed, Nov 19, 2014 at 4:33 PM, Jeroen van der Wal <[email protected] > > > > wrote: > > > > > Hi Martin, > > > > > > I would advice against option 2 because you lose an easy update path to > > > newer versions of the security module. > > > > > > > +1 to that advice. > > > > > > > Tell us more about your use-case so we can see what the options are. > > > > > > > In particular, is the additional information you need to store mandatory > with no sensible default (ie would need to prompt for it), or would the > current signatures of the methods in ApplicationUsers domain service > suffice? > > > > > > > > Cheers, > > > > > > > > > Jeroen > > > > > > On Wed, Nov 19, 2014 at 2:24 PM, Martin Balmaceda < > > > [email protected]> wrote: > > > > > > -- to do is to be. dobedobedo
