Activities of "bmulinari"

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

Thanks!

Hi,

From what I could find in the documentation and in this article, bundling JavaScript or CSS files is only mentioned for Blazor WebAssembly, no mention of Blazor Server. From my tests the BundleContributor approach does not seem to work for Blazor Server.

For now the workaround has been collocated JavaScript files with specific components.

Does ABP offer any way to do file bundling in Blazor Server? What would be the correct approach?

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!

Hi there.

We have identified an inconsistency in the audit logs page (/audit-logs), where the time shown in the log entries is always fixed to the value saved in the database (UTC), so any time zone setting is ignored in this page (host time zone or user account time zone setting).

This does not happen in the security logs (/Account/SecurityLogs) where I can verify that it correctly displays the time based on the time zone setting.

Is this intended or a bug?

For added context, we are currently using the following settings related to the time zone:

• Npgsql.EnableLegacyTimestampBehavior enabled, since we are using PostgreSQL (as instructed here).
• AbpClockOptions.Kind set to DateTimeKind.Utc (as instructed here).

Should both of these settings be used at the same time? I just want to ensure we are configuring time zones correctly in the application.

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: