Thanks @alper.
Also having an issue with the abp suite today. Going to the modules page is throwing a 500/403 error. This is happening in 3.0.3
and 3.0.4
. I have tried removing and adding the suite, and have made sure I am logged into the CLI. The page was working yesterday. Any suggestions?
[16:50:05 ERR] Error occured while retrieving the module list. System.Exception: Remote server returns '500-Internal Server Error'. Message: An internal error occurred during your request!
at Volo.Abp.Cli.ProjectBuilding.RemoteServiceExceptionHandler.EnsureSuccessfulHttpResponseAsync(HttpResponseMessage responseMessage) in D:\github\abp\framework\src\Volo.Abp.Cli.Core\Volo\Abp\Cli\ProjectBuilding\RemoteServiceExceptionHandler.cs:line 44
at Volo.Abp.Cli.ProjectBuilding.ModuleInfoProvider.GetModuleListInternalAsync() in D:\github\abp\framework\src\Volo.Abp.Cli.Core\Volo\Abp\Cli\ProjectBuilding\ModuleInfoProvider.cs:line 58
at Volo.Abp.Cli.ProjectBuilding.ModuleInfoProvider.GetModuleListAsync() in D:\github\abp\framework\src\Volo.Abp.Cli.Core\Volo\Abp\Cli\ProjectBuilding\ModuleInfoProvider.cs:line 45
at Volo.Abp.Suite.Controllers.AbpSuiteController.GetModuleListAsync()
I am trying to override AccountEmailer
but the SendEmailConfirmationLinkAsync
method is not marked as virtual
in the Account Module like the SendPasswordResetLinkAsync
is, so it can't be overriden. Is this intentional or a bug?
Hello. This is a follow-up from a question a while back about removing functionality from the UI and API: https://support.abp.io/QA/Questions/255
By disabling the permissions to Organization Units and Claim Types we were able to remove these elements from the navigation:
//Remove the Organization Unit functionality by overriding permissions and setting it to not enabled/granted
context.GetPermissionOrNull(IdentityPermissions.OrganizationUnits.Default).IsEnabled = false;
context.GetPermissionOrNull(IdentityPermissions.OrganizationUnits.ManageOU).IsEnabled = false;
context.GetPermissionOrNull(IdentityPermissions.OrganizationUnits.ManageRoles).IsEnabled = false;
context.GetPermissionOrNull(IdentityPermissions.OrganizationUnits.ManageUsers).IsEnabled = false;
//Remove the Claim Types functionality by overriding permissions and setting it to not enabled/granted
context.GetPermissionOrNull(IdentityPermissions.ClaimTypes.Default).IsEnabled = false;
context.GetPermissionOrNull(IdentityPermissions.ClaimTypes.Create).IsEnabled = false;
context.GetPermissionOrNull(IdentityPermissions.ClaimTypes.Delete).IsEnabled = false;
context.GetPermissionOrNull(IdentityPermissions.ClaimTypes.Update).IsEnabled = false;
However, this did not stop these elements from appearing in other areas in the app:
Organization Units tab still appears on Create/Edit User: When the modal opens to create or edit a user, the organization units tab is still present, but because the permission is disabled, it throws an error.
Claims still appears in User and Role action dropdown: On the user and role tables, a Claims
option is still present, and clicking will still get claim-types
and claims
for that user or role successfully and allows adding or updating claims with no errors. It seems that is because these endpoints check the IdentityPermissions.Roles/Users.Default/Update
permissions and not any related to IdentityPermissions.ClaimTypes
.
Am I correct in assuming that these elements should be hidden if these permissions are disabled? If so, could these extra permission checks be added to the Identity Module to prevent this unexpected behavior? If not, what would be the best way for me to manually hide these elements?
Thanks for the help, Jack