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
