Activities of "sserestyen"

[maliming] said: Hi,

The fix will be included in 10.7. Until you upgrade, you can keep the workaround code in main.ts.

Thanks

Hi,

Thanks for the info. I'll close this ticket, as I can confirm the recommended workaround in the main.ts works as expected.

Thanks, S.

Hi,

Thanks for the response. Just wondering if you know in which version it will be fixed?

Thanks, S.

[AI-Bot] said:

• What you’re seeing is consistent with a real regression introduced by the signal-based disabled input mirroring in the newer lookup/picker components: setDisabledState(true) (CVA-driven) sets the plain disabled property, but the component’s effect(() => this.disabled = this.disabledInput()) can overwrite it back to the input value (default false) and/or prevent the view from reflecting the CVA change as expected under OnPush.
• In other words, CVA disabled state and [disabled] input are no longer merged, and the input-signal wins.

Solution

Recommended workaround (works today, no library patch required): bind [disabled] to the FormControl disabled state.

Example:

<abp-lookup-select 
  formControlName="countryId" 
  [disabled]="form.get('countryId')?.disabled ?? false" 
  [getFn]="service.getCountryLookup" 
  displayNameProp="name"> 
</abp-lookup-select> 

If you disable/enable the whole form, you can bind to form.disabled instead:

<abp-lookup-select 
  formControlName="countryId" 
  [disabled]="form.disabled" 
  [getFn]="service.getCountryLookup" 
  displayNameProp="name"> 
</abp-lookup-select> 

What an ABP-side fix should look like (for the ABP team / if you patch with source):

• The component must not continuously overwrite disabled from disabledInput() in an effect.
• It should instead merge both sources of truth, e.g. keep two fields:
  • inputDisabled (from [disabled])
  • cvaDisabled (from setDisabledState)
  • expose disabled = inputDisabled || cvaDisabled (and ensure change detection updates)
• Or, treat the input as the “initial value” only and let setDisabledState take over when used via forms.

Known issue / planned fix

I can’t verify (from the indexed support KB/docs available to me) an official ABP issue entry or release note explicitly acknowledging this specific regression in AbstractLookupSelectComponent / lookup components’ CVA disabling behavior. So I can’t definitively confirm whether it’s already tracked internally or which patch version will contain the fix.

(Practically, given your root-cause analysis, it’s very likely unintended—because it breaks standard Angular ControlValueAccessor expectations.)

If you have a commercial support channel, I recommend opening a ticket referencing:

• the exact constructor snippet you posted (disabledInput = input(false...), effect(...))
• the statement: “CVA setDisabledState is overwritten by signal input effect; should be merged”

Reference (component API still documents disabled input)

• https://abp.io/docs/10.6/framework/ui/angular/lookup-components

---

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.

Could this be reviewed by the support team?

Summary: After upgrading @abp/ng.core and @volo/abp.commercial.ng.ui from v10.1.1 to v10.6.1 (Angular v21 → v22), components that extend AbstractLookupSelectComponent (e.g. abp-lookup-select, likely also abp-lookup-typeahead, abp-lookup-typeahead-mtm, and the date/datetime pickers) no longer respect the disabled state set programmatically via Angular Reactive Forms (FormControl.disable() / FormGroup.disable()). Previously this worked correctly in 10.1.1.

Environment:

Angular: 22.1.7 @abp/ng.core: upgraded 10.1.1 → 10.6.1 @volo/abp.commercial.ng.ui: upgraded 10.1.1 → 10.6.1

Steps to reproduce:

1. Bind an abp-lookup-select (or similar lookup/picker component) to a FormControl via formControlName in a reactive form, without an explicit [disabled] template binding.
2. Call formGroup.get('xyz').disable() (or formGroup.disable()) programmatically.
3. Observe that the lookup component's disabled visual/functional state does not update — it remains enabled, even though Angular's ControlValueAccessor.setDisabledState() is being called with true.

Expected behavior: The component should become disabled, matching the behavior in 10.1.1, consistent with the standard Angular ControlValueAccessor contract.

Root cause (identified by comparing the published 10.1.1 vs 10.6.1 bundles):

• AbstractNgModelComponent.setDisabledState(isDisabled) is unchanged between versions — it still does this.disabled = isDisabled;.
• However, in 10.6.1, AbstractLookupSelectComponent's constructor now contains:

this.disabledInput = input(false, { alias: 'disabled' });
this.disabled = false;
effect(() => { this.disabled = this.disabledInput(); });

This mirrors the new signal disabledInput into the plain disabled property used by the template ([abpDisabled]="disabled"). Because disabledInput only reflects the template-bound [disabled] input (not CVA state), and the component is OnPush, the plain property assignment made by setDisabledState() is no longer reliably reflected in the rendered template — it's effectively disconnected from/overwritten relative to the signal-driven effect().

• In 10.1.1, disabled was a plain @Input() property, so setDisabledState()'s direct mutation was picked up normally by change detection.

This appears to be an unintended side effect of migrating these components to Angular signal inputs, rather than a documented/intentional breaking change — setDisabledState() itself was not modified, suggesting CVA-driven disabling was meant to keep working.

Current workaround: Explicitly bind [disabled]="expression" in the template to mirror the control's disabled condition, instead of relying solely on FormControl.disable().

Request: Please confirm whether this is a known issue, and whether a fix is planned to restore ControlValueAccessor.setDisabledState() support for lookup/picker components without requiring an explicit [disabled] template binding.

Thanks, S.

Thanks for your response. I'll look into these, and if none of these solve the issue I will provide more details.

Thanks, S.

Hi,

Using APB.IO v9.1.2 and when navigating to the Identity Management and either Roles or Users page in Angular project, it gets the data from the backend as I can see it in the chrome dev tools but the data is not displayed in the data table. Only when I resize the chrome window. The same happens when I sort the data via clicking on one of the columns.

Is this a known issue with this version (v9.1.2)?

Thanks, S.

Hi,

That's great, thanks for providing the example.

Thanks.

Hi,

Using the commercial license with Angular frontend. For those dropdown lists where we get the list of items from the API we use the abp-lookup-select component.

Just wondering if there is a similar component for working with enum-s?

e.g. given below enum

import { mapEnumToOptions } from '@abp/ng.core';

export enum GeometryTypeEnum {
  None = 1,
  Point = 2,
  Line = 3,
  Polygon = 4,
  All = 5,
}

export const geometryTypeEnumOptions = mapEnumToOptions(GeometryTypeEnum);

Thanks.

Hi,

Thanks for providing these details.

Thanks.

Hi,

We use the commercial license with version 10.1.1, and using Angular as the frontend. How can we customize the ResetPassword page for Angular, to keep the current functionality, but to add a link to the ForgotPassword page?

Thanks.