- Hi Martin, maybe you can try a solution that I made and that works for me at
the moment;
I defined a 'an abstrat secure object' that has the properties you are looking
for [1]
[1]
https://github.com/johandoornenbal/matching/blob/master/dom/src/main/java/info/matchingservice/dom/MatchingSecureMutableObject.java
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
wrote:
> On 19 November 2014 16:41, Jeroen van der Wal 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 >
> > 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
