within
On 27 September 2016 at 04:25, Martin <[email protected]> wrote: > > I was wondering whether instead of checking for role name / concert name > equality as in the "ApplicationTenancyEvaluatorForConcerts" it would also > make sense to associate the ApplicationUser entity with a Concert through > some Committee (n:m) and then make the decision based on > navigability/reachability? You could do it that way, but my strong preference is not to; I feel that the authorization concerns should be layered on top of the domain model, not something that the domain objects such as Concert know anything about. You can use domain event subscribers on the actions of your domain objects to veto or respond to interactions within your domain, see [1] > Or is that seen as bad design because entities > from external plugins/packages should not be associated to the plain domain > entities? > > exactly > Another question I need some clarification on: in case the ApplicationUsers > that can see the Concert are assigned different roles within the Committee, > the decision on whether a user can edit certain properties has be taken in > the entity itself (through hideXxxx etc...) or does this require another > evaluator? > > No, you should just be able to manage this using the roles/permissions/features of the security module [2]. Again, while you *could* do this using the hideXxx methods (eg using the UserService to obtain the identity of the current user), I don't think you should embed this security knowledge in your core domain. HTH Dan PS: could you subscribe to the users mailing list [3] so that I don't have to keep moderating your posts? thx. [1] http://isis.apache.org/guides/rgant.html#_rgant-Action_domainEvent [2] https://github.com/isisaddons/isis-module-security#add-permission-at-different-scopes [3] http://isis.apache.org/support.html#how-to-subscribe > > On Mon, Sep 26, 2016 at 11:46 PM, Dan Haywood < > [email protected]> > wrote: > > > Hi Bilgin, > > > > Good catch. > > > > It's because the HomePageViewModel#getObjects() is calling the > > ConcertRepository directly, rather than using the WrapperFactory. If the > > domain service is wrapped, then the objects that it returns are in effect > > filtered with respect to the current user. You can see this also in the > > integration tests 1]. > > > > > > I've made the fix [2]. > > > > > > Cheers > > Dan > > > > [1] > > https://github.com/danhaywood/security-generalized-tenancy- > > app/blob/master/integtests/src/test/java/domainapp/ > > integtests/tests/modules/simple/Concert_IntegTest.java#L78 > > [2] > > https://github.com/danhaywood/security-generalized-tenancy-app/commit/ > > 64282dc9110b7428835af7a671c962b2be7c9398#diff- > > 4ef1fac0cff7edc209b038f93834dde6R41 > > > > > > On 26 September 2016 at 17:36, Bilgin Ibryam <[email protected]> wrote: > > > > > 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 < > [email protected] > > > > > > 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<ApplicationRole> 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 > > > <[email protected]> > > > > 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 (<ppt>Committee) in the role of managing > > > (<role>ConcertManager) > > > >>> the concert (<moment-interval>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 > > > > > >
