:-) Am 12.12.2017 8:39 vorm. schrieb "Nikhil Dhamapurkar" < [email protected]>:
> 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 > > >>>>> > > >>>>> > > >>>> > > >>> > > >>> > > >> > > > > > > >
