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 >
