Hi Timothéé Am 16.01.2013 um 11:48 schrieb Timothée Maret:
> > 2013/1/16 Felix Meschberger <[email protected]> > >> On a related note: Currently it is only possible to manage (create, read, >> update, delete) through the Web Console. Would it make sense to define a >> TenantManager service (which is not the same as the TenantProvider: While >> the TenantProvider can be used by any one, the TenantManageris intended for >> us by administrators). >> >> It makes totally sense to me. You might give it a try ? I created SLING-2710 [1] to track this. Maybe the API should be enhanced by the methods taking a ResourceResolver to access the persistence for write-back ? Regards Felix [1] https://issues.apache.org/jira/browse/SLING-2710 > >> Regards >> Felix >> >> >> >> Am 16.01.2013 um 10:29 schrieb Timothée Maret: >> >>> Hi, >>> >>> I have been using the sling tenant recently and although the tenant path >>> matcher configuration is >>> flexbile, the user to tenant resolution mechanism enforces to organize >> the >>> users following a fixed >>> structure where all the users must be under the tenantId root. >>> >>> As an example: >>> >>> /home/users/<tenantId>/bob >>> /us/alice >>> /fr/charles >>> >>> This is not flexible enough, especially with enabling tenant support on >>> legacy system where users >>> location is already set. >>> >>> I think there two approaches to improve that >>> >>> * Based on group >>> >>> Instead of being applied against the user home path, the regex could be >>> applied against all the >>> groups the user is a member of. Each tenant would be assigned to a >> default >>> group and the first >>> tenant.default-group/user.group match would define the user as being part >>> of the group. >>> >>> This offers the flexibility to store the user anywhere. However, the >>> resolution would be undeterministic >>> in cases where the user has more than one tenant group assigned. >> Moreover, >>> this would interleave >>> group and tenant support which sounds like a limitation in comparison to >>> the path based approach. >>> >>> * Based on property set in user home >>> >>> Each user part of a tenant would have a property "tenantId" set which >> would >>> map it to the tenant. >>> This implies a bit more maintenance but would offer the flexibility to >>> store users anywhere as well >>> as a separation between group and tenants. >>> >>> To me, the property based is clearly the best way to go as it offers most >>> flexibility in therms of >>> group and user organization. Moreover, it could be implemented as an >>> extension of the current design. >>> Basically, instead of only trying to match against the user home path, >> the >>> TenantAdapterFactory could >>> also look for the userHome + "tenantId" property path. If the property is >>> present, then the value >>> could be appended to the user home path and tried to be matched against >> the >>> regex. >>> >>> wdyt ? >>> >>> Regards, >>> >>> Timothee. >> >> Regards, > > Timothee.
