Activities of "bmulinari"

I appreciate the AI-generated response, but I'd like to hear the ABP team's input on this matter.

Thanks!

I have verified that adding UseAbpTimeZone to my application initialization does seem to solve the issue in the /audit-logs page and it now shows the correct local time:

Still, it's not clear to me when to have UseAbpTimeZone or not (I couldn't find any documentation on it besides your article).

The inconsistency shown in my previous post does seem like a bug... 🤔

Hi there.

I have migrated my application to ABP 9.2.0 and applied the migrations that updated all timestamp columns in the database to type timestamp without time zone. I'm using both Npgsql.EnableLegacyTimestampBehavior and AbpClockOptions.Kind = DateTimeKind.Utc. With this, I believe now I have the correct time zone configurations both in application and database according to your instructions.

With that said, I still observe the issue I reported initially, where the time displayed in the audit logs page is incorrect, ignoring the time zone settings (application or account). Here are some screenshots:

/audit-logs page, showing UTC time (❌ incorrect)

AbpAuditLogs table, storing UTC time (✅ correct)

/Account/SecurityLogs page, showing local time (✅ correct)

AbpSecurityLogs table, storing UTC time (✅ correct)

Sorry for the delay on this. I think it's important to explain in more details my concern regarding the correct time zone settings.

When we initially migrated to PostgreSQL, the migration guide didn't include the instruction to use the EnableLegacyTimestampBehavior setting. That means that when we followed the old version of the guide, we got the same error reported here, and in this same thread you can see that the solution is to set AbpClockOptions.Kind to DateTimeKind.Utc to fix the error, so that's what we did and it worked.

So now that the migration guide has been updated to include the EnableLegacyTimestampBehavior setting, the AbpClockOptions setting we used seems no longer needed.

However, if I try to include the EnableLegacyTimestampBehavior setting now, that results in changes to all timestamp columns in the DB (migrations) since this setting controls the type for these columns. For example:

// ...
migrationBuilder.AlterColumn<DateTime>(
    name: "DeletionTime",
    table: "AbpUsers",
    type: "timestamp without time zone",
    nullable: true,
    oldClrType: typeof(DateTime),
    oldType: "timestamp with time zone",
    oldNullable: true);
// ...

I have not applied this migration since I'm not sure if it's the right thing to do in this case.

Considering this situation, what would be the recommended course of action? I think that before I can reliably report any problem related to time zone, first I need to ensure everything is correct in my application and database.

Hi,

I see that there were a bunch of changes related to time zones in 9.2.0, so I updated to it to test and the issue I described above still persists in 9.2.0. The article you linked is the same one I linked.

Also, I would appreciate if you could confirm the correct settings to use in our case.

Thanks!

Awesome, thank you.

Thanks, @maliming. This seems to solve the issue.

From my understanding looking at GitHub these fixes will be available in version 9.3, is that right? I just want to confirm that it will be safe to remove these once that version is out and we upgrade to it.

Thank you.

Hi, @maliming. I've tried doing the override you mentioned, but it doesn't seem to make a difference.

I managed to narrow it down and I've created a fresh project that reproduces the issue. You should receive the code in your email.

Here are the steps to reproduce:

• Run DB migrator
• Start Blazor App and login to host
• Create a new tenant
• Assign Standard edition To tenant
• Go to editions and enable "My Custom Feature" for the Standard edition
• Login to the tenant and navigate to the Dashboard
• You should see the feature check displaying the feature as enabled in the page
• However, in the app console, you'll see the log from the background worker showing the same feature as disabled

Here's an image demonstrating the issue on the sample project:

Hi, @EngincanV. Any update on this?

Regarding the favicon, I managed to fix it by adding the favicon.svg file. Previously we had only a favicon.ico file.

Hi, @EngincanV thanks for the response.

I tested the change with the steps you mentioned and it did work, that is, the table created in the previous module is no longer created again in the migration for the new module.

However, I noticed that this only worked when I ran the command to remove the latest migration twice (as you instructed), and as expected that removes the last two migrations, even though the second to last migration it removes has no relation to the latest one or its tables. I don't understand why that is the case, could you please provide an explanation?

Thanks in advance.