Activities of "AI-Bot"

• The fix referenced in #10853 (implemented by PR #26017) was not released in 10.6.1.

• Based on the available verified information, it was scheduled for “an upcoming release” at the time of the #10853 answer, but the exact version (e.g., 10.6.2/10.6.3 vs 10.7.0+) is not explicitly stated in any verified source I can access here.

• Since you can still reproduce “session never saved when the client disconnects” on 10.6.1, the safe/confirmed conclusion is: it is not included in 10.6.1; the earliest version containing it cannot be definitively confirmed from verified sources in this environment.

• Practically: if you need a deterministic server-side behavior today, your current mitigation of adding /connect/token to AbpAspNetCoreUnitOfWorkOptions.IgnoredUrls (or equivalent “commit-before-flush” approach) is consistent with the framework-side fix described in #10853, and you should keep it until you upgrade to a version where you can confirm the fix is present by testing.

Links (validated):

• https://abp.io/support/questions/10853
• https://github.com/abpframework/abp/pull/26017

This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

Please contact us at https://abp.io/contact.

This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

Please contact us at https://abp.io/contact.

This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

• The Unexpected token '<', "<!doctype "... is not valid JSON error means the MCP tool call is receiving HTML instead of JSON. In practice (for ABP CLI/Studio), this typically happens when the underlying ABP backend endpoint returns an HTML error/login/forbidden page rather than the expected JSON payload.
• For the ABP MCP server tools, the most common trigger for HTML responses is authentication/session/license state in ABP CLI/Studio being invalid/expired, so the server-side returns an HTML page (e.g., 403/redirect) and the client tries to parse it as JSON.
• Fix steps (do these exactly):
  1. Update ABP Studio CLI (you already have 3.1.6; keep it updated):

dotnet tool update -g Volo.Abp.Studio.Cli

2. Re-authenticate ABP CLI (this resets the auth tokens used by ABP’s remote services that MCP relies on):

abp logout
     abp login

3. Restart the MCP server process / reconnect it in Claude after login.

• If you still get empty responses for the “relevant docs/articles/support questions” tools after re-login: that indicates the MCP server still can’t access its backend data sources (typically the same auth issue). Re-check step (2) and ensure the abp login actually succeeds in the same environment/user that Claude is launching abp mcp from.

Sources:

• https://abp.io/support/questions/3757
• https://abp.io/docs/10.7/cli/

This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

• ABP’s React UI (modern templates) keeps the selected tenant id in sessionStorage under abp_tenant_id and sends it to the backend with the __tenant HTTP header on requests. So, if your MCP server is a custom, separate “streamable HTTP” endpoint, ABP AI Workspace does not automatically forward the current tenant to that external MCP server unless you explicitly implement such forwarding in your MCP server integration.
• Therefore, to use the current tenant inside your custom MCP server, you should read it from the incoming request header __tenant (or, if you are calling your MCP server from your React app directly, make your client include __tenant header using the value from sessionStorage['abp_tenant_id']).

Practical approach (custom streamable HTTP MCP server)

1. Expect this header on your MCP server:

   • __tenant: <tenantId> (GUID as string)

2. In ASP.NET Core (example), read it like:

app.MapPost("/mcp", async (HttpContext httpContext) =>
{
    var tenantId = httpContext.Request.Headers["__tenant"].ToString(); // may be empty for Host
    // use tenantId in your logic
});

3. If the MCP server is called from your React UI, add __tenant header from:

• sessionStorage.getItem("abp_tenant_id")

Sources

• https://abp.io/docs/10.5/framework/ui/react/permission-management (validated)
• https://abp.io/docs/10.2/modules/ai-management (validated)

This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

• What you’re observing in @volo/abp.commercial.ng.ui 10.7.0 is consistent with the original regression: the lookup component still has a signal-driven disabled input mirrored via an effect(...), and the inherited setDisabledState(...) path still doesn’t trigger view refresh (markForCheck()), so a reactive-forms disable can be lost/overwritten.
• Based on the only verifiable support information available (the original ticket thread), ABP support first stated “the fix will be included in 10.7”, but later clarified: “We’ll fix this in a future release.” There is no verified public info (release note / commit / tag) that specifies which exact version after 10.7.0 contains the permanent fix.

What you should do now (until the permanent fix is released)

1. Keep using one of these workarounds:

   • Template workaround: bind [disabled] to the form/form-control disabled state.
   • Or the main.ts prototype patch from ticket #10904 (the one that merges _inputDisabled + _formDisabled and calls cdRef.markForCheck() in setDisabledState).

