allow an ApplicationUser to be associated with multiple ApplicationTenancy's

[danhaywood]

Currently an ApplicationUser has an optional atPath, which specifies the (single) ApplicationTenancy to which they are related.

In Estatio we have a requirement for a user to be associated with multiple ApplicationTenancys, not necessarily hierarchical in nature. (There is also the requirement for a domain object to be associated within multiple ApplicationTenancy's, but that is application-specific and so doesn't impact this module).

What we are proposing is that we retain ApplicationUser#atPath, but remove the FK link to ApplicationTenancy. Instead, the interpretation of a user's atPath is application-specific; it could (as now) be considered to identify a single ApplicationTenancy, or it might instead be treated as a "specification" of a set of ApplicationTenancys to which the user belongs (similar to how a regex string identifies a set of matching values). Indeed, in Estatio we might well use a regex string.

This change will (in a minor way) break backward compatibility; ApplicationUser#getApplicationTenancy() will be removed, and the FK in the database will be removed.

To minimize disruption, though, we'll retain the ApplicationTenancy entity, as a way to enumerate all named application tenancies.

[oscarbou]

In my experience, has all sense for me.

[danhaywood]

From private email conversation with mwhesse:

The feature sounds interesting, and I already thought about wether a user shouldn't be able to belong to multiple tenants. But since you intend to remove the FK where will the model document which user belongs to which tenancy?

Dan's reply:

Our proposal is somewhat influenced by our existing legacy that ApplicationUser already has an atPath; in suggestion its value be treated like a regex, it is in a sense acting like a vector rather than a scalar.

An alternative approach would be to simply make the ApplicationUser <-> ApplicationTenancy into a many-to-many association rather than many-to-one. This tuple entity could be application-specific, it doesn't need to live in the security module. (You would probably then hide the ApplicationUser#atPath using a subscriber because it wouldn't have any meaning if you also had this tuple).

From what I understand this is something that be will be evaluated at runtime suing atPath, but how will I enable non-technical users to manage this association? From the runtime perspective I feel using regex to eval whether a user belongs to a tenancy is fine, but from a modelling / user-user perspective I'm not sure I understood how this should work?

Dan's reply:

At least for our use case, setting up app tenancies for end-users tends to be programmatic or is done by an administrator, so this isn't really a problem for us. There's nothing to prevent you from writing a mixin on ApplicationUser that could provide a better UI for non-administrators. This mixin could, for example, populate an application-specific tuple between ApplicatoinUser and ApplicationTenancy. You could then use a custom impl of the ApplicationTenancyEvaluator [1] to query this tuple in determining if a user had access.