Activities of "enisn"

Hi,

Thanks for the details and screenshots.

These screenshots point to two separate things:

1. In your local screenshot, the created user response contains a non-null tenantId.
2. In production, the created user response shows "tenantId": null.

In ABP, a new identity user is created with the current tenant context. So when tenantId is null, the request is being handled in host context in production.

The later maximum of 5 users dialog is a different check. I verified this from the source:

• This is controlled by the Identity.MaxUserCount feature.
• Its default value is 0, which means unlimited.
• So if you are seeing 5, that value was explicitly set for the current context.

Please check these from the host side:

1. On the app/service that serves the user creation API, make sure app.UseMultiTenancy() is enabled and placed after app.UseAuthentication() as in the startup templates.
2. Verify that your production tenant resolver is working for that API as well. Since the production response shows tenantId: null, the API is currently not resolving the tenant there.
3. Open the tenant's Features dialog and check Identity -> Maximum user count.
4. If the tenant is assigned to an edition, also check the edition's feature value, because feature lookup falls back from tenant to edition.
5. If you want no limit, set Maximum user count to 0.

Also, if the request is still running as host in production, the 5 value may be coming from the host feature/configuration instead of the tenant. In that case, also check Settings -> Feature Management -> Manage Host Features.

If it still continues, please share:

• Which app/service handles the /api/identity/users endpoint.
• How tenant resolution is configured in production (domain/subdomain, header, cookie, etc.).
• A screenshot of the Identity -> Maximum user count value for that tenant or its edition.

Best regards,

ABP Support Team

Hi,

Thanks for the details.

Yes, this scenario is possible without multi-tenancy.

• In a tiered solution, SecondaryUI.web should be treated as another UI/remote-client application. The File Management HTTP endpoints and the actual file storage are on the server side, so the BLOB provider configuration for FileManagementContainer should be done in HttpApi.Host, not in SecondaryUI.web.
• File Management's built-in storage size limit is tenant-based. In a non-multi-tenant application, this effectively becomes a single host-wide limit, not a per-user limit.

To make the project split clearer:

• The exact project/package list depends on whether SecondaryUI.web is MVC/Razor Pages, Blazor, or another UI setup, so we should not prescribe one fixed package list without seeing the solution structure.
• However, the responsibility split should be like this:
• On the server side, the File Management backend and FileManagementContainer BLOB provider configuration should exist in the application that exposes the File Management HTTP API and stores the files, which in your case is HttpApi.Host.
• On SecondaryUI.web, you should use the UI package for the framework you are using, and if this application works as a remote client, it should consume the File Management remote API through the client/proxy side (Volo.FileManagement.HttpApi.Client or the equivalent proxies added by the module installation).
• For example, the File Management module provides separate UI-side packages such as Volo.FileManagement.Web for MVC/Razor Pages and Volo.FileManagement.Blazor for Blazor, while remote API client proxies are provided by Volo.FileManagement.HttpApi.Client.
• So, the important point is not that SecondaryUI.web should have no File Management references; it can have the UI/client-side references. The important point is that storage provider configuration and actual persistence behavior belong to the host side.
• For a second MVC/Razor Pages application specifically, Volo.FileManagement.Web alone is generally not enough when the real backend is on another server application. The module's JavaScript proxies and upload/download URLs target the current application's root (abp.appPath / /api/file-management/...).
• Because of that, in this MVC/Razor Pages scenario you typically need Volo.FileManagement.Web + Volo.FileManagement.HttpApi + Volo.FileManagement.HttpApi.Client together in SecondaryUI.web.
• In that setup, the local File Management HTTP API controllers in SecondaryUI.web receive the requests from the module UI, and those controllers can delegate to the remote application through the HttpApi.Client implementations.
• If you build a custom reverse-proxy/base-url setup, you may organize it differently, but for the standard second MVC/Razor Pages client scenario, this clarification is important.

For your scenario, the recommended approach is:

1. Create one root directory for each user in the host application.
2. Let SecondaryUI.web use the existing File Management APIs/proxies exposed by the host.
3. Grant that user access only to their own root directory.
4. Keep upload, download, move, and delete operations inside that user's directory tree.

There is also an important point for your follow-up question about permissions:

• This is already available in ABP File Management 10.2.
• File Management already defines built-in resource permissions for directories and files.
• These permissions are checked by the module during directory/file operations, and directory permissions can apply through the parent directory chain.
• So you do not need to build a completely separate folder-permission infrastructure for the module itself; you mainly need to grant and manage the correct resource permissions for each user's root folder.

