Thanks for adding some food for thought Oscar. There are more ways that lead to Rome [1] but with the given scenario I still would model it as part of the domain, rely on database queries for performance and maybe use app tenancy as a safeguard. Just a matter of taste I guess.
[1] https://en.wiktionary.org/wiki/all_roads_lead_to_Rome On 23 February 2016 at 20:59, Óscar Bou - GOVERTIS <o....@govertis.com> wrote: > > Hi David and Jeroen, > > Current Isis Security add-on has an interface, "WithApplicationTenancy”, > that can also be used to apply custom domain/business logic to resolve the > Application Tenancy to assign to a given entity. > By means of the tenancy path returned, you can determine the permissions > that the different roles or users will be over that entity. > That way, perhaps your need can be modeled by using custom-defined > “tenancy paths”, that allow to determine to whom allow to see a given > Entity. > See [1] for further details. > > So basically if, when you’re computing the Domain Object’s tenancy path, > you consider if current Isis logged user is associated with the general > admin, financial admin or user, you can properly return a string that > allows to view, edit or hide that domain object to the logged user. > > > > > An example implementation of overriding the tenancy path we have in > production is the next one. > Please, notice that the “Account” entity is linked to an ApplicationUser > as defined in the isis-module-security add-on. > > That way, the “security user” has an associated Domain Entity that can be > used to define business logic in the domain. > > > > > public abstract class AbstractMyProjectObject<T extends > AbstractMyProjectObject<T>> > extends AbstractDomainObject implements Comparable<T>, > WithApplicationTenancy { > > // ////////////////////////////////////// > // Application Tenancy. > // ////////////////////////////////////// > > protected static String TENANT_PATH_UNIVERSAL = "/"; > > @Property(hidden = Where.EVERYWHERE) > @Override > public ApplicationTenancy getApplicationTenancy() { > final ApplicationTenancy applicationTenancy = > this.applicationTenancies.findTenancyByPath(this.tenancyPath()); > > if (applicationTenancy == null) { > throw new FatalException("Domain Object without Application > Tenancy !!! That's forbidden."); > } > > return applicationTenancy; > } > > @Programmatic > public abstract String tenancyPath(); > > […] > } > > > public class Account extends AbstractMyProjectObject<Account> { > > […] > > // {{ ApplicationUser (property) > private ApplicationUser applicationUser; > > // Acts as a Title because ApplicationUser has #title() impl > @Column(allowsNull = "false") > @PropertyLayout(hidden = Where.ANYWHERE) > public ApplicationUser getApplicationUser() { > return this.applicationUser; > } > > public void setApplicationUser(final ApplicationUser applicationUser) { > this.applicationUser = applicationUser; > } > > // }} > > @Override > @Programmatic > public String tenancyPath() { > if (this.getApplicationUser() != null) { > return "/accounts/" + this.getApplicationUser().getName(); > } else { > return TenantMyProjectInternalUsers.TENANT_PATH_MyProject_ONLY; > } > } > } > > > public abstract class extends AbstractMyProjectObject<IE> { > > […] > > @Override > @Programmatic > public String tenancyPath() { > return TENANT_PATH_UNIVERSAL; > } > } > > > When an entity returns a “tenancyPath” of “/accounts/xxxx” only specific > users are allowed to see it. > > All entities whose “tenancyPath” is simply “/“ can be viewed by anybody. > > > > > HTH, > > Oscar > > > > [1] https://github.com/isisaddons/isis-module-security#application-tenancy > < > https://github.com/isisaddons/isis-module-security#applicationtenancypathevaluator > > > > > > > > > El 23 feb 2016, a las 18:37, Jeroen van der Wal <jer...@stromboli.it> > escribió: > > > > Hi David, > > > > Currently in isis-module-security a user can have multiple roles (general > > admin, financial admin, etc) and a single application tenancy (your > > regatta) which is not a perfect match for your requirements. Personally I > > would model an tuple entity like RegattaRole to specify the user, regatta > > and role type and use the security module for system roles like admin and > > user. > > > > Cheers, > > > > Jeroen > > > > > > On 23 February 2016 at 15:36, David Soff <da...@soff.nl> wrote: > > > >> Hello, > >> > >> I have been playing with ISIS some more and have a question concerning > >> multiple tenancies for a single user. > >> > >> The application I am working on is a rowing regatta management system. > >> I would like users to have scoped roles so that > >> user A can be: > >> - a general admin for regatta A > >> - a financial admin for regatta B > >> - a normal user (without privileges) for regatta C > >> > >> user B can be: > >> - a general admin for regatta B > >> - a financial admin for regatta C > >> - a normal user (without privileges) for regatta A > >> > >> There are no necessary commonalities between the regattas. > >> > >> Is a setup like this possible using ISIS-security or will I have to > build > >> something from scratch? > >> > >> thanks a million, > >> > >> David > >> > >
