Activities of "alexander.nikonov"

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'

We have several ABP tables with "_SAVE" suffix. I thought it was created on purpose by ABP. But if it is not - I suppose it is some backup (or default value storage) done manually by someone in the team. Please confirm you have no any such, so I will ask the team about them:

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?

I was unable to find "Bugs & Issues v7.0.1" (this is the version the bug below is reproduced), we are not planning to update to 7.2.x for the moment, but we need "Identity Server" section working ASAP.

SO...

After upgrading from ABP 5.1.2 to 7.0.1 I cannot add a claim to "Owned" When I'm trying to move any claim from right to left:

I am getting JS exception (because the given property is "undefined"):

The same goes for Identity Resources (and maybe other sections like this).

FYI: we keep using Identity Server, not Open ID Dict - probably it has something to do with this.

Version

7.0.1

User Interface

Angular

Database Provider

EF Core (Default)

Tiered or separate authentication server

Separate Auth Server

Operation System

Windows (Default)

We love the framework but support and bug reporting is not handled well. My developer has mostly given up reporting issues as he says it's not worth it as responses tend to be one line, minimum effort answers. Complex issues often just get auto-closed without resolution.

I don't mind the one line answers but they should not be considered a paid response to an issue when we only get to report 15 a year. Basic forum responses should not be included in any limit.

Fully agree. I also noticed that the quality of the support has deteriorated: 2-3 year ago the replies (from the same support team members, BTW) were more meaningful, detailed and looked like a "ready-to-help" dialog. Now it looks like the total amount of work on the growing framework has noticeably increased since then and the support team simply does not manage to handle the support tickets. Well - it's the most careful explanation I have.