Using Tenant ID instead of Tenant Name in AddNewUserAsync\UpdateUserAsync methods

[tsygankov]

Hi @JonPSmith

I noticed that methods AddNewUserAsync and UpdateUserAsync have 'string tenantName' parameter (well described here). Is there any specific reason for using tenant name instead of tenant ID (can be nullable)?

For example, in my case I'm trying to create users directly\immediately (without sending an invitation or running synchronization), so my plan is to call AddNewUserAsync after creating a user in ASP Net Identity. I have an abstraction layer for both, ASP Net Identity and AuthPermissions (partially), so Tenant class (and Tenant Name) is not available in my application layer (and I hope that I won't have to expose it), however Tenant ID is available, as it's stored in Organizations table that belongs to my domain entities (same as [invoice].[Companies] table in Example 3).

Unfortunately, even if I expose the Tenant entity, I have to run an additional query to get the corresponding Tenant entity and use (string) Tenant Name to call the AddNewUserAsync method. I see that AddNewUserAsync will anyway later convert (string) TenantName to Tenant entity.

In your opinion, should I try to create an overloaded method versions for AddNewUserAsync and UpdateUserAsync with Tenant ID parameter? Or something like TenantChangeService, but for users? Any other suggestions?

Thanks a lot!

[JonPSmith]

Hi @tsygankov,

I used the tenant name in the AddNewUserAsync or UpdateUserAsync because it gave better error messages if the tenant isn't found, e.g $"A tenant with the name '{tenantName}' wasn't found.".

You have many ways to get around this, but I think the best approach is storing the tenant name in your Organizations table in your domain entities. If the tenant name changes, then you can use the ITenantChangeService.SingleTenantUpdateNameAsync to update your Organizations table.

This approach means you don't have to create your own AddNewUserAsync and UpdateUserAsync with Tenant ID parameter, which will be outdated when the next release comes out which adds multilanguage handling of all the errors / messages within the AuthP library.

[tsygankov]

Thank you for responding so quickly!

I implemented it as you suggested above and it works great! It turned out it wasn't as complex as I originally thought.

Looking forward to the next release of your amazing library!

Many thanks!

/Stan