So, to limit a user to only their own folder, the usual design is to:

• give the user the basic File Management access needed to open the module,
• create a dedicated root folder for that user,
• grant resource permissions only for that folder (and its descendants),
• avoid granting broad create/update/delete permissions globally unless the user should have full access everywhere.

For the storage quota part:

• If you want a different quota for each user, this requires customization in the host application.
• The module's built-in storage check is based on the current tenant/host total usage, not on a specific user's folder size.
• For a per-user quota, you should add a custom upload validation that calculates the total size under the current user's root directory and rejects the upload when the user-specific limit is exceeded.

So, for your original questions:

1. Configure the File Management storage provider in HttpApi.Host, and use SecondaryUI.web as the UI/client side that consumes the File Management functionality from the host.
2. Yes, it works without multi-tenancy, but per-user quota is not built in and needs a custom implementation.

If you want, we can also share a recommended server-side design for automatically creating the user's root folder, granting the correct resource permissions, and enforcing a per-user upload quota.

Best regards,

ABP Support Team

Hi,

Thanks, yes, this is the important part of the error:

• Invalid object name 'AIManagementApplicationAIProviders'

So this is not an OpenAI package problem and it is not a client-proxy problem.

SQL Server is saying that the AIManagementApplicationAIProviders table does not exist in the database currently used by HttpApi.Host.

At the same time, your screenshot shows that dbo.AIManagementApplicationAIProviders and dbo.AIManagementWorkspaces already exist.

Because of that, the two strongest possibilities are:

1. HttpApi.Host is connected to a different database than the one shown in your screenshot.
2. The AI Management tables are still not included in the actual EF Core migration chain of your application.

As a quick confirmation, please go to your .EntityFrameworkCore project folder and run:

dotnet ef migrations add CheckAiManagementTables

Then check the generated migration:

• If it contains CreateTable(...) for AI Management tables such as AIManagementApplicationAIProviders, then AI Management tables are still missing from your application's migration set. In that case, apply that migration and update the database.
• If the migration is empty, then the EF Core model already contains the AI Management tables, and the stronger possibility is that HttpApi.Host is pointing to a different database.

Please also check these values in *.HttpApi.Host carefully:

• ConnectionStrings:Default
• ConnectionStrings:AIManagement

AI Management uses the AIManagement connection string name. If ConnectionStrings:AIManagement is defined, ABP uses it first. If it is not defined, it falls back to Default.

So if ConnectionStrings:AIManagement points to another database, please either:

• change it to the database that contains dbo.AIManagementApplicationAIProviders, or
• remove it so the module falls back to Default.

Since your solution is multi-tenant and uses separate tenant schema/database, please make sure you are checking the exact database used by HttpApi.Host startup, not only a tenant database.

To verify quickly, run this against the exact database used by HttpApi.Host:

SELECT DB_NAME() AS CurrentDatabase;
SELECT name FROM sys.tables WHERE name IN ('AIManagementApplicationAIProviders', 'AIManagementWorkspaces');

After checking the migration result and the connection strings, restart HttpApi.Host and test again.

If the problem still continues, please share:

• whether the new migration was empty or not
• the target database names for Default and AIManagement
• whether you are logged in as host or tenant

Best regards,

ABP Support Team

Hi,

Thanks for the details.

Based on the behavior you described, this looks more like a server-side AI Management setup/database issue than an OpenAI API issue.

The main reason is:

• The Workspaces page first loads AI Management data from your application database.
• The provider dropdown is populated from provider names registered at application startup.

So when the page throws a generic AbpRemoteCallException and the provider list is also empty, the usual cause is that the AI Management module was added but its database changes and/or startup registration were not completed yet.

In your case, the strongest clue is that the solution was created with --skip-migration --skip-migrator.

Please check these steps:

1. Create and apply a new EF Core migration after importing Volo.AIManagement. If the AI Management tables were not created yet, the /api/ai-management/workspaces request will fail with this kind of generic remote call exception.

2. Make sure Volo.AIManagement.OpenAI is installed on the server startup side of the application, not only in a UI/client project. The available providers are collected from registered factories at startup. If the OpenAI module is not loaded by the startup application, the provider dropdown will stay empty.

3. Restart the application after installing the provider package and after applying the migration.

4. Check the *.HttpApi.Host logs while opening the Workspaces page. The real exception should be written there. If the migration is missing, you will typically see the actual SQL/table-related error on the host side.

So the first thing we recommend is:

• add/apply the migration,
• restart HttpApi.Host,
• open the Workspaces page again,
• then verify whether OpenAI appears in the provider dropdown.

