Activities of "michael.sudnik"

We have tried it for a different user on a new computer and we did not have to add the solution to the abp suite (but had to install it).

• ABP Framework version: v4.3
• UI type: MVC
• DB provider: MongoDB
• Tiered (MVC) or Identity Server Separated (Angular): yes
• Exception message and stack trace:
• Steps to reproduce the issue:

Hi

We have had some difficulty getting a new developer (who has a license) up and running with an already existing abp solution.

We tried to run the application, and could see in the log that there was a license validation problem. So, we then used the cli to login to abp "abp login..." and were logged in succesfully. When trying to run the application again, there were no issues is the log file, but everytime we tried to run the application it kept coming up with a 404 error.

We could see that the application worked succesfully when in Release mode, but not in debug mode. Trying to replace the ASPNETCORE_ENVIRONMENT=Development to Production did not fix the problem either (just different error page but stil 404 error).

After trying different things, we then decided to try the abp suite. After installing it for the first time and then adding the existing solution to abp, we then found that that after running the solution again (debug, ASPNETCORE_ENVIRONMENT=Development ), the application now started correctly.

Should simply logging in using the cli "abp login..." be enough to be start working with a solution? Is this the best way to get a new developer started? Or is there a better way?

Best regards,

Mike

Created a new solution with RC1 (MVC, Mobile: None, MongoDB, Public web site (and CMS-kit), not tieried, Preview version). Ran the DB MIgrator. Started the web version without any problems. Tried to start the web.public and got the following error:

I have inherited from the base MongoDBRepository and added the following method

public virtual async Task<IAggregateFluent<TEntity>> GetMongoAggregatedAsync(CancellationToken cancellationToken, AggregateOptions options = null)
        {
            var sessionHandle = await GetSessionHandleAsync(cancellationToken);

            var collection = await GetCollectionAsync(cancellationToken);

            if (options == null)
                options = (await GetDbContextAsync()).ProvideDefaultAggregateOptions();

            IAggregateFluent<TEntity> aggregate = sessionHandle != null ? collection.Aggregate(sessionHandle, options) : collection.Aggregate(options);

            return ApplyDataFilters(aggregate);
        }

My dbcontext has the following

public interface IExtendedMongoDbContext : IAbpMongoDbContext
    {
        string GetCollectionNamePublic<T>();

        AggregateOptions ProvideDefaultAggregateOptions();
    }

I also have an equivalent new method for the GetMongoQueryableAsync.

At the very least, it would be nice if these methods were virtual, so that they could at least be overriden within a repository, allowing the default aggregation options to be specified.

https://github.com/abpframework/abp/blob/ef5f6fb81e5168d4e52493bc507c452e15692eae/framework/src/Volo.Abp.MongoDB/Volo/Abp/Domain/Repositories/MongoDB/MongoDbRepository.cs#L514

https://github.com/abpframework/abp/blob/ef5f6fb81e5168d4e52493bc507c452e15692eae/framework/src/Volo.Abp.MongoDB/Volo/Abp/Domain/Repositories/MongoDB/MongoDbRepository.cs#L528

• ABP Framework version: v4.2.1
• UI type: MVC
• DB provider: MongoDB
• Tiered (MVC) or Identity Server Separated (Angular): yes
• Exception message and stack trace:
• Steps to reproduce the issue:

I cannot find a nice way to specify the AggregationOptions used when using the GetMongoQueryableAsync or GetAggregateAsync methods.

Ideally, the following changes could be made:

• add an "AggregateOptions options = null" parameter to both the GetMongoQueryableAsync and GetAggregateAsync methods
• Create a virtual "CreateAggregationOptions" method on the AbpMongoDbContext to create the default AggregateOptions that should be used. Default return null.
• Create a virtual "CreateAggregationOptions" method on the MongoDbRepository to create the default AggregateOptions that should be used. Default return value from IAbpMongoDbContext.CreateAggregationOptions.

By being able to control the AggregationOptions in this way, we can then specify the Collation setting for a whole module, repository or specific query. Ideally, I would also like to specify the default AggregationOptions used for my entire application. E.g. by configuring some mongodb options.

I would also want to ablity to override the aggregation options specified in other modules (presumably this would be possible by replacing the DBContext).

An example why this is neccesary... Without specifying the collation (and accompanying index within the database) we cannot make results be ordered in a case insensitive way. E.g. By default the list "A, b, D, e" is ordered as "A, D, b, e" if a collation is not specified (resulting in a binary simple collation always being used). By specifying a collation, we can ensure that a particular index is used, which is defined as having a strength of 1 or 2 (case and diacritic insensitive).

Another minor improvement, which would be useful during aggregation pipelines (e.g. lookup generation) would be if the AbpMongoDbContext.GetCollectionName<> method was made public.

Thabks for that.

Are you also planning to modify datatables-extensions to automatically handle the abort if there is a pending request?

• ABP Framework version: v4.2.1
• UI type: MVC
• DB provider: MongoDB
• Tiered (MVC) or Identity Server Separated (Angular): yes
• Exception message and stack trace:
• Steps to reproduce the issue:

If I set the page size to a large number (e.g. 500), a request is pending. If I then subsequently change the page size to a small number (e.g. 10) the request is created and completed relatively quickly. The previous request is then still pending, and eventually completes resulting in the table being incorrectly updated.

Is there a way to cancel previous requests automatically when calling dataTable.ajax.reload()? Or is there a way to manually cancel a previous request?

I have looked at this file, but cannot figure out what to do to change the behaviour: https://github.com/abpframework/abp/blob/dev/framework/src/Volo.Abp.AspNetCore.Mvc.UI.Theme.Shared/wwwroot/libs/abp/aspnetcore-mvc-ui-theme-shared/datatables/datatables-extensions.js

• ABP Framework version: v4.2.1
• UI type: MVC
• DB provider: MongoDB
• Tiered (MVC) or Identity Server Separated (Angular): yes
• Exception message and stack trace:
• Steps to reproduce the issue:

The AbpUserClaimsPrincipalFactory is using the ClaimsIdentityExtensions.AddIfNotContains extension method, which is not adding any claims of the same type.

https://github.com/abpframework/abp/blob/c67dd7f25e61a81221259d5a9d5e9e7786e58aa1/modules/identity/src/Volo.Abp.Identity.Domain/Volo/Abp/Identity/AbpUserClaimsPrincipalFactory.cs#L75

What is the best way to replace or override this factory?

yes it is now fixed. thanks.

• ABP Framework version: v4.2.1
• UI type: MVC
• DB provider: MongoDB
• Tiered (MVC) or Identity Server Separated (Angular): yes
• Exception message and stack trace:
• Steps to reproduce the issue:

I am trying to run my already existing solution locally, but it is existing during the following:

My Expiry date is invalid within my organization details...