Page template site menu in multi-tenant site

[CrispinF]

When watching a demo of an application that uses cloudscribe folder-name multi-tenancy, I got to thinking again about how a user finds their way into their own ‘tenant’.

Note that many users will not actually bookmark their tenant address, but they will know they are using “Insights” or “FlyMapper” (or whatever) which they will be able to google.

So the root landing page of the site really has to make it easy for a user to get to their area.

In one such site we made the root site landing page a kind of ‘menu’ with a tile for each customer, for a user to click on to get to their tenant. See https://local-heritage-list.org.uk/
This is completely hand-carved 'content' – which is fine for smallish numbers and low rate of change.

This could be made much easier. with a simple page template component for this: a ‘Tenant site menu page template’.

This could have top content, bottom content, and in the middle it would render the ‘list’ of tenants, making use of the tenant site settings to provide: name, URL, logo image, and potentially other properties such as 'Header Content'.

The actual rendering could then be tiles, like on LHLP, or a simple list, or whatever. There could be some choices in the template.

[JimKerslake]

Considerations (from a quick chat)

1- should this be a dynamic template that populates the menu list from a query of all other non-root tenants?
If so might need some logic to decide which tenants might need to be excluded from the list (e.g. we could exclude ones which are flagged as 'site closed')... and presumably list them in alphabet-order of some property (site name?)

I could possibly see a role also for a non-dynamic one that is more hand-curated like the LHLP one...
Kind of depends if you want a pretty set of card images for each that are all the same size etc.?

2 - should the use of this template be restricted to root site page editors only? (do we actually have a mechanism for limiting access to page templates by tenant, when the 'root' tenant we want to limit it to could either be dynamically inferred or else taken from the MultiTenantOptions RootSiteId Guid in the Json? )
We can limit content templates to specific tenants (ContentTemplateConfig >> ProjectId in the appsettings json) but that assumes we know the Guid of the root site, which assumes that a cs site developer is going to make manual config intervention to achieve that. Perhaps in practice we deploy the page template from a VSIX CS template with that particular template declared in appsettings.json with its ProjectId set to either * or to a zero guid, so we do have to rely on the cs template developer to put the Guid of the root site in there manually, if that's what they want.

[JimKerslake]

As Mark correctly pointed out, cs.SimpleContent is not 'allowed' to have any knowledge of the cs core data architecture and multitenancy models - there is no dependency chain there.

(in theory simplecontent could be used over the top of a different website back-end - though it does depend on cloudscribe.Web.Common)

It's therefore not possible to build the 'dynamic' version of the above in a straightforward way, directly talking to the cs core architecture, without breaking the much-prized independence between different CS modules.

Would need some architectural thought about how to build this dynamically so that the simplecontent template could consume a generic DI pipeline service that would deliver a List of tenant site settings potentially from any back-end, and then implement that service specifically from cs core.