Activities of "vkelwan"

Thanks, that makes sense. To confirm I understand correctly:

Given that we currently have no email sender (SMTP) and no SMS provider configured in our solution, and users have not enrolled any authenticator app —

Does this mean an admin can currently only ever turn OFF two-factor authentication for a user (since disabling doesn't require a provider check), but can never turn ON 2FA for any user from the Users grid, until that specific user either (a) sets up an authenticator app themselves via My Account, or (b) we configure a working email/SMS sender at the application level?

In other words, is it correct that there is no scenario in which an admin can enable 2FA for a user purely from the Identity Management → Users → Two factor screen, without either the user doing self-enrollment first or us adding provider infrastructure (SMTP/SMS) — the "Email Confirmed" checkbox alone is never sufficient on its own?

Just want to confirm this is expected behavior by design, not a bug or misconfiguration on our end.

Hello, Thank, you, but what if I have multiple decimal types?

protected override void ConfigureConventions(ModelConfigurationBuilder configurationBuilder) { base.ConfigureConventions(configurationBuilder); configurationBuilder.Properties<decimal>().HavePrecision(18, 6); } protected override void OnModelCreating(ModelBuilder builder) { base.OnModelCreating(builder);

const string PriceDecimalType = "decimal(18, 6)";
const string CordinateDecimalType = "decimal(18, 10)";
const string DecimalType102 = "decimal(10, 2)";
const string DecimalType182 = "decimal(18, 2)";

builder.ConfigureEventInbox();
builder.ConfigureEventOutbox();


builder.Entity<OutboxJournalEntry>(b =>
        {
            b.ToTable(DbTablePrefix + "OutboxJournalEntries", DbSchema);
            b.ConfigureByConvention();
            b.Property(x => x.TenantId).HasColumnName(nameof(OutboxJournalEntry.TenantId));
            b.Property(x => x.BookingId).HasColumnName(nameof(OutboxJournalEntry.BookingId));
            b.Property(x => x.DetailId).HasColumnName(nameof(OutboxJournalEntry.DetailId));
            b.Property(x => x.ServiceTypeId).HasColumnName(nameof(OutboxJournalEntry.ServiceTypeId));
            b.Property(x => x.Narration).HasColumnName(nameof(OutboxJournalEntry.Narration)).HasMaxLength(OutboxJournalEntryConsts.NarrationMaxLength);
            b.Property(x => x.BuyingROE).HasColumnName(nameof(OutboxJournalEntry.BuyingROE));
            b.Property(x => x.SellingROE).HasColumnName(nameof(OutboxJournalEntry.SellingROE));
            b.Property(x => x.IsSameCurrency).HasColumnName(nameof(OutboxJournalEntry.IsSameCurrency));
            b.Property(x => x.EventType).HasColumnName(nameof(OutboxJournalEntry.EventType)).HasMaxLength(OutboxJournalEntryConsts.EventTypeMaxLength);
            b.Property(x => x.RetryCount).HasColumnName(nameof(OutboxJournalEntry.RetryCount));
            b.Property(x => x.PublishedAt).HasColumnName(nameof(OutboxJournalEntry.PublishedAt));
            b.Property(x => x.Status).HasColumnName(nameof(OutboxJournalEntry.Status));
            b.Property(x => x.ServiceTypeName).HasColumnName(nameof(OutboxJournalEntry.ServiceTypeName)).HasMaxLength(OutboxJournalEntryConsts.ServiceTypeNameMaxLength);
            b.Property(x => x.ReverseSupplierId).HasColumnName(nameof(OutboxJournalEntry.ReverseSupplierId));
            b.Property(x => x.UserId).HasColumnName(nameof(OutboxJournalEntry.UserId));
            b.Property(x => x.UserTypeId).HasColumnName(nameof(OutboxJournalEntry.UserTypeId));
            b.Property(x => x.Amount).HasColumnName(nameof(OutboxJournalEntry.Amount));
            b.Property(x => x.TaxTypeCode).HasColumnName(nameof(OutboxJournalEntry.TaxTypeCode)).HasMaxLength(OutboxJournalEntryConsts.TaxTypeCodeMaxLength);
            b.Property(x => x.HeaderId).HasColumnName(nameof(OutboxJournalEntry.HeaderId));
            b.Property(x => x.EntityType).HasColumnName(nameof(OutboxJournalEntry.EntityType)).HasMaxLength(OutboxJournalEntryConsts.EntityTypeMaxLength);
            b.Property(x => x.CurrencyId).HasColumnName(nameof(OutboxJournalEntry.CurrencyId));
            b.Property(x => x.CurrencyCode).HasColumnName(nameof(OutboxJournalEntry.CurrencyCode)).HasMaxLength(OutboxJournalEntryConsts.CurrencyCodeMaxLength);
            b.Property(x => x.BaseAmount).HasColumnName(nameof(OutboxJournalEntry.BaseAmount));
            b.Property(x => x.BookingDate).HasColumnName(nameof(OutboxJournalEntry.BookingDate));
            b.Property(x => x.CheckinDate).HasColumnName(nameof(OutboxJournalEntry.CheckinDate));
            b.Property(x => x.CheckOutDate).HasColumnName(nameof(OutboxJournalEntry.CheckOutDate));
            b.Property(x => x.DeadlineDate).HasColumnName(nameof(OutboxJournalEntry.DeadlineDate));
            b.Property(x => x.acc).HasColumnName(nameof(OutboxJournalEntry.acc));
        });

This is my dbcontext file, and from this check, BaseAmount is 18,6 and BuyingROE is 18,10. but it's removing when I am adding a new column in this entity

Thanks for confirming. I've implemented the workaround as suggested — a global EF Core convention that sets decimal(18,6) precision/scale on all decimal properties that don't already have an explicit override, added at the end of OnModelCreating in the Suite-generated DbContext:

foreach (var property in builder.Model.GetEntityTypes() .SelectMany(t => t.GetProperties()) .Where(p => p.ClrType == typeof(decimal) || p.ClrType == typeof(decimal?)) .Where(p => p.GetColumnType() == null)) { property.SetPrecision(18); property.SetScale(6); } My concern: this file ({Service}DbContext.cs) is regenerated/appended to by Suite every time I add a new entity via the designer. You mentioned putting this "outside the generated/regenerated parts" — but this file is exactly the one Suite writes to when generating entities.

Given that, what is the officially recommended safe location for this kind of global convention so it's guaranteed not to be affected by future Suite generations? Specifically:

Is it safe to leave this code at the end of OnModelCreating in the Suite-generated DbContext, given Suite only appends new builder.Entity<...>() blocks and doesn't rewrite the whole file? Or should this go in a separate partial class file, a custom IModelCustomizer, or some other Suite-recommended extension point? Does ABP Suite provide any "custom code" region/marker (similar to the //Write your custom code here... marker in Extended entity files) inside the generated DbContext that is guaranteed to survive regeneration? Appreciate a definitive answer so I don't lose this configuration on the next Suite run.

Okay, I will check and update you

Okay so once I am done with all, then it will work and hide form permission when I disable that tour feature right?

But if the feature tour is not checked, then also get permission?

Hi,

We have deployed the diagnostic services and collected the logs. Please find the detailed diagnostic output attached in the email.

Thanks

Hello ResourcePermissionManager and ResourcePermissionGrantRepository might be do not exit in my abp (9.2.0) version Because I am getting these errors

Hello i have created another query please reply in that

No you did not understand what i am asking

i have check this query also in administation host and tenant databse

SELECT * FROM AbpFeatureValues WHERE Name LIKE '%TourModule%' OR Name LIKE '%TourService%' ORDER BY ProviderName, ProviderKey;

no record