2. Open a new support ticket (as you did) and reference that:

   • You’re on 10.7.0 and the issue persists.
   • The published bundles still contain the effect(() => this.disabled = this.disabledInput()) behavior and setDisabledState still doesn’t markForCheck().
   • The main.ts patch from #10904 still fixes it. This will allow the ABP team to link it to their internal issue tracker and respond with the planned patch version (e.g., 10.7.1 / 10.7.2 / 10.8).

Sources (validated)

• https://abp.io/support/questions/10904/Regression--setDisabledState-reactive-forms-disable-no-longer-works-on-Lookup-components-after-upgrading-from-1011-to-1061

This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

• In ABP Blazor WASM/WebApp, the client-side localization is resource-based and module-based, and each module typically embeds a set of JSON files for many cultures under its virtual file system (VFS). When the WASM client decides it needs a given localization resource, it pulls the resource’s JSON files exposed by the host. That’s why you see “module localization texts” as a big chunk of startup time, and why it repeats on each F5 (because the WASM runtime/app is restarted and re-initializes its localization store).

• ABP’s localization fallback rules are indeed culture-based (requested culture → base culture → default culture, etc.). Those fallback rules are documented, but they do not imply the framework will only download those cultures; it only implies how a key is resolved once the relevant dictionaries are present.
  So, your understanding of fallback is correct, but the current loading strategy is not “download only what’s required for fallback”.

• As of the verified ABP docs available here, there is no documented/supported option that tells the Blazor WASM client to “only download the cultures configured in the application + fallbacks” for module-provided virtual JSON localization files. (So there’s no officially documented switch I can point you to that changes this behavior in 10.7.)

• Practical mitigations you can apply without changing ABP internals:

  1. Reduce the number/size of shipped localization JSONs in your own application/modules (obvious, but it’s the only fully supported lever).
  2. Prefer server-provided localization where possible (in a WebApp, SSR happens first; WASM then fetches configuration/culture afterwards). This doesn’t eliminate the need for client localization entirely, but it can reduce what must be ready before first interaction, depending on your UI structure.
  3. Measure whether you are loading localization resources earlier than necessary (e.g., during module init rather than on-demand at first use). If you can defer certain modules/components, you may defer their localization cost as well.

• For the other startup costs you listed (resource-collection.js, generate-proxy.json, etc.), those are separate pipelines (static asset discovery and dynamic proxy metadata). The “load everything each F5” characteristic is normal for an Interactive WASM app because the browser refresh restarts the app; caching helps network, but not parsing/processing/DI initialization time.

Sources (validated)

• https://abp.io/docs/10.7/framework/fundamentals/localization
• https://abp.io/docs/10.7/framework/fundamentals/url-based-localization

This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

• LimitedResultRequestDto is an ABP Framework type and it should come from the Volo.Abp.Application.Dtos namespace (same place as PagedResultRequestDto).
• In ABP 10.7, PagedResultRequestDto inherits from LimitedResultRequestDto (so Suite templates referencing LimitedResultRequestDto is consistent with the framework DTO hierarchy).

What to do in your solution (ABP 10.7.0):

1. Ensure your projects reference the correct ABP package(s)

   • The DTO base classes (LimitedResultRequestDto, PagedResultRequestDto, etc.) come from ABP’s application contracts layer packages (transitively or directly).
   • Make sure the project where the template is compiled (typically *.Application.Contracts and/or *.TestBase / *.Tests) references ABP 10.7.0 packages consistently (no mixed versions).

2. Clean and restore to eliminate stale assemblies

   • Delete bin/obj for the solution (or run dotnet clean + delete bin/obj).
   • Run dotnet restore
   • Rebuild the whole solution.

3. If you still can’t compile because the type is missing

   • That indicates your solution is not actually resolving the ABP 10.7 assemblies that contain the DTOs (e.g., package downgrade, pinned central package version, or inconsistent package graph).
   • Fix by aligning all Volo.Abp.* package versions to 10.7.0 (including test projects).

Reference (contains the LimitedResultRequestDto and shows its relationship to PagedResultRequestDto / PagedAndSortedResultRequestDto):

• https://abp.io/docs/10.7/framework/architecture/domain-driven-design/data-transfer-objects

This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

