"roberto.fiocchi@mcsi.it" की गतिविधियाँ

https://support.abp.io/QA/Questions/3052/Your-feature-request#answer-3a0d62be-d186-9460-0995-e613ddc33fbf

I would like the advanced filter to be generated optionally (for all UI types)

Thank you

This works:

protected List<PermissionGrantInfoDto> GetChildPermissions(PermissionGroupDto permissionGroup, PermissionGrantInfoDto permission)
{
    var childPermissions = new List<PermissionGrantInfoDto>();
    GetChildPermissions(childPermissions, permissionGroup.Permissions, permission);
    return childPermissions;
}

protected void GetChildPermissions(List<PermissionGrantInfoDto> allChildPermissions, List<PermissionGrantInfoDto> permissions, PermissionGrantInfoDto permission)
{
    var childPermissions = permissions.Where(x => x.ParentName == permission.Name).ToList();
    if (childPermissions.Count == 0)
    {
        return;
    }

    allChildPermissions.AddRange(childPermissions);

    foreach (var childPermission in childPermissions)
    {
        GetChildPermissions(allChildPermissions, permissions, childPermission);
    }
}

hi,

It seems to me that as of today this is a requirment since the permission modal wont work properly if it isn't respected, What is the point of having the PermissionDefinition.AddChild() function and nesting them if the rest of the implementation doesn't use this structure?

hi,

Thanks for the link, but this didn't answer my questions:

Is this a naming convention for the permissions that Abp enforces? If so, could you link us the documentation that defines this naming convention?

Hi,

I have overriden the PermissionManagmentModal and now im able to see the sublevels, but i have noticed that when i uncheck a parent permission the child permissions dont get unchecked. After further investigation i have found this piece of code in the PermissionManagmentModal:

protected List<PermissionGrantInfoDto> GetChildPermissions(PermissionGroupDto permissionGroup, PermissionGrantInfoDto permission)
{
    return permissionGroup.Permissions.Where(x => x.Name.StartsWith(permission.Name)).ToList();
}

This assumes that the child (and child's child and so on) permissions all start with parent permission Name. Our permission naming follows a different logic, Is this a naming convention for the permissions that Abp enforces? If so, could you link us the documentation that defines this naming convention?

Hi,

Thanks for the reply! Is there any possibility to have that feature in version 7.4.5? We would rather not migrate to .Net 8 yet.

• ABP Framework version: v7.4.5
• UI Type: Blazor WASM
• Database System: EF Core (SQL Server)
• Tiered (for MVC) or Auth Server Separated (for Angular): no
• Exception message and full stack trace: none

Steps to reproduce the issue:

• Create a new Blazor Wasm solution using abp suite
• Define the three levels of permission in the Permissions.cs:

public static class Level
{
    public const string FirstLevel = GroupName + ".FirstLevel";
    public const string SecondLevel = FirstLevel + ".SecondLevel";
    public const string ThirdLevel = SecondLevel + ".ThirdLevel";
}

• Add the permissions to the PermissionDefinitionProvider.cs:

var firstLevelPermission = myGroup.AddPermission(PermissionsIssuePermissions.Level.FirstLevel, L("Permission:FirstLevel"));
var secondLevelPermission = firstLevelPermission.AddChild(PermissionsIssuePermissions.Level.SecondLevel, L("Permission:SecondLevel"));
var thirdLevelPermission = secondLevelPermission.AddChild(PermissionsIssuePermissions.Level.ThirdLevel, L("Permission:ThirdLevel"));

• Run the application and open the Permissions modal on the "admin" role:
• Notice how the "SecondLevel" and "ThirdLevel" permissions look to be on the same permission level even tho the "ThirdLevel" permission is a child of "SecondLevel" permission

In the 8.0.0 version of Abp Suite with the new version of EntityFramework that supports the DateOnly and TimeOnly types, it would be useful to add them to the list of types that can be used to create a property in an entity.

Hi, yes you are right the other filters should also be passed to the parameter and the filtering should work for them as well. I have created an internal issue (#15729) for this and will fix it asap.

Also, is it not wiser to use a POST request rather then a GET because the query parameters in a GET requests has a 2048 character limit and could possibly go over if i have enough filters?

I understand your intent but since we are getting a result back and not adding or updating any record to a datastore, and instead just collecting the result and returning it GET request seems more proper, according to REST API guides.

Hi, Thanks so much for the help and understanding! We'll wait for the fix.

P.S: We don't know if its intended but we also noticed that with ABP 7.4.2 under HttpApi project a "TestModel.cs" is created when initializing the project with Abp Suite

Hello roberto.fiocchi@mcsi.it ,

The issue you're encountering is that the FilterText property is the only one being passed to the URL when generating the Excel download link. This is because the DownloadAsExcelAsync method only explicitly passes the FilterText property. To include the other filter properties, you'll need to modify the method to explicitly pass them as well.

Thanks,

Hi, I think there might have been a misunderstanding, i was reporting a bug since it should be Abp Suite's job to add those filters when the code is generated like it does with the Page Filters. If i have an entity that has a lot of filters it would take me a while to add all of them manually, time that can be saved if automated with Abp Suite.

Also, is it not wiser to use a POST request rather then a GET because the query parameters in a GET requests has a 2048 character limit and could possibly go over if i have enough filters?