If the problem still continues after that, please share these details:

• the exact exception from the HttpApi.Host log,
• whether the AI Management tables were created successfully,
• and which project you added Volo.AIManagement.OpenAI to.

Best regards,

ABP Support Team

Hi,

Thanks for sharing the backend log.

The key part in your log is this exception:

IStudioHub/HeartbeatAsync -> Volo.Abp.Studio.Connectivity.StudioBackendHub.NotifyHeartbeatAsync -> System.NullReferenceException

This indicates the crash is happening inside ABP Studio's own internal monitoring/heartbeat pipeline while Studio is loading or tracking the linked applications. In other words, this does not look like an error thrown by your microservice solution itself.

We also checked the current released rel-2.2 source and the same heartbeat-forwarding path is still present there, so at the moment this looks like a Studio regression rather than a known configuration mistake in your solution.

A few important notes:

1. 2.1.4 is the last ABP Studio version mapped to ABP 10.0.1, while 2.2.x is mapped to 10.1.x startup templates.
2. However, that version mapping is mainly about newly created templates, and by itself it should not cause ABP Studio to crash.
3. Since your log shows an internal Studio NullReferenceException, the strongest evidence still points to a Studio-side bug/regression.

For now, the safest workaround is to continue using 2.1.4 for this workspace until we have a fix or a confirmed newer build that addresses it.

To move this forward, please share these additional files/details so we can reproduce and report it more precisely:

1. The full ABP Studio UI logs folder on macOS.
2. The full backend logs folder on macOS.
3. Your .abpsln file for this workspace.
4. A macOS crash report if one is generated under ~/Library/Logs/DiagnosticReports/.
5. Whether the same crash happens with the same workspace before starting Docker, and whether it also happens with a smaller solution.

Once we have those artifacts, we can continue the investigation with the Studio team.

Best regards,

ABP Support Team

Hi,

Thanks for your patience on this one.

We re-checked the current React Native / Expo template against the latest available ABP Studio template stack and compared it with the current documentation and template source.

One important clarification first: the screenshot in the ticket does not prove that ABP Studio 2.1.8 was already installed. It only shows that 2.1.8 was available as an update, so the safest conclusion is that the older report came from an earlier 2.1.x / ABP 10.0.x template line, not necessarily from 2.1.8 itself.

After re-validating the current line:

• ABP Studio 2.2.2 - 2.2.4 maps to ABP 10.1.1, and the release notes explicitly mention: "Updated React Native templates to use latest Expo/React Native standards."
• The specific blockers originally mentioned in this ticket, such as missing CreateUpdateTenant / TenantsScreen references and the normalize-css-color resolution problem, are not reproduced in the current template source or in a fresh generated solution.
• For the Web View / Expo Web scenario, the current documentation and template intentionally use the https://localhost flow for local web testing, and the generated backend/app settings include React Native-related localhost entries for that case.

So, regarding the original blockers: they do appear to be addressed in the current template line.

That said, we also do not want to overstate the current state as completely problem-free yet.

In our fresh validation:

• solution generation succeeded,
• the .NET build succeeded,
• Expo doctor and web export checks succeeded,
• yarn install succeeded,
• but npm install produced a peer dependency resolution error in our environment,
• and we also hit a TypeScript issue during a strict tsc --noEmit check.

Because of that, the most accurate status today is:

• the older template-breaking issues reported in this ticket are no longer reproducing on the current line,
• the React Native template is in a better state than before,
• but it still is not fully friction-free in every workflow yet.

If you decide to re-check it on your side, we recommend testing with the latest ABP Studio 2.2.x line and following the current React Native documentation / README flow.

If you still hit a blocker on the latest template, please send us these details and we can verify the exact case directly:

1. Your ABP Studio version
2. Whether you generated the app with ABP Studio or ABP CLI
3. Whether you used npm or yarn inside the react-native folder
4. The exact command output for the first failing step

Best regards,

ABP Support Team

Hi again,

I saw it in the internal development roadmap and plans. It's not a fully announced feature. Currently I don't have enough information for sharing any more information at the moment and it's not a mature feature currently and not clear which ABP Studio version will be affected not clear so far. You can track official roadmap and announcements.

Best regards,

ABP Support Team

Hi,

Thanks for the detailed feedback and for sharing the screenshots.

Based on the current ABP documentation and theme implementation, here is the current situation:

