isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Cameron <steve.cameron...@gmail.com>
Subject Re: Can I make a specific class instance editable, all others not?
Date Thu, 24 Aug 2017 07:54:12 GMT
On Thu, Aug 24, 2017 at 4:17 PM, Kevin Meyer <kevin@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.62@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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message