Activities of "enisn"

Hi,

Thanks for reporting this issue.

You are right that AI Management is not intended to work as a tenant-scoped feature. The problem was caused by the workspace-data-sources blob container still using tenant-aware blob storage behavior.

We have confirmed and fixed this issue by configuring that container as shared instead of tenant-scoped and it'll be published in the next patch release.

As a temporary workaround on your project, you can configure the same container as shared in one of your application's module ConfigureServices methods:

using Volo.Abp.BlobStoring;
using Volo.AIManagement;

public override void ConfigureServices(ServiceConfigurationContext context)
{
    Configure<AbpBlobStoringOptions>(options =>
    {
        options.Containers.Configure<WorkspaceDataSourceBlobContainer>(container =>
        {
            container.IsMultiTenant = false;
        });
    });
}

Please note that this changes the resolved blob path from tenant-scoped to shared/host-scoped. So if you already uploaded documents under tenants/<tenant-id>/..., those existing files may need to be re-uploaded after applying the workaround.

This fix will be included in the next patch release.

Best regards,

ABP Support Team

Hi,

Thanks for the detailed report and the reproduction steps.

We reviewed the scenario with ABP 10.3.0, LeptonX 5.3.0, and Blazorise 2.0.4. This matches an issue in the LeptonX custom select overlay rather than a problem with your data binding.

In the affected LeptonX version, the custom overlay is applied to select.form-select controls and builds its own visible option list from the native <select>. This causes two problems in the scenarios you described:

• <optgroup> labels are not preserved in the custom overlay, so grouped options are displayed as a flat list.
• In the Blazorise modal scenario, the native <select> can contain the correct <option> elements while the custom overlay list remains empty or out of sync after the modal/component render cycle.

We are tracking this in Lepton issue #3488, and the fix is being handled in PR #3491. The fix is targeted for the LeptonX 5.2 patch line and will be available with a 5.2.x patch package after the PR is merged and released.

You can track issues and releases from here: abp.io/pro-releases

Until the fix is available in a LeptonX package release, the safest workaround is to avoid the LeptonX custom select overlay for the affected controls:

• Use a native <select> that does not use the form-select class for grouped selects and modal-hosted selects, for example class="form-control" as you already tried.
• Keep explicit @onchange handlers for non-string or nullable enum values, because the native select value is received as a string.
• Scope the workaround only to selects that use <optgroup> or are rendered inside the affected modal flow.

Your DOM verification is also the right way to confirm the issue: if DevTools shows the expected <option> / <optgroup> nodes in the native select but the LeptonX dropdown is flattened or empty, the problem is in the custom overlay rendering/synchronization layer.

We will update this ticket when the LeptonX 5.2.x patch package is available. If you still see an empty dropdown with a native select that does not use form-select, please share a minimal component/page that reproduces it, because that would indicate a separate rendering path.

Since this was confirmed as a product issue in LeptonX, we have refunded your support ticket credit.

Best regards,

ABP Support Team

Hello again,

A new documentation PR has just dropped. https://github.com/abpframework/abp/pull/25245

I know, it's not what you seek currently, but a new React option comes with a couple of different theme/style options. It seems it's not for existing projects, I'll try to deliver new updates whenever they're publicly available. Stay tuned!

Best regards,

ABP Support Team

Hi,

Select2 has a specific issue and we're fixing it in the next patch version of leptonx as soon as possible. I'll deliver other concerns to the design team to work leptonx enhancement to prevent breaking existing applications.

I'll update the latest state about it. For now, your workaround seems valid until the next patch

I had same issue, and fix it by removing form-select from select class.

In the screenshots, I saw you're using your own stylings already. As a workaround I can recommend downgrading only LeptonX package to 5.1 will help you.

  <ItemGroup>
    <PackageReference Include="Volo.Abp.AspNetCore.Mvc.UI.Theme.LeptonX" Version="5.1.1" />
  </ItemGroup>

And rest of the ABP references can stay at v10.2 until we find the real problem on your case. Please provide the information that I asked in the previous messages to help us to detect the original source of the problem

Best regards,

ABP Support Team

Hi again,

I realized you're using your own custom theming, probably you removed some of leptonx styles but not javascript bundles.

What you are seeing is not the <abp-select> tag helper rendering the field twice. In LeptonX 10.2, select.form-select elements are enhanced with a custom wrapper/display element. The HTML you shared is consistent with that behavior: the original <select> is wrapped in custom-select-wrapper and a custom-select-display element is added next to it.

The problem is that the original native <select> should then be hidden by the LeptonX theme CSS. When both controls are visible together, it usually means the corresponding LeptonX bootstrap/theme CSS is not taking effect on the page.

Since this happens for every dropdown on the site, the issue is most likely at the theme asset/layout level rather than in the page markup itself.

Please check these items:

1. In the browser Network tab, verify that the active LeptonX theme CSS is loaded successfully, for example ~/Themes/LeptonX/Global/side-menu/css/bootstrap-light.css, bootstrap-dark.css, or bootstrap-dim.css depending on the selected style.
2. In the browser Styles/Computed pane, inspect the native <select> inside .custom-select-wrapper and check whether the LeptonX rule that hides it is present and whether it is being overridden by another stylesheet.
3. If you are using a custom layout via LeptonXThemeMvcOptions.ApplicationLayout, or if you have overridden Themes/LeptonX/Layouts/Application/SideMenuLayout.cshtml or TopMenuLayout.cshtml, please compare that layout with the current LeptonX 10.2 layout and make sure the LeptonX style bundle and theme CSS links are still included.
4. If you have custom CSS in global-styles.css or another bundle, temporarily disable it and test again, because a global override on .form-select / select can cause the native control to remain visible.