• What you’re seeing is coming from the Angular proxy generator trying to translate some problematic server-side types that the AI Management module exposes in its HTTP API contract (via /api/abp/api-definition?includeTypes=true). In ABP 10.7, those types end up producing invalid TypeScript in the generated models.ts files:

  • Duplicate / conflicting ActionResult declarations (non-generic + generic with the same name).
  • ChatRole being emitted as interface ChatRole extends any, which is invalid TypeScript.

• There isn’t a supported switch to say “keep module backend/UI functionality but don’t generate its client-side types when I run the default abp generate-proxy -t ng”. The supported approach is to generate proxies per module when you need them, instead of generating everything into the main app proxies.

• Supported workaround (recommended): generate only the AI Management proxies separately

  1. Remove (or revert) the broken generated proxies in your main app proxy folder (since they are already invalid TS).
  2. Generate only AI Management proxies using the module-scoped command:

abp generate-proxy -t ng --module aiManagement

 This is the documented way to generate the AI Management module’s Angular services/models.

• If you want to avoid pulling AI Management contracts into your default app proxy output, keep using the default generation for your app module:

abp generate-proxy -t ng --module app

and generate AI Management only when/where you need it using the --module aiManagement command above.

• If you must generate everything in one shot (single proxy tree), then the only reliable workaround is manually fixing the generated TypeScript after generation (but that is not a stable/supported workflow because regeneration will overwrite).

Sources (validated)

• https://abp.io/docs/10.7/modules/ai-management/
• https://docs.abp.io/en/abp/latest/UI/Angular/Service-Proxies

This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

• Issue 1 (z-index / MatDialog overlay): abp-modal is implemented on top of ng-bootstrap’s NgbModal, which appends ngb-modal-window / ngb-modal-backdrop to document.body. When your app (or theme) sets .cdk-overlay-container { z-index: 10000 !important; } and ng-bootstrap modal/backdrop stays at a lower z-index (e.g., 9999), the modal will render behind the CDK overlay stack.
  Supported ABP-side workaround (no need to fork ABP): pass windowClass / backdropClass via the [options] input (ABP spreads options() into NgbModal.open(...)), then override z-index globally.

<abp-modal
    [(visible)]="openViewDocument"
    [options]="{
      windowClass: 'abp-above-cdk',
      backdropClass: 'abp-above-cdk-backdrop'
    }"
  >
    <ng-template #abpBody>...</ng-template>
  </abp-modal>

Put the CSS in a global stylesheet (recommended), so you don’t need ::ng-deep:

ngb-modal-window.abp-above-cdk { z-index: 10001 !important; }
  ngb-modal-backdrop.abp-above-cdk-backdrop { z-index: 10001 !important; }

Notes:

• Using a component-scoped stylesheet forces you into ::ng-deep because the modal elements are not inside the component’s DOM tree (they’re appended to body).

• Your current CSS values confirm the root cause: 9999 < 10000, so it will always lose against .cdk-overlay-container.

• Issue 2 (contentChild('abpBody') + *ngIf on <ng-template>): In ABP 10.6, abp-modal uses Angular’s signal-based contentChild('abpBody'). That query will not reliably find a template reference that is structurally wrapped (like <ng-template *ngIf ... #abpBody>), because *ngIf on an <ng-template> creates an additional outer template layer.
  Fix in application code: keep exactly one projected <ng-template #abpBody> and move conditional logic inside it (as you already did):

<abp-modal [(visible)]="showModal">
    <ng-template #abpBody>
      <app-edit-form *ngIf="isEditMode"></app-edit-form>
      <app-view-only *ngIf="!isEditMode"></app-view-only>
    </ng-template>
  </abp-modal>

This pattern aligns with how ABP’s modal is documented/used (single #abpBody template projected into the component).

• About your requested ABP changes (what is verifiable from sources):
  • From the ABP Angular modal docs, the modal is expected to be used by projecting #abpHeader/#abpBody/#abpFooter templates (single templates) into <abp-modal>. Your “two #abpBody templates toggled by *ngIf” is not a documented usage pattern, and it becomes fragile with signal-based content queries.
  • There is no verified, official ABP documentation (in the retrieved sources) that mentions a zIndex input, container option, or a migration note specifically about contentChild() + *ngIf on <ng-template #abpBody>.

Sources (verified)

• https://abp.io/docs/latest/framework/ui/angular/modal
• https://github.com/abpframework/abp/blob/dev/npm/ng-packs/packages/theme-shared/src/lib/components/modal/modal.component.ts
• https://github.com/abpframework/abp/tree/dev/npm/ng-packs/packages/theme-shared

This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.