Nested Tenant?

[TalMcMahon]

I have a use case in which a Company has subsidiaries they want to manage the content for, but each of those subsidiaries need to be segregated from each other. The easiest model to explain would be like Yum! Brands needs to have a place for someone to add Content for their restaurants like KFC, Pizza Hut, and Taco bell. These restaurants also need to be segregated from each other because of the nature of the content.

I am hoping there is a built in module that handles this and I have just missed it in the documentation.

If there isn't an easy way existing, could I get the same result by somehow making a Parent tenant and having the admin of that tenant as an admin on all of the other tenants somehow listing the child tenants in the parents view so they could just click into the child tenant without logout and login type thing.

Thanks in advanced

Tal McMahon

[hishamco]

Orchard Core already has a Default tenant which allows you to add or remove tenants

so they could just click into the child tenant without logout and login type thing.

For this in particular I did an impersonation feature that you can look in Orchard Core Contrib Users Module, also Lombiq already extend that to provide extra features, probably @Piedone might give you some details about their module which you can find in their account

[Piedone]

Thanks for the shoutout, Hisham! Yes, we added an impersonation feature and lot more in this project of ours: https://github.com/Lombiq/Hosting-Tenants

[Piedone]

Aren't you looking for the built-in multi-tenancy feature of Orchard? You can create individual sub-sites in the same Orchard app, that have completely independent content and configuration. See the docs and this tutorial video.

[Piedone]

I see, so you want more than one layer (Orchard offers only one: parent site - what we call Default tenant - and sub-sites, i.e. other tenants). In this case, what's in Orchard by default won't cut it.

However, you can have multiple applications, for each brand under a company (i.e. "Taco Bell" would be its own app, with restaurants as tenants under it). This is probably better anyway since Orchard's multi-tenancy is about hosting a lot of sites together that need a similar feature set; if the sites are wildly different, especially if they require custom modules, then you're better off with separate apps.

If you can explain what are you looking for with using multi-tenancy, then we'll be able to better advise.

[TalMcMahon]

The use case is pretty much as I described it. I am building an App for training in restaurants. Many restaurant chains are owned by a parent company that does all of the cross cutting concerns like making training packages. That means however, there is a training content person that works for the parent company, making training for the specific Brand AND for a specific Site/restaurant (a restaurant inside of a stadium has different training than a restaurant in strip mall). So I need a Shell for store, a shell for brand, and a shell for Company. I feel like I could build something to slot users across shells, or some sort of impersonation for reaching down a layer. but that was why I was asking!

Thanks again

[Piedone]

Your concern with having this hierarchy is solely cross-tenant authentication and content management? As I see, you have the following options:

1. Create user accounts for your admins on each tenant, then let them log in with an SSO option. This makes managing the user accounts less of an issue, but you still need to create them. All sites can be tenants in the same app, you don't need a tenant hierarchy.
2. Use our above-mentioned Admin Login module to log in as a tenant's admin from the Default tenant. On the Default tenant you'll need the necessary user accounts to be admin too. In this case, you'll need separate apps, with their own Default tenants, for all brands.

Number 1 seems like the good option.

[TalMcMahon]

I think I understand. (as this is literally an app for food recipes, to avoid confusion, I am just going to say training content.)

I believe you are saying, I need to have a way to make content and attach it to the correct shell. It would seem I can:

1. Figure out hw to get the user "into" each shell as an admin and then let them create there as normal.
   OR
2. Figure out how to Create the content in the Highest level shell (Company) and then figure out which shells this company "owns" so that the admin can attach it to the shell (thinking just a drop down) and then we save it to the selected shell.

It seems like I can essentially build a Correlation table between Company and Brand stored in Company and another between Brand and Sites... I do not like the implications of essentially a by-hand and in memory join of that data. Would I be better off building a proper external Company->brand->site microservice and just do the lookups there?

[Piedone]

Your understanding is correct, yes. To clarify on the terminology: You're adding users to, and managing content for a "tenant". A "shell" is an object that's built when a tenant starts (as well as in some other cases, so there can be multiple shells for a tenant at a given time, but you needn't worry about this) and contains e.g. some important service objects.

While you can implement a custom external content store (or even one on the Default tenant), with a completely custom way of managing it and consuming it from the end sites, I don't recommend that. If you want to build a custom UX then it's more straightforward to let users manage content on other tenants from the Default one, what you can do like this. However, I still think my nr. 1 suggestion above is better.

[ns8482e]

@TalMcMahon In orchard core, the tenant is an isolated websites - where each website could have their own set of users, features, content and services. When you setup first website, it's called 'Default' tenant. Default tenant is no different than any other tenants you create. Also IT is NOT a parent of any other tenant. All are siblings.

If you are hosting all tenants under same domain then they are isolated by RequestPrefixUrl. You can have non-empty RequestPrefixUrl for Default or can have empty RequestPrefixUrl for non-default tenant. The only requirement is RequestPrefixUrl should be unique.

e.g.
mydomain.com/default/ <--Default
mydomain.com/tenant1/
mydomain.com/tenant2/
mydomain.com <--- tenant3

The only difference between non-default and default tenant is that there are some modules that are marked with "DefaultTenantOnly" are the modules allowed to run on Default tenant. like Tenant management feature that allows you to create tenants from admin UI.

For Authentication/Authorization, you may set one of your tenant as Open ID Server, where you manage users and applications, for all other tenants you set it as Open ID client.

For content publishing you may use Remote deployment to copy content from one tenant to another -
OR you can use graphql/api to read content from one tenant to another in real-time without copying.