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 >>>>> >>>>> >>>> >>> >>> >> >
