Activities of "maliming"

Hi,

First, to get you unblocked: restore the .abpmdl and .abpsln files from source control (their state before the update). Your packages were already upgraded to 10.5, so you keep the upgrade — only these two metadata files need fixing. After restoring, make sure there's no Unknown left in them and that the Volo.Abp.LeptonXTheme import is 5.5.0 (not the old 5.1.1).

For the cause: abp update writes Unknown like this when the package versions aren't set directly on each PackageReference but resolved centrally. Could you confirm how your versions are managed — do you use a Directory.Packages.props (Central Package Management), and are the versions there set through an MSBuild $(...) property? If you can share your Directory.Packages.props and one .csproj, I can confirm it matches what we've reproduced.

Thanks

👍

Hi,

Your current question credits have been refunded.

Thanks

Hi,

Let me split this into the switch itself and the actual filtering behavior, because they're separate.

The Npgsql switch

Npgsql.EnableLegacyTimestampBehavior only changes how Npgsql interprets a DateTime at runtime — it doesn't touch the column type. So your snapshot keeping timestamp with time zone is expected and correct; that column type is Npgsql's default EF Core mapping for DateTime, not something the switch controls. The template sets it to true purely for backward compatibility with the pre-Npgsql-6 behavior, so older code passing non-UTC DateTime values doesn't start throwing after the provider upgrade.

Turning it off does not require a schema migration or data fix — the columns stay timestamptz and your existing UTC data is untouched. It's a runtime/code change: with it off, any DateTime that isn't Kind=Utc throws immediately when written to a timestamptz column (... only UTC is supported) instead of being silently converted.

Why the filter doesn't match the timezone (on 9.2)

One thing to be aware of on 9.2: the __timezone header and UseAbpTimeZone() don't participate in binding the startTime/endTime filters at all — the model binder just normalizes the incoming value to Kind=Utc without any timezone conversion. So a query string value without an offset, like 2026-07-02T14:02:00, is treated as 14:02Z, not as 14:02 Johannesburg (12:02Z). Only a value that carries an explicit offset or Z is honored — e.g. 2026-07-02T14:02:00+02:00 is correctly read as 12:02Z.

So if the UI sends the picked local time without an offset, the query ends up off by your UTC offset. On 9.2 the way to make it match is to send the filter bounds already converted to UTC (with Z), or with an explicit offset. This is the same on any host, so it isn't tied to the Npgsql switch.

What changes on v10

This is relevant to your v10 question. ABP 10.2+ changed the DateTime model binding so that a value with no offset is now converted from the current request timezone (the __timezone/UseAbpTimeZone value) to UTC before querying. So on 10.2+ the bare local time from the client is interpreted using __timezone as you'd expect, whereas on 9.2 you have to send UTC explicitly. If moving the timezone handling out of your client code is worth it, that's a reason to upgrade. The template still keeps EnableLegacyTimestampBehavior = true in v10, and there are no ABP-specific migration steps for toggling it, since the switch is owned by Npgsql.

The local vs cloud difference

I can't say for sure what's behind this part yet without seeing the actual request. What I can say is that the standard filter binding is host-independent — the bound value is the same on a UTC+2 box and a UTC box — so a genuine difference between environments would most likely come from a DateTime reaching the query that isn't Kind=Utc. The usual source is custom or reporting code that builds filters with DateTime.Now / DateTime.Today / .ToLocalTime() instead of IClock: those are Kind=Local, and with the legacy switch true they get converted using the host machine's timezone, which would explain different boundaries per host. That's a direction to check, not a conclusion.

To narrow it down, it would help to capture the same filter in both environments and compare:

1. the raw audit-logs request (the startTime/endTime query values) from local and from cloud, and
2. the number of rows each returns.

If the two requests carry different values, it's the client computing UTC differently; if the requests are identical but the results differ, it's a server-side path passing a non-UTC value. In that second case, temporarily setting the switch to false in a staging environment is a fast way to surface it — a non-UTC value then throws right at the query and the stack trace points at the code that built it (staging only; in production it would make every non-UTC write fail). A snippet of any custom code that queries the logs directly would also help.

On (a) vs (b)

Keep audit/security timestamps as timestamptz and store UTC. Don't switch to timestamp without time zone — that just reintroduces ambiguity; these logs are absolute instants, which is exactly what timestamptz represents.

Thanks

Hi,

Your current question credits have been refunded.

Thanks

Hi,

This is an unintended behavior change in ABP 10, not by design. When the request is authenticated by a client (client_credentials) instead of a user, the dynamic proxy no longer forwards the incoming token and falls back to IdentityClients, so the downstream call goes out without auth and returns 401.

You can restore the previous behavior with this override:

using System.Threading.Tasks;
using Microsoft.AspNetCore.Authentication;
using Microsoft.AspNetCore.Http;
using Volo.Abp.DependencyInjection;
using Volo.Abp.Http.Client.Authentication;
using Volo.Abp.Http.Client.IdentityModel.Web;