This is also why downgrading to 10.1 makes the problem disappear: the newer LeptonX custom-select enhancement in 10.2 is active, but the CSS that should hide the original select is not being applied correctly in your application.

If the problem continues after these checks, please send us these details and we can narrow it down quickly:

1. Whether you override the LeptonX application layout or use a custom ApplicationLayout
2. A screenshot of the Network tab for the bootstrap-*.css request(s)
3. A screenshot of the Styles pane for the visible native <select> element

Hi

I've tested with fresh app on version 10.2.0 and LeptonX version is 5.2.0 and couldn't reproduce the exact same problem with your example:

I confirm that issue was happening in rc.1 version and it was immediately patched, so this stable version shouldn't have this problem. Can you provide me your ABP version and LeponX exact version from your .csproj file?

Also as far as I see, a newer patch version is live which is 10.2.1 on ABP and 5.2.1 on LeptonX. You can try with the patch version and ensure your bin and obj folders are cleaned to ensure the latest LeptonX package has to be restored.

Thanks for confirming.

Glad to hear it is sorted.

For future reference, this kind of behavior is usually caused by the backend app/service handling /api/identity/users running without the correct tenant context in production. In tiered or separated deployments, app.UseMultiTenancy() should be enabled on that backend service and placed after app.UseAuthentication() as in the ABP startup templates.

Also, the maximum of 5 users message is a separate feature limit. If you see that again, please check Identity -> Maximum user count on the tenant, its edition, or host features depending on your setup.

Hi,

Thanks, that clarification helps.

Since both SecondaryUI.web and the main server are MVC-based, the recommendation becomes more specific for the standard ABP setup:

• Keep the actual File Management backend and the FileManagementContainer BLOB provider configuration in HttpApi.Host.
• In SecondaryUI.web, Volo.FileManagement.Web alone is typically not enough.
• For this MVC-to-MVC client scenario, you typically need Volo.FileManagement.Web + Volo.FileManagement.HttpApi + Volo.FileManagement.HttpApi.Client in SecondaryUI.web.

The reason is:

• Volo.FileManagement.Web uses JavaScript proxies and upload/download endpoints against the current application's root (abp.appPath / /api/file-management/...).
• So, in a second MVC application, those requests first hit SecondaryUI.web itself.
• Volo.FileManagement.HttpApi provides the local File Management HTTP API controllers in that MVC application.
• Volo.FileManagement.HttpApi.Client allows those controllers to call the real backend on HttpApi.Host through remote client proxies.

So in practice, SecondaryUI.web acts as an MVC UI + local API facade, while HttpApi.Host remains the real storage/processing side.

One more important point:

• In SecondaryUI.web, make sure the remote service configuration for File Management points to the main host application.
• The File Management module uses the remote service name FileManagement, so this should be configured against the HttpApi.Host base URL.
• In practice, this usually means configuring RemoteServices in SecondaryUI.web's appsettings.json.

For example:

"RemoteServices": {
  "Default": {
    "BaseUrl": "https://localhost:44300/"
  },
  "FileManagement": {
    "BaseUrl": "https://localhost:44300/"
  }
}

• Here, https://localhost:44300/ should be replaced with your main HttpApi.Host URL.
• Since Volo.FileManagement.HttpApi.Client registers its proxies with the remote service name FileManagement, that named endpoint is the clearest configuration.
• Also note that ABP falls back to RemoteServices:Default if a named FileManagement endpoint is not defined. So if your Default endpoint already points to the same HttpApi.Host, a separate FileManagement section may not be strictly required.
• The relevant ABP documentation is here: https://abp.io/docs/10.2/framework/api-development/static-csharp-clients

The folder isolation and any per-user quota logic should still be enforced on the server side.

Best regards,

ABP Support Team

Hi,

To determine the exact cause, we need a little more information about your setup, because this kind of problem is often environment-specific in tiered or separated deployments.

Could you please share the following details?

1. Your exact ABP version.
2. Which startup template you are using.
3. Which UI you are using.
4. Whether this is a tiered solution / separated auth-server setup / microservice solution.
5. Which application actually handles the /api/identity/users request in production.
6. Which reverse proxy or deployment technology you are using in production.
7. How tenant resolution is configured in production.

Please also confirm these points:

• Does this happen for all tenants or only one tenant?
• Does it happen only in production, while local always works?
• Is the tenant selected by subdomain, domain, header, cookie, or another custom resolver?

If possible, please send these screenshots/details from production:

1. The browser Network tab for the users create request:
   • Request URL
   • Request headers
   • Response preview showing tenantId
2. The tenant's Features dialog, especially Identity -> Maximum user count
3. If the tenant uses an edition, the edition's Identity -> Maximum user count value too

Reason for asking: in tiered/separated deployments, the UI may look like it is inside a tenant context while the backend request is still resolved as host, especially when tenant resolution depends on proxy-forwarded host/header/cookie information.

Once you share these details, we can tell you exactly where to check next.

Best regards,

ABP Support Team