- ABP Framework version: v3.0.4
- UI type: Angular
- DB provider: EF Core
- Tiered (MVC) or Identity Server Separated (Angular): no / yes
- Exception message and stack trace: N.A
- Steps to reproduce the issue: N.A
REQUIREMENT
- Under a tenant I have few group of users like Anchor, Supplier, Buyer
- Each of them should have Admin user like AnchorAdmin, SupplierAdmin, BuyerAdmin
- Each of them should be able to create user only for their own group, say SupplierAdmin can create multiple users as Supplier but all the newly created user should not be able to create users, they will not have those rights, same applies for each group
- When an admin of a specific group log's in and go to administrator screen he should be able to see the users only within his group i.e AnchorAdmin should be able to see only AnchorUser not other group's user.
- GroupAdmin should have the controll over all the permission and role management stuff.
- All groups should have complete isolation in terms of not able to see other groups user, permissions , roles etc. etc.
- Hierarchy should be as below :
- Tenant
- Group i.e. (Anchor, Supplier, Buyer)
- Admin i.e. (AnchorAdmin, SupplierAdmin, BuyerAdmin)
- User_1 i.e. Normal user with only specific set of rights
- User_2
- Admin i.e. (AnchorAdmin, SupplierAdmin, BuyerAdmin)
- Group i.e. (Anchor, Supplier, Buyer)
- Tenant
I refered to this link https://docs.abp.io/en/abp/3.1/Modules/Organization-Units But not sure how to use it in this specific requirement. Even if there is any other feature of abp which will help me to achieve this functionality can help. Please provide few detail points or examples or docs where I can get complete understanding related to my requirement.
Thanks!!!
6 Answer(s)
-
0
@lalitChougule sorry for my late response.
This is a complex use case and there's no built-in way to achieve this type of usage. OrganizationUnits doesn't cover all your requirements. With OrganizationUnits you can group users and assign a role to an organization unit. But when you grant user create permission to AnchorAdmin, he'll be creating users for others as well.
Options:
1- You can create a new tenant for Anchors, Suppliers, Buyers. Then all your requirements will be supported. And you'll create the entities you share among them with not multitenant so that you can share the records.
2- You can override existing register user and get user list methods. So that you can implement your own logic.
These methods are
virtual
and open to override.namespace Volo.Abp.Identity { public class IdentityUserAppService : IdentityAppServiceBase, IIdentityUserAppService { public virtual async Task<PagedResultDto<IdentityUserDto>> GetListAsync(GetIdentityUsersInput input) { [Authorize(IdentityPermissions.Users.Create)] public virtual async Task<IdentityUserDto> CreateAsync(IdentityUserCreateDto input) { await IdentityOptions.SetAsync(); var user = new IdentityUser( GuidGenerator.Create(), input.UserName, input.Email, CurrentTenant.Id ); input.MapExtraPropertiesTo(user); (await UserManager.CreateAsync(user, input.Password)).CheckErrors(); await UpdateUserByInput(user, input); (await UserManager.UpdateAsync(user)).CheckErrors(); await CurrentUnitOfWork.SaveChangesAsync(); await DistributedEventBus.PublishAsync(new IdentityUserCreatedEto() { Id = user.Id, Properties = { { "SendConfirmationEmail", input.SendConfirmationEmail.ToString().ToUpper() }, { "AppName", "MVC" } } }); var userDto = ObjectMapper.Map<IdentityUser, IdentityUserDto>(user); return userDto; } } } }
and also
Get user list method:
namespace Volo.Abp.Identity { public class IdentityUserAppService : IdentityAppServiceBase, IIdentityUserAppService { public virtual async Task<PagedResultDto<IdentityUserDto>> GetListAsync(GetIdentityUsersInput input) { var count = await UserRepository.GetCountAsync(input.Filter); //TODO: var users = await UserRepository.GetListAsync(input.Sorting, input.MaxResultCount, input.SkipCount, input.Filter); var userDtos = ObjectMapper.Map<List<IdentityUser>, List<IdentityUserDto>>(users); var twoFactorEnabled = await IdentityProTwoFactorManager.IsOptionalAsync(); for (int i = 0; i < users.Count; i++) { userDtos[i].IsLockedOut = users[i].LockoutEnabled && (users[i].LockoutEnd != null && users[i].LockoutEnd > DateTime.UtcNow); userDtos[i].SupportTwoFactor = twoFactorEnabled; } return new PagedResultDto<IdentityUserDto>( count, userDtos ); } } }
3- Add the Identity module source code to your project and you are free to customize everything.
there maybe other options but these are the first one come to my mind.
-
0
We have same scenario, i was created ticket about that. If system grows you will need like that requirements. I thinked maybe features could be scoped if he want. Like feature admin, just can manage own feature and every feature could be scoped about permissions, roles but is an issue to be considered
-
0
What would you do if you have a plain ASP.NET Core application?
-
0
Hi @alper,
Thanks for the response.
I implemented your second approach, I customized code for the mentioned methods. It was just a POC for now, but in near future I have to develop full functionality. For now it's kinda configured via appsetting.json approach like if RoleA log's in he ill be able to see user's only under RoleA or which ever role the user is associated with. I want to make it more dynamic.
appsetting.json
"UserAccessControl": { "FetchUsersByClaims": [ "SupplierAdmin" ], "UserCreationWithClaims": [ "SupplierAdmin" ], "FetchUsersByRoles": { "admin": "AnchorAdmin", "AnchorAdmin": "SellerAdmin", "SupplierAdmin": "Supplier", "SellerAdmin": "Seller" }, "CannotEditUserWithRoles": { "AnchorAdmin": "AnchorAdmin" }, "CannotDeleteUserWithRoles": { "AnchorAdmin": "AnchorAdmin,SupplierAdmin" } }
Here as u see my config file in UserAccessControl a section called FetchUsersByRoles, here I have mentioned which If my logged in use if of role
admin
he can only get users of roleAnchorAdmin
.Likewise other sections.This is where my config file have control, I want to give this control to my Admin user. I want to generate a screen and allow Admin himself to have a control over this.And in future we add new roles to our system, we can have control over them as well.
If you can simply proved any better approach to manage this requirement will be very helpfull.
-
0
This question has been automatically marked as stale because it has not had recent activity.