• ABP currently provides official theme options around Basic Theme, LeptonX Lite, and LeptonX Theme. The Basic Theme is intentionally minimal and is meant to be a good starting point if you want to build your own design on top of it.
• At the moment, we do not have a public roadmap item for a completely new lightweight theme separate from the current theme family. The public roadmap currently focuses on improving LeptonX (new layouts, styles, and components) and a theme builder rather than introducing a brand-new theme line.
• If your goal is a more modern but lighter option, LeptonX Lite is currently the closest official choice.
• For React Native / Expo, ABP's React Native support is a separate mobile startup template integrated with ABP backends. It is not based on the web themes, so Basic / LeptonX / LeptonX Lite do not directly apply to the React Native UI layer. We also do not currently have a public roadmap item for a dedicated React Native theme.

About the mobile navigation customization in your screenshots:

• Your concern is valid. In the current LeptonX mobile layout, items such as Settings, Profile, and the hamburger menu are part of the mobile navbar structure itself.
• Because of that, changes like removing Settings from the bottom bar, moving the menu button, or changing that mobile structure are generally not simple CSS customizations. They typically require component/layout replacement or source-level customization.

So, if your priority is lightweight + easier customization, the most practical options today are:

1. Basic Theme + source customization if you want maximum control and a lighter base.
2. LeptonX Lite if you want a more modern official theme with a lighter footprint than full LeptonX.
3. LeptonX with component replacement/custom layout work if you want to stay with the commercial theme and customize deeper parts of the UI.

If you want, please let us know whether your project is Angular, Blazor, or MVC / Razor Pages. Then we can suggest the most maintainable customization path for your exact stack.

Best regards,

ABP Support Team

Hi,

Thanks for the detailed report and the clear reproduction notes.

We verified that this is a real issue in ABP 10.1.1, not just a tsconfig problem.

The root cause is that, in the Angular side, ExtensibleLimitedResultRequestDto was inheriting from ExtensibleEntityDto, which brings an id?: string property. In the Identity Pro contracts, GetIdentityUsersInput also declares its own nullable Id property (Guid? on the .NET side), so the generated Angular proxy ends up with id?: string | null. Under strict TypeScript checking, that becomes an invalid interface extension because the child type is wider than the base type.

So your diagnosis is correct: the mismatch is in the ABP Angular DTO hierarchy, and strict/isolatedModules only make the existing type incompatibility visible.

We also verified that a fix has already been prepared for this case. The planned change is to make ExtensibleLimitedResultRequestDto extend ExtensibleObject instead of ExtensibleEntityDto, which removes the incorrect inherited id member from that request DTO chain. This is being tracked here:

• https://github.com/abpframework/abp/issues/25115

Until the patched package is released, the practical workaround is to keep applying the generated proxy adjustment on your side after proxy generation, for example by removing the generated id member from GetIdentityUsersInput or otherwise aligning that generated type with the fixed hierarchy.

Once the fix is included in the next relevant release, regenerating the Angular proxies should no longer produce this conflict.

You can follow the release status here:

• https://github.com/abpframework/abp/releases
• https://abp.io/docs/latest/release-info/release-notes

Best regards,

ABP Support Team

Hi,

Thanks for the detailed screenshots.

This does not look like a normal usage mistake on your side. For the Angular module installation generated with ABP Studio 2.1.4, there was a template issue in the generated Angular integration.

From your screenshots, we can see that:

• the RagEngine menu item is created,
• the route is added in app.routes.ts,
• the generated component calls RagEngineService.sample() when the page opens,
• after login, the page ends with a 404.

The important point is that the login redirect itself is expected when the route is protected. The actual problem is the 404 that happens after that.

For this template, the Angular side should use these values:

1. The rag-engine route should include canActivate: [authGuard].
2. The generated Angular service should call /api/rag-engine/example instead of /api/rag-engine/sample.

This issue has already been fixed in newer ABP Studio templates, starting from 2.1.5.

So, for your existing solution, please do one of these:

• update ABP Studio to 2.1.5 or later and regenerate/reinstall the module,
• or apply the same corrections manually in the existing project.

Also, please make sure the Angular library import used in app.routes.ts is still resolvable from angular/tsconfig.json, and that the module's config provider is still registered in app.config.ts. Those entries are normally added automatically during installation.

If it still does not work after that, please share these 3 items and we can check the remaining difference directly:

1. the rag-engine route entry from angular/src/app/app.routes.ts,
2. the sample() method from modules/ragengine/angular/projects/rag-engine/src/lib/services/rag-engine.service.ts,
3. the exact failing request URL and status from the browser Network tab.

Best regards,

ABP Support Team