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