Oh, was a bit unexpected, but now I understand. I need a "root" permission definition - I cannot assign my permissions straight to the group:
{
...
var rolesPermission = moduleRoleGroup.AddPermission(ModuleRolePermissions.SubGroupName, L("Permission:ModuleRoles")).WithProviders("MR");
...
}
{
...
options.ProviderPolicies[AbxModuleRolePermissionValueProvider.ProviderName] = "ModuleRoles"; //TODO: Replace with constant ModuleRolePermissions.SubGroupName
...
}
Regarding what you have said in the very beginning:
You need to cover the role permission provider to load the permissions of the custom role under the role
do I need to REPLACE some ABP providers (instead of adding my own ones)? What I'm going to do eventually is to replace ABP "Permissions" dialog completely. At the same time, I want to retain as much existing code as possible. I.e. I'm extending Role Management with my two-level role system, but I don't want to break anything which already is functioning at ABP side (if ABP needs traditional approach at some page, it needs to keep functioning).
Thank you. OK - on Application.Contracts
layer i've created AbxModuleRolePermissionDefinitionProvider
where I defined all "so-called" permissions (according to our requirements - second-level roles):
public class AbxModuleRolePermissionDefinitionProvider : PermissionDefinitionProvider
{
public override void Define(IPermissionDefinitionContext context)
{
var currentUser = context.ServiceProvider.GetService<ICurrentUser>();
if (currentUser.IsAuthenticated)
{
var moduleRoleGroup = context.AddGroup(ModuleRolePermissions.GroupName, L("Permission:ModuleRoleManagement"));
var moduleRoleAppService = context.ServiceProvider.GetService<IModuleRoleAppService>();
var moduleRoles = moduleRoleAppService.GetModuleRolesAsync(new GetModuleRolesInput()).Result;
for (var i = 0; i < moduleRoles.Items.Count; i++)
{
moduleRoleGroup.AddPermission(moduleRoles.Items[i].Name).WithProviders("MR");
}
}
}
private static LocalizableString L(string name)
{
return LocalizableString.Create<CoreResource>(name);
}
I also put the line related to policies into Module:
Configure<AbpPermissionOptions>(options =>
{
options.ValueProviders.Add<AbxModuleRolePermissionValueProvider>();
});
Configure<PermissionManagementOptions>(options =>
{
options.ProviderPolicies[AbxModuleRolePermissionValueProvider.ProviderName] = "WHAT_IS_IT";
options.ManagementProviders.Add<AbxModuleRolePermissionManagementProvider>();
});
And this list is successfully loaded on my page (see the grid below). But nevertheless, when I try to update the permissions with the code in the first post, I'm getting the same error.
I can see there are PermissionValueProvider
and PermissionManagementProvider
ABP providers. Do I need to create both? I did it and added them to my domain module like so:
public override void ConfigureServices(ServiceConfigurationContext context)
{
Configure<AbpPermissionOptions>(options =>
{
options.ValueProviders.Add<AbxModuleRolePermissionValueProvider>();
});
Configure<PermissionManagementOptions>(options =>
{
options.ProviderPolicies.Add(AbxModuleRolePermissionValueProvider.ProviderName, AbxModuleRolePermissionValueProvider.ProviderName); // "MR"
options.ManagementProviders.Add<AbxModuleRolePermissionManagementProvider>();
});
...
}
However, when I reference provider name (AbxModuleRolePermissionValueProvider.ProviderName) via DI-ed ABP IPermissionAppService
in my configuring page of the project
I am getting the following error:
No policy found: 'MR'
BTW, what the ABP tables with "_SAVE" suffix are for? E.g., I can see ABPUSERROLES and ABPUSERROLES_SAVE... the structure is the same...
ABPROLES does not have some suitable fields for this purpose
No such fields, you can consider to extending entities: https://docs.abp.io/en/abp/latest/Customizing-Application-Modules-Extending-Entities
Ok, thanks. We will consider it. Please, do not close the ticket though, we might come up with other questions - the implementation is in progress...
Looks like I will need to create another table, similar to ABPUSERROLES - to bind bottom-level roles to a top-level role. What I don't like in this approach - there will be no difference between both types of roles (just role name encoded in a special way) - ABPROLES does not have some suitable fields for this purpose: it needs to be allowed to assign a bottom-level role to a top-level role, but not vice-versa.
I've noticed I have not indicated used UI type. We are using Angular, not Blazor. Could you please try that one?
Hi Alexandre,
It looks like there is a problem 5.3 version and later, I created an issue for this I'll fix it
Hi. Ok. Please let me know if I will need to make a local fix or there will be some patch from your side. As I meant, we're not planning to upgrade the nearest time.
I've noticed I have not indicated used UI type. We are using Angular, not Blazor. Could you please try that one?
Hi,
You can try to update to 7.0.3, maybe it has been fixed.
Sorry. We are not ready to invest time into another update. Do you have other suggestions? Can you confirm this issue or suggest the way to resolve this issue in the existing solution 7.0.1?