Activities of "jackmcelhinney"

I understand the reasoning for switching to Authorization Code Flow, and our team switched to it with the 3.1 release. What I don't understand is how the profile page is relevant to the new auth mechanism, especially given how the new flow worked great with the profile page still in Angular. The examples of Google and Microsoft are different because a user's account spans multiple products, like Gmail, Drive, Photos, etc, so it makes sense that there would be a single profile/settings page for simplicity and consistency between products. But for at-least our team's use of ABP as a single product, this advantage isn't relevant, and switching the profile page from Angular to MVC does not seem necessary from a security perspective either since the user is authorized after logging in, and all the profile actions are just standard HTTPS requests like in the rest of the app.

I can understand moving to this design if a team has several separate projects that share the same users and hitting the same profile page could be useful. But in our, fairly standard project, it causes several issues that I mentioned earlier and is inconsistent for the user, all for no real benefit. It would be nice if we had the option of choosing whether to use the 3.1 profile page in Angular or move it to the MVC by overriding where the "Manage Your Profile" button links to. I've spent some time trying to do this, but since the profile page components and services are no longer included in the @volo/abp.ng.account package, it is very difficult to restore the old functionality.

In its current state, the behavior of the profile page in this context is unexpected and confusing for users. Since it is not directly necessary for authorization, why not allow the 3.1 Angular profile page as well?

Sorry to jump on this thread with a long comment, but just wanted to give some feedback as well.

I'm curious to know why the profile page specifically needs to be on the MVC side for Authorization Code Flow since the user is already authenticated. While I understand this redirect may be necessary, it seems to be causing several problems that I have described below:

1. Logging out from the profile page seems to behave differently. If you log-out from the profile page, then log back in, it will redirect you to the swagger page. Additionally, if you log-out from the profile page then return to the Angular UI (localhost:4200), you will still be logged in, and will only be prompted for credentials if you go back to the profile page.
2. Clicking on the logo in the sidebar on the profile page redirects to the swagger page.
3. There seems to be no way to easily change the ViewBag.Title (text that appears in the browser tab) on these MVC pages. I encountered this with the MVC login page as well, but in order to override the default "MyApplication" text, I need to copy the source code for the page and edit the ViewBag.Title. I then get concerned with keeping this code up to date just to change this text. Solution based on this thread, please let me know if there's an easier way to change these titles.
4. In my Angular code, I have a lot of style overrides in styles.scss that override some of the theme elements, like the sidebar. For example, we use Lepton Style1, but have overriden it so the sidebar is white with black text. To keep theming consistent in the profile page, I have to convert the scss to be css-friendly and maintain these styles in the Host project as well.
5. We have plans in the future for allowing tenants to upload their logo and replace them in the UI. This seems to complicate this quite a bit, since the logo is drawn from two different locations for the MVC (login/profile) and Angular sides.

If this switch to the MVC side is necessary for the profile page, I think it may be helpful and more elegant to have an easier way to override Lepton styles so that overrides and logo replacements made on the MVC side propagate to the Angular side if possible. I also wonder if there are other solutions like serving the profile page content from an iframe in the Angular app instead so that sidebar navigation and styles are still available.

Anyway, just wanted to give my thoughts on this. Keep up the great work, our team is making great progress with ABP!

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