You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by Nikhil Dhamapurkar <ni...@healthengine.com.au> on 2017/12/06 14:07:02 UTC
RE: Tenancy restriction - entity that relates to more than
oneOtherentity.
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 <st...@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....@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
>>
>
>
Re: Tenancy restriction - entity that relates to more thanoneOtherentity.
Posted by Stephen Cameron <st...@gmail.com>.
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....@gmail.com>
wrote:
> :-)
>
> Am 12.12.2017 8:39 vorm. schrieb "Nikhil Dhamapurkar" <
> nikhil.dhamapurkar@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.62@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.62@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.pliessnig@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.62@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.pliessnig@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
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>>
> > > >>
> > > >
> > >
> >
> >
>
RE: Tenancy restriction - entity that relates to more thanoneOtherentity.
Posted by Patrick Pliessnig <p....@gmail.com>.
:-)
Am 12.12.2017 8:39 vorm. schrieb "Nikhil Dhamapurkar" <
nikhil.dhamapurkar@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.62@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.62@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.pliessnig@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.62@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.pliessnig@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
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>>
> > >>
> > >
> >
>
>
RE: Tenancy restriction - entity that relates to more
thanoneOtherentity.
Posted by Nikhil Dhamapurkar <ni...@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.62@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.62@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....@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.62@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.pliessnig@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
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >
>
Re: Tenancy restriction - entity that relates to more than oneOtherentity.
Posted by Patrick Pliessnig <p....@gmail.com>.
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.62@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.62@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....@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.62@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.pliessnig@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
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >
>
Re: Tenancy restriction - entity that relates to more than oneOtherentity.
Posted by Stephen Cameron <st...@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 <st...@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....@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.62@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.pliessnig@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
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
Re: Tenancy restriction - entity that relates to more than oneOtherentity.
Posted by Stephen Cameron <st...@gmail.com>.
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....@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.62@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.pliessnig@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
>>>>
>>>>
>>>
>>
>>
>
Re: Tenancy restriction - entity that relates to more than
oneOtherentity.
Posted by Patrick Pliessnig <p....@gmx.net>.
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 <st...@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....@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
>>>
>>
>
>