Ends in:
7 DAYS
20 HRS
1 MIN
18 SEC
Ends in:
7 D
20 H
1 M
18 S

Activities of "jackmcelhinney"

Answer

@alper I should have clarifed. I made both of these changes based on the code you suggested. It produces the same error.

Answer

Thanks @alper. Unfortunately, the same error is still thrown after using FirstOrDefaultAsync(). Let me know if you have any other ideas I could try.

Answer

Having an issue with using [UnitOfWork(IsDisabled = true)] after upgrading to v4.0.2. In an application service method with the unit of work disabled, querying a repository like _repository.Where(x => x.Id == id) throws a 500 error with the following message:

2020-12-22 17:01:26.918 -05:00 [ERR] Cannot access a disposed context instance. A common cause of this error is disposing a context instance that was resolved from dependency injection and then later trying to use the same context instance elsewhere in your application. This may occur if you are calling 'Dispose' on the context instance, or wrapping it in a using statement. If you are using dependency injection, you should let the dependency injection container take care of disposing context instances.
Object name: 'WebPlatformDbContext'.
System.ObjectDisposedException: Cannot access a disposed context instance. A common cause of this error is disposing a context instance that was resolved from dependency injection and then later trying to use the same context instance elsewhere in your application. This may occur if you are calling 'Dispose' on the context instance, or wrapping it in a using statement. If you are using dependency injection, you should let the dependency injection container take care of disposing context instances.
Object name: 'WebPlatformDbContext'.
   at Microsoft.EntityFrameworkCore.DbContext.CheckDisposed()
   at Microsoft.EntityFrameworkCore.DbContext.get_InternalServiceProvider()
   at Microsoft.EntityFrameworkCore.DbContext.get_ChangeTracker()
   at Microsoft.EntityFrameworkCore.Query.CompiledQueryCacheKeyGenerator.GenerateCacheKeyCore(Expression query, Boolean async)
   at Microsoft.EntityFrameworkCore.Query.RelationalCompiledQueryCacheKeyGenerator.GenerateCacheKeyCore(Expression query, Boolean async)
   at Microsoft.EntityFrameworkCore.SqlServer.Query.Internal.SqlServerCompiledQueryCacheKeyGenerator.GenerateCacheKey(Expression query, Boolean async)
   at Microsoft.EntityFrameworkCore.Query.Internal.QueryCompiler.Execute[TResult](Expression query)
   at Microsoft.EntityFrameworkCore.Query.Internal.EntityQueryProvider.Execute[TResult](Expression expression)
   at System.Linq.Queryable.FirstOrDefault[TSource](IQueryable`1 source)
   at Company.WebPlatform.WorkItems.WorkItemAppService.ExampleGetAsync(Guid id) in C:\Users\Jack\source\repos\WebPlatform\aspnet-core\src\Company.WebPlatform.Application\WorkItems\WorkItemAppService.cs:line 112
   ...
   ...
   ...
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync()
--- End of stack trace from previous location ---

To reproduce, query a repository in a method with unit of work disabled like so:

Controller:

[UnitOfWork(IsDisabled = true)]
[HttpGet]
[Route("test/{id}")]
public virtual Task<WorkItemDto> ExampleGetAsync(Guid id)
{
    return _workItemAppService.ExampleGetAsync(id);
}

AppService:

[UnitOfWork(IsDisabled = true)]
[AllowAnonymous]
public virtual async Task<WorkItemDto> ExampleGetAsync(Guid id)
{
    var test = _workItemRepository.Where(w => w.Id == id).FirstOrDefault(); //<<-- Error thrown here

    return ObjectMapper.Map<WorkItem, WorkItemDto>(test);
}

Execute the route from swagger and notice the error when the uow is disabled. It's worth noting the built in methods like _repository.GetAsync() still work.

Thanks for the help!

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()
Showing 31 to 40 of 42 entries
Made with ❤️ on ABP v9.1.0-preview. Updated on November 20, 2024, 13:06