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 <[email protected]>
> 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 <[email protected]> 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
>>
