Join tenant list with additional tenant-related data (e.g. CompanyTenant table)

[tsygankov]

Hi,

Many thanks for creating this great library!

I'm working on a hierarchical multitenant application and now trying to add this library to an existing application. In my case, I have 'Dealer | Organization | Site' hierarchy,. We reused the existing Dealers and Organizations tables to store additional information about tenants (following the CompanyTenant example).

In my case, for super admin users I have to output full list of tenants with additional data joined\aggregated from Dealers (e.g. DealerTenant) and Organizations (e.g. OrganizationTenant) tables. The problem is that my queries to Dealers and Organizations tables do not return any data due to the DataKey filter.

So, what's the best way to access additional tenant-related data in non-authp schema?

Some ideas that came to my mind:

1. create one more hierarchy level for super admin users;
2. use a separate AdminDbContext without DataKey filter;
3. use IQueriable and IgnoreQueryFilters method (not an option in my case due to additional query filters).

I checked the Example4 demo and it looks that there the super admin user (Super@g1.com) also can't access Stocks and Sales.

Thanks!

[JonPSmith]

Hi @tsygankov,

I am glad to say I have a feature that an admin user can request access to a tenant / hierarchy. You can find information on this in:

• This section of the Part2, administration shows how an admin user (i.e. a user that isn't linked to a tenant) can access a tenant data.
• The documentation of this feature gives you the information to set this up in your application.
• The Example3 application has this feature set up if you want to try it. Example is a single-level multi-tenant app but it does work with a hierarchical multi-tenant app.

[tsygankov]

Hi @JonPSmith,

Thanks so much for your quick response.

I explored the documentation before asking this question, but I was not sure if it's correct to use the mentioned feature for my specific use-case. I assume that this feature is mostly used to temporary access data of specific tenant, but in my case I have to access data of multiple (all) tenants simultaneously. For example, I have to implement search through all tenant data stored in Dealers (e.g. CompanyTenant) table, so that I could find the tenant that match my search criteria (and use LinkToTenant afterwards). Another example would be to get aggregated data per tenant, e.g. number of Invoices per tenant in Example3, or number of ShopSock items or monthly sales amount per tenant in Example4.

As I understood, using the 'Link to tenant data' feature I can't get access to multiple tenant data simultaneously.

Probably my question is quite similar to #61 , but the difference is that I have a valid user (and actually there is no background process), so I was hoping that there is a better way to solve this problem.

Thanks again!

[JonPSmith]

HI @tsygankov,

I'm sorry I didn't fully understand what you needed the first time, but your extra comment helps. I think you have two main ways, (which you have already detail) that would would:

Use IgnoreQueryFilters in your query

I know you ruled this out due to "additional query filters" (I assume something like a Query Filter for soft delete), but that can be rectify this by manually adding the "additional query filters" to your query. I have done this in client application.

Create one more hierarchy level for super admin users

Because you are using hierarchical multi-tenant you can add a top level which could see everything, and your "additional query filters" would still be in place. You can then write standard queries to get what you want.

This approach is simpler to use, but the IgnoreQueryFilters approach is a bit quicker because it removes the DataKey filter.

[tsygankov]

Thanks a lot!

We added one more hierarchy level and now it works exactly as we need.

I'm excited for this library, It's so easy to write business logic on top of it! As I mentioned, we are migrating an existing application to your library, so I immediately see the difference. I'm sure that after the migration our codebase size will will significantly reduce as we don't need those complex if-else-based permission checks any more. And the main benefit is that the risk of sensitive data exposure is now reduced to minimum, this library has built-in poka-yoke and developers don't have to care about tenant data filters any more.

I have no doubt that this project has a bright future ahead!