Activities of "michael.sudnik"

I probably wont be able to investigate until after Christmas now.

What did you try?

It might be the fact that I am using mongodb? I also have created a single module exposing 75 permissions.

When editing a users permissions, there is still a big performance issue (no longer associated with the UI - thanks for that fix), but appears to be with the application services (PermissionAppService,PermissionManager and Permission Providers ).

For a brand new user (with no roles or OUs) it takes 15 seconds to load the Permissions dialog.

I have approximately 10 roles configured and approximately 30 OUs configured. Some of the OUs have roles associated with them, but as I said, none of these are associated with the newly created user.

Interestingly, overriding the PermissionManagementModal.cshtml with your changes seems to improved the Edit Permissions dialog when editing permissions for a Role. But, when I edit the permissions of a User it still has the performance problem. I have confiirmed that it is using the overriden view, so not sure why it is different.

Yep - that gives the same performance boost. Of course, it is much better to be able to use the asp-for tag helpers, so this is great. Thanks for the workaround.

I have also seen this performance hit when editing user or role permissions. It can take 15 seconds to load. I have also made the equivalent change to the PermissionManagementModal view and it took it down to 3 seconds.

• ABP Framework version: v4.0.1
• UI type: MVC
• DB provider: MongoDB
• Tiered (MVC) or Identity Server Seperated (Angular): yes
• Exception message and stack trace:
• Steps to reproduce the issue:

I have found that after creating around 20 organization units, it now takes a while (5 seconds) to open the create / edit user modal dialog. After some investigation, it seems to be the following lines

                        @for (var i = 0; i < Model.OrganizationUnits.Length; i++)
                        {
                            <input asp-for="@Model.OrganizationUnits[i].IsAssigned">
                            <input asp-for="@Model.OrganizationUnits[i].DisplayName" />
                            <input asp-for="@Model.OrganizationUnits[i].Id" />
                        }

I replaced this with the following and it is now is back down to less than a second to open the dialogs.

                        @for (var i = 0; i < Model.OrganizationUnits.Length; i++)
                        {
                            <input type="hidden" id="OrganizationUnits_@(i)__Id" name="OrganizationUnits[@(i)].Id" value="@Model.OrganizationUnits[i].Id">
                            <input type="hidden" id="OrganizationUnits_@(i)__IsAssigned" name="OrganizationUnits[@(i)].IsAssigned" value="@Model.OrganizationUnits[i].IsAssigned.ToString()">
                        }

I have excluded the DisplayName input as we did not need that.

Is it something to do with dialogs? Or the asp-for tag helper and the associated extra generated validation properties? I am not able to delve into the cause of the performance difference, but maybe you could investigate it?

Best regards,

Mike

• ABP Framework version: v4.0.1
• UI type: MVC
• DB provider: MongoDB
• Tiered (MVC) or Identity Server Seperated (Angular): yes
• Exception message and stack trace:
• Steps to reproduce the issue:

Can you let me know the status of the CMS kit? Has it been released and is it stable? Is it your intention to release it and document it? There is nothing in the documentation yet.

We are looking at creating a simple internal user voice type system to track feedback and ideas.

Many thanks, Mike

Thanks for that. We actually purchased the upgrade to the business license recently, but the question credits did not increase with the upgrade. Maybe you could bump it up a bit more? Hopefully, I won't need them, but you never know.

• ABP Framework version: v4.0.1
• UI type: MVC
• DB provider: MongoDB
• Tiered (MVC) or Identity Server Seperated (Angular): yes
• Exception message and stack trace:
• Steps to reproduce the issue:

There is no authorize attribute on the IdentityUserAppService.GetAvailableOrganizationUnitsAsync() method, which would allow any unauthenticated user to discover the OU structure!

Maybe there are also other cases where this has been missed?

(p.s. Great to see the DB provider field in the new question template!)

Many thanks for your feedback.

I ended up extending my relevant entities to include a collection of OU ids and duplicated the same UI in the entity create / edit modal views (e.g. JTree), which exists for assigning a user to one or more OUs.

I then did what you suggested and created a custom claim type (added to user or role claims), which needed to be set to the id of the relevant OU that a user would have access to.

I then updated my repository to filter based on the relevant OU ids (discovered by checking the user claims and getting all child OUs using the OrganizationUnitManager.

I had to fix a bug which was preventing me from saving claims against individual roles.

Thanks again.