Hi Dan,
I've used tenancies before to good effect to separate data by regions. In
this case I'll look to use them for different companies and then states
within companies (dreaming big!), your suggestion goes an extra step to
people within states within companies.
What I have done is to create a derived property which is a view-model of
the MyApplicationUser, this class is a conventional POJO, with public
getters and setters, made read-only with @DomainObject(objectType =
"OneId.IndividualViewModel", nature = Nature.VIEW_MODEL, editing =
Editing.DISABLED).
Thanks all
Steve
On Thu, Aug 24, 2017 at 6:34 PM, Dan Haywood <d...@haywood-associates.co.uk>
wrote:
> Hi Steve,
> As you point out, the user/role/permissions system of the security module
> is class-based, not instance-based.
>
> However, the security module also supports application tenancies. So you
> could support these use case by defining an ApplicationTenancy for each
> user, and then associating their ApplicatoinUser with that same
> ApplicationTenancy.
>
> For example,
>
> ApplicationUser "bill" has associated ApplicationTenancy "/people/bill"
> ApplicationUser "mary" has associated ApplicationTenancy "/people/mary"
> ApplicationUser "superuser" has associated ApplicationTenancy "/" (global)
>
> The out-of-the box ApplicationTenancyEvaluator would prevent bill from even
> seeing mary's user, and vice-versa, while "superuser" would be able to see
> and modify both. However, you can provide a custom implementation of an
> evaluator that could do any other rules.
>
> One limitation of the security module is that ApplicationTenancy is an
> entity, so you will end up with these extra objects. We've been discussing
> simply dropping this entity, so that a application tenancy path ("atPath")
> is simply a label.
>
> ~~
> An alternative approach would be to implement some sort of subscriber that
> would veto all edits for each user unless they are looking at their own
> object. you can use the security module's MeService for that, I think (or
> Isis' UserService otherwise).
>
> HTH
> Dan
>
>
>
>
>
> On Thu, 24 Aug 2017 at 08:54 Stephen Cameron <steve.cameron...@gmail.com>
> wrote:
>
> > On Thu, Aug 24, 2017 at 4:17 PM, Kevin Meyer <ke...@kmz.co.za> wrote:
> >
> > > Hi Steve,
> > >
> > > Why not use the isis-addons security module to only authorise users to
> > > edit their own profile?
> > >
> >
> > Oh, apologies, that is what I am using, but I think that if you have
> > permission to edit your own profile you can edit anyones if you get
> access
> > to it. The editing permission is on that class.
> >
> > I am using the MyApplicationUser class to represent people in my domain
> > model, so that leads to the problem. But I want to have people self
> > register (which the security module provides) and then optionally be
> given
> > extra roles to enable them to do more than just edit their own profile.
> >
> >
> > > In the past, I have implemented such security directly in the domain
> > > objects by using the isVisible() and disabled() methods on actions (or
> > > class level, depending) and then working with the session username...
> > >
> >
> > If I could get a class level disabled to work that would be a solution,
> but
> > am now thinking a view-model approach is more flexible. I never make a
> > reference to a MyApplicationUser instance public (visible), and provide a
> > view-model of it instead. All except where I allow access to the current
> > users profile.
> >
> > >
> > > Cheers,
> > > Kevin
> > >
> > > On 24 August 2017 06:14:47 CEST, Stephen Cameron <
> > > steve.cameron...@gmail.com> wrote:
> > > >Hi,
> > > >
> > > >I have implemented and extended version of ApplicationUser class
> called
> > > >MyApplicationUser to allow users to add more information to their
> > > >'profile'
> > > >in my web-app. They self-enrol (via initial entry of an email address,
> > > >then
> > > >following a link in a email sent to that address [1] ) and then add
> > > >more
> > > >details once they've created a user account.
> > > >
> > > >I now make use of the class MyApplicationUser more widely in the
> > > >application but this leads to the problem that one user can modify the
> > > >profile of another. Using the security module we can make all classes,
> > > >instances of a class VIEWING or CHANGING. It must be the later to be
> > > >able
> > > >to change their own record, but generally it should be VIEWING only.
> Is
> > > >there a way to achieve this.
> > > >
> > > >My alternative is to make use of the MyApplicationUser entity but to
> > > >display its property values as a read-only view-model when necessary,
> > > >that
> > > >is, as a derived property. At the moment, I am having some problems
> > > >with
> > > >this approach in terms of displaying collections of MyApplicationUser
> > > >as
> > > >collections (of more view models) in the view-model class.
> > > >
> > > >I was creating my view-model as a wrapper around a persistent entity,
> > > >it's
> > > >worked in the past but not working in this case, with some strange
> > > >effects,
> > > >like "Failed title". So setting actual properties in the view-model
> > > >class
> > > >(rather than making all getters call a getter of the wrapped object)
> > > >might
> > > >be necessary to take full advantage of session caching of view model
> > > >instances?
> > > >
> > > >I think using the view model approach might be the solution.
> > > >
> > > >Cheers
> > > >Steve
> > >
> > > --
> > > Sent from my Android device with K-9 Mail. Please excuse my brevity.
> >
>
