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: [email protected] 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" < [email protected]>: > 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 < > [email protected]> > 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 <[email protected]> > > 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: [email protected] > >>> 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: [email protected] > >>> 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 < > >>> [email protected]> > >>> 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 < > >>>> [email protected]> > >>>> 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 > >>>>> > >>>>> > >>>> > >>> > >>> > >> > > >