namespace MyCompanyName.MyProject;

[Dependency(ReplaceServices = true)]
[ExposeServices(typeof(IAbpAccessTokenProvider))]
public class MyHttpContextAbpAccessTokenProvider : HttpContextAbpAccessTokenProvider
{
    public MyHttpContextAbpAccessTokenProvider(IHttpContextAccessor httpContextAccessor)
        : base(httpContextAccessor)
    {
    }

    public override async Task<string?> GetTokenAsync()
    {
        var httpContext = HttpContextAccessor?.HttpContext;
        if (httpContext == null)
        {
            return null;
        }

        if (httpContext.User.Identity?.IsAuthenticated != true)
        {
            return null;
        }

        return await httpContext.GetTokenAsync("access_token");
    }
}

We'll fix this in the framework in the next release, so you can drop the override after upgrading.

Thanks

Hi,

The failure comes from a stale module import version in your solution, not from the LeptonX packages themselves.

abp update runs in two steps: first it updates the package versions in your .csproj files (this part succeeds), then it runs a follow-up step that reads the imports section of your root .abpmdl file and, for each import, downloads that exact recorded version's .Installer package to re-sync the versions. Your .abpmdl still records Volo.Abp.LeptonXTheme at 5.1.1 (that's the LeptonX version from the ABP 10.1 era) and it was never bumped as you moved up to 10.4. So the update reaches back for Volo.Abp.LeptonXTheme.Installer 5.1.1, that request fails in your environment, and the whole update aborts. That's why you see it pulling such an old version.

Two things to fix it:

1. Make sure you're logged in so Studio can reach the commercial feed:

abp login <your-username>

2. Open the .abpmdl file at your solution root (<YourApp>.abpmdl), find the LeptonX import and bump its version to the one now referenced in your .csproj files after the update (for ABP 10.5 that's 5.5.0):

"imports": {
  "Volo.Abp.LeptonXTheme": {
    "version": "5.1.1",   // change to 5.5.0
    ...
  }
}

Save and run the update again. The re-sync step will then fetch the current installer and complete.

We'll also make this step more resilient in a next release so a stale import version can't break the whole update.

Thanks

Hi,

You're right, this is a bug on our side. When you use "Stop" on the whole Containers group ("Stop All"), ABP Studio brings the containers down with docker compose down -v, and the -v removes the Compose-managed named volumes too. Stopping an individual container doesn't remove the volumes, which is why the volume survives in that case.

For now, mark the volume as external so Compose won't remove it even on down -v:

volumes:
  meinwerk_opensearchdata:
    external: true
    name: meinwerk_opensearchdata

Then create it once before running:

docker volume create meinwerk_opensearchdata

External volumes are treated as pre-existing infrastructure, so down -v leaves them untouched, and your OpenSearch data will persist across "Stop All" from now on. One thing to watch: if your current data is sitting in a project-prefixed volume (e.g. <project>_meinwerk_opensearchdata), point name: to that exact volume instead of creating a new empty one.

We'll fix this in the next ABP Studio release so "Stop All" keeps the volumes just like stopping a single container does.

Thanks

Hi,

This isn't an accidental omission, but it only happens on Blazor UI solutions. On Blazor WebAssembly and Blazor Server, Suite hides Guid (and char) from the property type dropdown. On MVC and Angular solutions both are available as normal primitive types.

The reason is that the Blazor CRUD page generator currently has no input template for a standalone Guid field, so Suite leaves it out of the dropdown to avoid generating a form with a field you can't edit.

For your case — a Guid that's just an application identifier and not an FK — you don't need Suite to scaffold an input for it anyway, so the cleanest approach is to add it in the entity's custom-code file, which Suite keeps when you regenerate.

Make sure Customizable code is enabled for the entity. Suite then generates the entity as two files: Book.cs (the BookBase class, fully regenerated every time) and Book.Extended.cs (the Book class where your own code lives). If you don't see the .Extended.cs file, enable Customizable code and regenerate the entity first. Add the properties in the extended one:

// Books/Book.Extended.cs
public class Book : BookBase
{
    //<suite-custom-code-autogenerated>
    // (constructors are managed by Suite here)
    //</suite-custom-code-autogenerated>

    // Your custom code below is preserved on regeneration
    public Guid ExternalId { get; set; }
    public Guid? LinkedEntityId { get; set; }
}

One thing to keep in mind: since these live in your custom code and not in the Suite entity model, Suite won't add them to the DTOs, the app service, or the CRUD UI. That's fine when the value is set/read by your own domain/application code, which matches your "logical association, not an FK" scenario.

Then add a migration and update the database (run from your EF Core project, or add the migration there and apply it with the DbMigrator):

dotnet ef migrations add Added_External_Guids
dotnet ef database update

With SQL Server these map to plain uniqueidentifier columns. They won't become navigation properties or foreign keys unless you add a relationship yourself.

We'll look at adding first-class Guid support to the Blazor generator in a future Suite version so you can pick it directly from the dropdown.

Thanks

: )