Activities of "jackmcelhinney"

Hey @Mehmet,

Seems like it was just a package issue. Running yarn upgrade fixed the problem.

Having some issues with the ngx-datatable in the Angular UI after migrating to 3.1.0. I'm getting the following error when on a page with a datatable after upgrading with no other changes:

I tried providing ScrollbarHelper from @swimlane/ngx-datatable in the module, then it throws the same error for DimensionsHelper, ColumnChangesService, and DatatableComponent, the latter of which providing does not change the error.

Are there any changes I need to make to keep the datatables working in 3.1.0? Any ideas? Thanks in advance.

Excellent. Thanks for the help!

Is there somewhere I can download the default html and ts source code for these components? Downloading the source code of the modules from the suite seems to only have cshtml files. Would I need to manually convert everything but the part I need to change to override in Angular?

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?

• ABP Framework version: v3.0.3
• UI type: Angular
• Identity Server Seperated: no

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:

1. 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.

2. 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