We would like to implement the logic which implies assigning permissions to a custom role, while such custom role in turn is assigned to a standard role of the system. Could you please advice how can we fulfil such task by means of ABP framework?
We love the framework but support and bug reporting is not handled well. My developer has mostly given up reporting issues as he says it's not worth it as responses tend to be one line, minimum effort answers. Complex issues often just get auto-closed without resolution.
I don't mind the one line answers but they should not be considered a paid response to an issue when we only get to report 15 a year. Basic forum responses should not be included in any limit.
Fully agree. I also noticed that the quality of the support has deteriorated: 2-3 year ago the replies (from the same support team members, BTW) were more meaningful, detailed and looked like a "ready-to-help" dialog. Now it looks like the total amount of work on the growing framework has noticeably increased since then and the support team simply does not manage to handle the support tickets. Well - it's the most careful explanation I have.
Mosf of the time - when we have a technical question - we are asked to either send the project source code or create the test version where the problem is reproduced.
The first one is not possible because of commercial nature of the project. The second one is very time consuming and is not possible too.
Yes, our solution is quite complex and we have some custom code on the top of ABP framework. But it would be great, if your support team devoted more time trying to understand the nature of the problem and analyze the fragments of the code shown in the message. Because often the answers are very short and meaningless - so we end up debugging out solution and looking at the downloaded ABP module source codes to resolve the problem ourselves.
p.ClrType == typeof(ExtraPropertyDictionary)
That was it. I was checking against string type only, would not expect such ClrType. Seems like I finally got rid of NVARCHAR. Thank you. I will keep this ticket open for some time until the migration is done...
And again you don't understand what I'm trying to say. I'm telling you that migration using a standard driver causes problem now. I have shown you the fragments of the code. Migration with Devart which has always been used never caused the problem. But now Devart cannot be used, they delay the NET7 support for month or so. You have published ABP7, but rely on Devart. Can you offer a working migration solution NOW?
Ok. But that was not my main question. My main question is why output generated by Devart differs from the standard one? They are supposed to be identical. Are you saying that output generated by standard driver is incorrect and cannot be used for Oracle migration??
Unfortunately, we don't have time and need to migrate now. So we need to use a generic Oracle driver.
The script which is generated by the generic driver, looks weird, though - it suggests to replace VARCHAR fields in ABP tables with NVARCHAR. There are a lot of such changes. Could you please explain, why in a 7.0.1 test app you are suggesting to use NVARCHAR/NVARCHAR2 DB type:
but at the same time the suggested Devart-based DB configuration has the following options, i.e. the DB fields are generated as VARCHAR/VARCHAR2?
So currently the generated migration script has tons of suggested changes like this (it compares the previously created migration using Devart and a generic dviver generation now):
I've tried to get rid of NVARCHAR manually in the DB migration context:
protected override void OnModelCreating(ModelBuilder builder)
{
//var config = Devart.Data.Oracle.Entity.Configuration.OracleEntityProviderConfig.Instance;
//config.Workarounds.DisableQuoting = true;
//config.CodeFirstOptions.UseNonLobStrings = true;
//config.CodeFirstOptions.UseNonUnicodeStrings = true;
base.OnModelCreating(builder);
/* Include modules to your migration db context */
builder.ConfigurePermissionManagement();
builder.ConfigureSettingManagement();
builder.ConfigureBackgroundJobs();
builder.ConfigureAuditLogging();
builder.ConfigureIdentityPro();
builder.ConfigureIdentityServer();
builder.ConfigureFeatureManagement();
builder.ConfigureLanguageManagement();
builder.ConfigureTextTemplateManagement();
builder.ConfigureBlobStoring();
builder.ConfigureSaas();
foreach (var property in builder.Model.GetEntityTypes().SelectMany(e => e.GetProperties()).Where(p => p.ClrType == typeof(string)))
{
property.SetIsUnicode(false);
}
}
But it still generates me migration script with NVARCHAR/NVARCHAR2...
This does not help either:
protected override void ConfigureConventions(ModelConfigurationBuilder configurationBuilder)
{
configurationBuilder.DefaultTypeMapping<string>().IsUnicode(false);
}
I have a couple of issues / questions with the migration.
Server side: probably because of absent Devart Oracle driver which supports .NET 7.0+ the Add-Migration causes the following error (please note that we have set target=NET7 for all our projects):
Return type in method 'Devart.Common.Entity.c5.FindMapping(System.Type)' on type 'Devart.Common.Entity.c5' from assembly 'Devart.Data.Oracle.Entity.EFCore, Version=9.16.1434.0, Culture=neutral, PublicKeyToken=09af7300eec23701' is not compatible with base type method 'Microsoft.EntityFrameworkCore.Storage.RelationalTypeMappingSource.FindMapping(System.Type)'.
The Add-Migration itself with the standard driver completes successfully, but when I run Update-Database - very soon I end up with the errors related to Upper / Lower case in Table/Column names + quotes around those. We did not have such problems with Devart thanks to these options:
var config = Devart.Data.Oracle.Entity.Configuration.OracleEntityProviderConfig.Instance;
config.Workarounds.DisableQuoting = true;
config.CodeFirstOptions.UseNonLobStrings = true;
config.CodeFirstOptions.UseNonUnicodeStrings = true;
How to make a successful migration? Sorry - I cannot share the source code.
Client side: it is not clear which version of Angular should we use now, with ABP 7.0.1. We have had Angular 13 so far...I've tried to upgrade Angular after using abp update, but faced the compilation problem for our Angular packages, similar to these, but related to ng-bootstrap and other material components. So what Angular version should we use? Should we upgrade from version 13 and how to make it correct?
hi
I think there is no problem with this.
Restore my question points then please if not done yet.
Eventually I've resolved thie issue. I've split the shared project DbContexts into 2 - one contains the entities which are shared in the consuming project, another one contains the entities which use the same table as the entities in the consuming project. Please, replenish my point for this question.