Angular & .net core Version: V9.1.0 .NET core 3.1
So, I hope anyone can provide me with some proper insights on how to tackle this request/addition...
We are developing a large platform for a customer in which we need to create a seperation in user accounts.
Let's say we have 3 layers:
- Customers/tenants (This are the tenant users in the AbpUser table)
- Candidates (We have to do something with this)
- Admin (this is the Host environment)
We either want to use the current AbpUsers table with a custom property of some sort.. but then we need to create filters in the appservices which are specific for the candidate users and the customer users. Is that a possiblity?
Option two is to create a separate user table, but I think we need to copy a lot of boilerplate code to get that to work.
Has anyone ever done this and has some pointers on how to approach this?
Thanks!
4 Answer(s)
-
0
Hi @mk2software
Your use case for Candidates isn't clear to me.
- What is the relationship between a candidates and a customer/tenant?
- Is a candidate for a specific customer/tenant? Or more than one tenant?
- Should all candidates be managed within an instance of a single tenant (i.e. Candidate tenant)?
- Is each candidate effectively its own tenant?
Can you describe your application a bit more to provide some more context.
Thanks Jamie
-
0
Hi @mk2software,
I'm not sure about the use case but option 1 is a better choice in any case because option 2 (creating a new entity and table) will require lots of duplication of existing codes (also from framework).
You can follow documents below to create a custom filter, see;
https://aspnetboilerplate.com/Pages/Documents/Articles\How-To\add-custom-session-field-aspnet-core
https://aspnetboilerplate.com/Pages/Documents/Articles\How-To\add-custom-data-filter-ef-core
-
0
Hello @aldercove,
Thanks for you reply.. There is no clear relationship between the candidates and customer/tenants. It's more of a separate entity. However, we figured it would be nice to use the authentication/authorization implementation of aspnetcore, because it will partly use the same API endpoints as the host and customer enviroment does.
The candidate users will be managed through the admin environment. So I think you can look at the candidate users as tenantless users (or each user is its own tenant).
@ismcagdas, I think we will go with this approach and perhaps split the users in a whole new database in the future. Thanks for the information about the custom filters! We will check them out.
-
0
@mk2software thanks. Let us know if you face any problems.
