Re: object level ownership / tenancy

[Bilgin Ibryam]

Hi Dan,

great timing. I was looking at multi tenancy today and wanted to see
something different than the path concept (which is not very common
for implementing multi tenancy).

In your demo app, users bill/joe see the correct number of entities
(2), but the home page shows description "3 objects". I wonder why?


Thanks,
Bilgin

On 26 September 2016 at 15:38, Dan Haywood  
wrote:
> Hi Martin,
>
> Your post has prompted me to push out a new version of security module [1],
> 1.13.3.  (We also had a related requirement in Estatio, so a matter of
> killing two bird with one stone).
>
> So, there is now a more general optional SPI service which doesn't depend
> on the concept of application tenancy paths, instead it just gives the
> service the two objects to evaluate and asks it to say if they are visible
> (or hidden) and editable (or disabled):
>
>
> public interface ApplicationTenancyEvaluator {
> boolean handles(Class cls);  
> (1)
> String hides(Object domainObject, ApplicationUser applicationUser); 
> (2)
> String disables(Object domainObject, ApplicationUser applicationUser);  
> (3)
> }
>
>
>
> To test this, I knocked up a demo app; it's implementation of this service
> is:
>
> @DomainService(nature = NatureOfService.DOMAIN)public class
> ApplicationTenancyEvaluatorForConcerts implements
> ApplicationTenancyEvaluator {
> public boolean handles(Class cls) {
> return Concert.class.isAssignableFrom(cls);
> }
> public String hides(Object domainObject, ApplicationUser applicationUser) 
> {
> if (!(domainObject instanceof Concert)) {
> return null;
> }
> final Concert concert = (Concert) domainObject;
>
> final Optional roleIfAny =
> applicationUser.getRoles()
> .stream()
> .filter(role -> Objects.equals(role.getName(),
> concert.getName()))  (1)
> .findAny();
>
> return roleIfAny.isPresent()? null: "Requires role " +
> concert.getName();
> }
> public String disables(Object domainObject, ApplicationUser
> applicationUser) {
> return null;
> }
> }
>
>
>
> Hope that makes sense, let us know how you get on.
>
> Cheers
> Dan
>
>
> [1] https://github.com/isisaddons/isis-module-security
> [2] https://github.com/danhaywood/security-generalized-tenancy-app
>
>
>
> On 24 September 2016 at 23:53, David Tildesley 
> wrote:
>
>> Just read my own post. Sorry those chevrons were meant to be double, and
>> they are only indicating color modelling "archetypes"[1] - force of habit -
>> helps me conceptualize problem domains.
>>
>> [1] http://www.nebulon.com/articles/fdd/download/adspostera3.pdf
>>
>>
>>
>>
>> On 24-Sep-16 3:59 PM, David Tildesley wrote:
>>
>>> Hi Martin,
>>>
>>> You haven't described a  tenancy problem so I wouldn't necessarily try
>>> and bend that to your problem. I would model it in the domain and use
>>> domain behavior. The behaviour checks if the user is a member of a
>>> committee (Committee) in the role of managing (ConcertManager)
>>> the concert (Concert) before allowing operations on the
>>> concert component.
>>>
>>> Regards,
>>>
>>> David.
>>>
>>>
>>> On 23-Sep-16 6:07 PM, Martin wrote:
>>>
 Hello,

 We want to give ownership of specific objects in the domain model to a
 subset of users.

 Example: an application to manage concerts, and a subset of the users is
 the concert organization committee. The members of
 the organization committee can be added and removed at runtime or defined
 when creating a new concert object. A user can be assigned to be a member
 of multiple committees, and the members of a concerts organization
 committee should be granted permissions to manipulate the concert and its
 associated objects.

 I looked at the isis-security-module (
 https://github.com/isisaddons/isis-module-security) and also at the
 tenancy, but I had trouble figuring out if this could actually serve our
 needs.

 How would one go about this with apache isis?

 Thanks and regards,
 Martin


>>>
>>



-- 
Bilgin Ibryam
Camel Committer at ASF & Integration Architect at Red Hat
Blog: http://ofbizian.com | Twitter: @bibryam

Camel Design Patterns https://leanpub.com/camel-design-patterns
Instant Apache Camel Message Routing http://www.amazon.com/dp/1783283475

Re: object level ownership / tenancy

[Dan Haywood]

Hi Martin,

Your post has prompted me to push out a new version of security module [1],
1.13.3.  (We also had a related requirement in Estatio, so a matter of
killing two bird with one stone).

So, there is now a more general optional SPI service which doesn't depend
on the concept of application tenancy paths, instead it just gives the
service the two objects to evaluate and asks it to say if they are visible
(or hidden) and editable (or disabled):


public interface ApplicationTenancyEvaluator {
boolean handles(Class cls);  (1)
String hides(Object domainObject, ApplicationUser applicationUser); (2)
String disables(Object domainObject, ApplicationUser applicationUser);  (3)
}



To test this, I knocked up a demo app; it's implementation of this service
is:

@DomainService(nature = NatureOfService.DOMAIN)public class
ApplicationTenancyEvaluatorForConcerts implements
ApplicationTenancyEvaluator {
public boolean handles(Class cls) {
return Concert.class.isAssignableFrom(cls);
}
public String hides(Object domainObject, ApplicationUser applicationUser) {
if (!(domainObject instanceof Concert)) {
return null;
}
final Concert concert = (Concert) domainObject;

final Optional roleIfAny =
applicationUser.getRoles()
.stream()
.filter(role -> Objects.equals(role.getName(),
concert.getName()))  (1)
.findAny();

return roleIfAny.isPresent()? null: "Requires role " +
concert.getName();
}
public String disables(Object domainObject, ApplicationUser
applicationUser) {
return null;
}
}



Hope that makes sense, let us know how you get on.

Cheers
Dan


[1] https://github.com/isisaddons/isis-module-security
[2] https://github.com/danhaywood/security-generalized-tenancy-app



On 24 September 2016 at 23:53, David Tildesley 
wrote:

> Just read my own post. Sorry those chevrons were meant to be double, and
> they are only indicating color modelling "archetypes"[1] - force of habit -
> helps me conceptualize problem domains.
>
> [1] http://www.nebulon.com/articles/fdd/download/adspostera3.pdf
>
>
>
>
> On 24-Sep-16 3:59 PM, David Tildesley wrote:
>
>> Hi Martin,
>>
>> You haven't described a  tenancy problem so I wouldn't necessarily try
>> and bend that to your problem. I would model it in the domain and use
>> domain behavior. The behaviour checks if the user is a member of a
>> committee (Committee) in the role of managing (ConcertManager)
>> the concert (Concert) before allowing operations on the
>> concert component.
>>
>> Regards,
>>
>> David.
>>
>>
>> On 23-Sep-16 6:07 PM, Martin wrote:
>>
>>> Hello,
>>>
>>> We want to give ownership of specific objects in the domain model to a
>>> subset of users.
>>>
>>> Example: an application to manage concerts, and a subset of the users is
>>> the concert organization committee. The members of
>>> the organization committee can be added and removed at runtime or defined
>>> when creating a new concert object. A user can be assigned to be a member
>>> of multiple committees, and the members of a concerts organization
>>> committee should be granted permissions to manipulate the concert and its
>>> associated objects.
>>>
>>> I looked at the isis-security-module (
>>> https://github.com/isisaddons/isis-module-security) and also at the
>>> tenancy, but I had trouble figuring out if this could actually serve our
>>> needs.
>>>
>>> How would one go about this with apache isis?
>>>
>>> Thanks and regards,
>>> Martin
>>>
>>>
>>
>