Hi Nikhil, Good to hear, thanks for the feedback.
I think that the Apache Isis security module is great.
On Tue, Dec 12, 2017 at 8:27 PM, Patrick Pliessnig <p.pliess...@gmail.com>
wrote:
> :-)
>
> Am 12.12.2017 8:39 vorm. schrieb "Nikhil Dhamapurkar" <
> nikhil.dhamapur...@healthengine.com.au>:
>
> > Hi Patrick, Steve
> >
> > Thank for your responses, I have made the changes similar to what you
> guys
> > have suggested.
> > The context relating to desk / Org was helpful.
> >
> > I have flattened the many to many relation entity (practicePractitioner)
> > which relates a practice and a patient, the admin or a super user will
> link
> > a practitioner with a practice in this entity this way not exposing all
> > Practitioners to every user and this entity can have their own version of
> > Practitioner Name or Shortname as well.
> >
> > Also, to relate the Desk / Context instead of extending the
> > ApplicationUser class to save the current login information, I am saving
> > the UserRole and Practice its Organization in a separate table
> > (RoleMapping). I read the role mapping in the ApplicationTenancyEvaluator
> > and Hide or disable the entity based on this information
> >
> > Completed most of the changes yesterday and I can see I have the control
> > as needed for the entity based on these changes thank you for your
> > suggestions.
> >
> > Regards
> > Nikhil
> >
> > From: Patrick Pliessnig
> > Sent: 07 December 2017 11:42
> > To: users@isis.apache.org
> > Subject: Re: Tenancy restriction - entity that relates to more
> > thanoneOtherentity.
> >
> > I wonder whether a metaphor for context could do a better job?
> >
> > Say, 'desk' instead of context. Then the user would have a currentDesk on
> > login
> >
> > To model the desk an interesting question might be, who organizes the
> desk?
> > Is it the practice for more standardization or rather the practitioner
> for
> > more individualization?
> >
> >
> > Am 06.12.2017 11:35 nachm. schrieb "Stephen Cameron" <
> > steve.cameron...@gmail.com>:
> >
> > > Oops, ignore that comment in the Person about tenancy paths, they
> aren't
> > > needed (yet).
> > >
> > > On Thu, Dec 7, 2017 at 9:33 AM, Stephen Cameron <
> > > steve.cameron...@gmail.com>
> > > wrote:
> > >
> > > > Hi Nikil,
> > > >
> > > > The context switching that Patrick is speaking of is what I was
> > > suggesting
> > > > before, but to make this work I think you have to extend the default
> > > > application user and record the current context on your extended
> > > > ApplicationUser. I've just done a test on this for my cooperation
> > > project.
> > > > In my situatioin there is a many-to-many relationship between
> > > Organisation
> > > > and Person, ( I have an OrganisationPerson entity for the join, so
> can
> > > set
> > > > a status property for each, either active or inactive)
> > > >
> > > > So I have a Person that references a current Organisation (context)
> > > >
> > > > @PersistenceCapable(identityType = IdentityType.DATASTORE, schema =
> > > > "cooperation")
> > > > @Inheritance(strategy = InheritanceStrategy.NEW_TABLE)
> > > > @DomainObject()
> > > > public class Person extends ApplicationUser {
> > > >
> > > > /*
> > > > * Allow a default Organisation to be set on the current user.
> > > > *
> > > > * Organisations have a list of linked users/Persons, but one
> user
> > > > might link to
> > > > * multiple Organisations, but we want to restrict the visibility
> > to
> > > > one Organisation at a time.
> > > > *
> > > > * We restrict access to all data usinf the security module
> tenancy
> > > > path, but this requires
> > > > * a current Organisation, that is set here a login, by the user
> > > > having only one link to an
> > > > * Organisation, or, the user selecting one specifically. In the
> > > later
> > > > case the currently operating
> > > > * one will be saved from session to session.
> > > > *
> > > > */
> > > > @Column(allowsNull="true", name="organisation_id")
> > > > @Getter
> > > > @Setter(value=AccessLevel.PACKAGE)
> > > > private Organisation organisation;
> > > >
> > > > ...
> > > >
> > > > }
> > > >
> > > > Person is used by the security module instead of default
> > ApplicationUser
> > > > by having a domain service as follows:
> > > >
> > > > @DomainService(nature=NatureOfService.DOMAIN)
> > > > public class MyApplicationUserFactory implements
> > ApplicationUserFactory {
> > > >
> > > > @Override
> > > > public ApplicationUser newApplicationUser() {
> > > > final ApplicationUser object = new Person();
> > > > serviceRegistry.injectServicesInto(object);
> > > > return object;
> > > > }
> > > >
> > > > @javax.inject.Inject
> > > > RepositoryService repositoryService;
> > > > @javax.inject.Inject
> > > > ServiceRegistry2 serviceRegistry;
> > > > }
> > > >
> > > > Then to control what Organisation a person can see at any one time I
> > > have:
> > > >
> > > > @DomainService(nature = NatureOfService.DOMAIN)
> > > > public class TenancyPathEvaluatorForCooperation implements
> > > > ApplicationTenancyEvaluator {
> > > > @Override
> > > > public boolean handles(final Class<?> cls) {
> > > > return Organisation.class == cls;
> > > > }
> > > >
> > > > @Override
> > > > public String disables(Object arg0, ApplicationUser arg1) {
> > > > return null;
> > > > }
> > > >
> > > > @Override
> > > > public String hides(Object arg0, ApplicationUser arg1) {
> > > > if (((Organisation) arg0).equals(((Person)
> > > > arg1).getOrganisation()))
> > > > return null;
> > > > else
> > > > return "Organisation access prevented";
> > > > }
> > > > }
> > > >
> > > >
> > > > Note: This has yet to be extended to handle all classes that are
> linked
> > > to
> > > > an Organisation!
> > > >
> > > > One thing I have not done is to allow a user to switch their
> > > Organisation
> > > > context, this is simply done by presenting a list of Organisations
> > based
> > > on
> > > > the list of OrganisationPerson entities that reference their Person
> > > entity,
> > > > which is what the security module returns as the logged in user. I
> > think
> > > > this is how this should be accessed:
> > > >
> > > > Person user = (Person) userRepo.findByUsernameCached(
> > > > users.getUser().getName());
> > > >
> > > > @Inject
> > > > ApplicationUserRepository userRepo;
> > > > @Inject
> > > > UserService users;
> > > >
> > > > Steve
> > > >
> > > >
> > > >
> > > > On Thu, Dec 7, 2017 at 2:33 AM, Patrick Pliessnig <
> p.pliess...@gmx.net
> > >
> > > > wrote:
> > > >
> > > >> Hi Nikhil
> > > >>
> > > >> This note is not about tenancy but about domain model.
> > > >>
> > > >> It seems to me that your practitioners (users) switch contexts
> > according
> > > >> to their current needs. Such a context could define the practice
> which
> > > is
> > > >> used to filter patients or it could define a location out in the
> > > outback if
> > > >> it is a flying doctor. In the case of a location the context
> defines a
> > > >> collection of local practices to filter patients.
> > > >>
> > > >> If you model contexts as domain entities you could use them to
> filter
> > > the
> > > >> patients the way you want. The practitioner could create his own
> > > contexts
> > > >> and everytime he logs in he activates the context he needs or the
> last
> > > >> activated context is used. If he then wants to list all patients
> only
> > > the
> > > >> patients filtered by the active context are shown.
> > > >>
> > > >> hth
> > > >> Patrick
> > > >>
> > > >>
> > > >>
> > > >> Am 06.12.2017 um 15:07 schrieb Nikhil Dhamapurkar:
> > > >>
> > > >>> I have made some progress in implementing tenancy, I would like to
> > know
> > > >>> if there is a better way someone has tried to use Tenancy interface
> > > >>> ApplicationTenancyEvaluator to apply on embedded Collections ?
> > > >>>
> > > >>> Example:
> > > >>> Patient has many to many relationship with practice how can I
> best
> > > >>> Hide or Disable Practice that should not be shown to the logged in
> > user
> > > >>> when he views Patient?
> > > >>> Patient ←→ Practice ( many to many)
> > > >>>
> > > >>> Regards
> > > >>> Nikhil
> > > >>>
> > > >>> From: Nikhil Dhamapurkar
> > > >>> Sent: 01 December 2017 11:27
> > > >>> To: users@isis.apache.org
> > > >>> Subject: RE: Tenancy restriction - entity that relates to more than
> > > >>> oneOtherentity.
> > > >>>
> > > >>> Hi Steve, Patrick
> > > >>>
> > > >>> As Steve suggested I had a table where I had Practice to Role
> mapping
> > > >>> instead of user as one of the use case is to see all Patients
> > > belonging to
> > > >>> a role / Org which if we switch user and Practice we wont see all
> > > patients
> > > >>> belonging to an org but my approach can display or restrict based
> on
> > > one
> > > >>> role if the user belongs to more than one role hence its not
> entirely
> > > >>> useful as well.
> > > >>>
> > > >>> Based on the input I am planning to make below changes :
> > > >>>
> > > >>> As Patrick has suggested I will be creating an entity Patient (
> > > >>> PatientInternalDetails, PracticePatients) - internal details as
> > > things
> > > >>> like Medical records etc.
> > > >>> PracticePatients will have additional fields which are Ok to be
> > > >>> displayed to user with permissions, and we have taken a call that
> > > entity
> > > >>> Patient is Ok to be visible only to admin users ( say “/”).
> > > >>>
> > > >>> Also will be exploring : https://isis.apache.org/guides
> > > >>> /rgcms/rgcms.html#_rgcms_classes_super_AbstractViewModel
> > > >>> If I can make changes in view instead of Domain Model.
> > > >>>
> > > >>> Regards
> > > >>> Nikhil
> > > >>>
> > > >>> From: Stephen Cameron
> > > >>> Sent: 01 December 2017 03:37
> > > >>> To: users@isis.apache.org
> > > >>> Subject: Re: Tenancy restriction - entity that relates to more than
> > one
> > > >>> Otherentity.
> > > >>>
> > > >>> Or, maybe just switching the role and setting a practice value
> after
> > > >>> logging in, then you have to switch the role back to the simple
> > 'login'
> > > >>> one
> > > >>> on logout, so that the next time they login they'll see that simple
> > > >>> practice selection menu again.
> > > >>>
> > > >>> On Fri, Dec 1, 2017 at 7:49 AM, Stephen Cameron <
> > > >>> steve.cameron...@gmail.com>
> > > >>> wrote:
> > > >>>
> > > >>> I think that making use of a custom ApplicationUser (explained in
> the
> > > >>>> security module notes) with a property practice may be necessary.
> > > >>>>
> > > >>>> Then Practioners would either log in as a specific user depending
> on
> > > >>>> what
> > > >>>> practice they are working at, or you might be able to make a
> switch
> > > >>>> happen
> > > >>>> behind the scenes, such that they always login as one application
> > > user,
> > > >>>> with only 1 menu option allowing them to choose a practice and the
> > > >>>> system
> > > >>>> switches their application user to a practice specific generated
> > user
> > > >>>> with
> > > >>>> a role giving full menu access.
> > > >>>>
> > > >>>>
> > > >>>> On Fri, Dec 1, 2017 at 1:58 AM, Patrick Pliessnig <
> > > >>>> p.pliess...@gmail.com>
> > > >>>> wrote:
> > > >>>>
> > > >>>> Hi Nikhil
> > > >>>>>
> > > >>>>> I guess this ultimately relates to the question how a practice
> > knows
> > > >>>>> about
> > > >>>>> its patients and the related access path.
> > > >>>>>
> > > >>>>> With tenancy the answer is: the patients are the ones with access
> > > >>>>> rights
> > > >>>>> for the practice.
> > > >>>>>
> > > >>>>> Maybe you could use a practice attribute 'practicePatients'. Then
> > the
> > > >>>>> answer is: the patients are the ones that use the services of the
> > > >>>>> practice.
> > > >>>>> (Many to many).
> > > >>>>>
> > > >>>>> Patrick
> > > >>>>>
> > > >>>>>
> > > >>>>> Am 30.11.2017 12:58 nachm. schrieb "Nikhil Dhamapurkar"
> > > >>>>> <nikhil.dhamapurkar@
> > > >>>>> healthengine.com.au>:
> > > >>>>>
> > > >>>>> Hi,
> > > >>>>>
> > > >>>>> I am working on supporting Multi Tenancy in Apache ISIS I have
> > tried
> > > >>>>> both
> > > >>>>> 1) ApplicationTenancyEvaluator and 2) HasAtPath interfaces to
> > control
> > > >>>>> what
> > > >>>>> the logged in user can see or execute.
> > > >>>>>
> > > >>>>> I have been able to make them work to an acceptable state but I
> > face
> > > >>>>> issue
> > > >>>>> when I come across collections that are part of the entity I am
> > > >>>>> evaluating.
> > > >>>>>
> > > >>>>> My Domain model has Patient / Practitioner entity both these
> > entity
> > > >>>>> can
> > > >>>>> be
> > > >>>>> associated with Different Practices at the same time.
> > > >>>>>
> > > >>>>>
> > > >>>>> Example : PractitionerA belongs to PracticeA and PracticeB
> both,
> > > >>>>> logged
> > > >>>>> in User has “Role” to Access PracticeA.
> > > >>>>>
> > > >>>>> Issue with ApplicationTenancyEvaluator : since Practitioner and
> > > >>>>> Practice
> > > >>>>> have many to many relation even if the role has access to only
> one
> > > >>>>> practice
> > > >>>>> I’ll end up displaying PracticeB on wicket viewer which I want to
> > > >>>>> prevent,
> > > >>>>> Is it possible ?
> > > >>>>>
> > > >>>>>
> > > >>>>> Issue with HasAtPath :
> > > >>>>>
> > > >>>>> I am creating Path programmatically with pattern as :
> > > >>>>> ORG/org/PRACTICE/<practiceName>/ pattern which models a tree,
> > then
> > > I
> > > >>>>> can
> > > >>>>> control user access to more than one Patient data if user at path
> > is
> > > >>>>> /ORG/org Or restrict access to one practice
> > > >>>>> /ORG/org/PRACTICE/practiceA
> > > >>>>> If the Patient Entity is associated with more than one practice
> My
> > > >>>>> logic
> > > >>>>> will Break as I would not know what should be the context for the
> > for
> > > >>>>> ORG/org/PRACTICE/<WhatShouldBeHere?>
> > > >>>>>
> > > >>>>> Does anyone have a better solution to tackle tenancy for a
> > Collection
> > > >>>>> within an entity?
> > > >>>>>
> > > >>>>> Regards
> > > >>>>> Nikhil
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>>
> > > >>
> > > >
> > >
> >
> >
>
