Activities of "sserestyen"

[maliming] said: Hi,

The fix was merged one day after 10.7.0 was published, so it missed that release. It will be in 10.7.1, which we plan to release next week.

Until then, keep the workaround in main.ts. Remove it after upgrading to 10.7.1.

Sorry for the confusion. Your ticket has been refunded.

Thanks

Ok, thanks for confirming it.

S.

Could the support team confirm when that issue will be fixed?

Thanks, S.

Hi,

This is a follow-up to ticket https://abp.io/support/questions/10904/Regression--setDisabledState-reactive-forms-disable-no-longer-works-on-Lookup-components-after-upgrading-from-1011-to-1061, where the fix was confirmed for version 10.7.

After upgrading both @abp/ng.core and @volo/abp.commercial.ng.ui to 10.7.0, I removed the recommended temporary workaround. However, abp-lookup-select still remains enabled when its reactive FormControl is initialized as disabled or disabled programmatically.

The installed 10.7.0 bundles still contain:

An effect in AbstractLookupSelectComponent that overwrites disabled with disabledInput(). An inherited setDisabledState() that only assigns this.disabled, without calling markForCheck(). Restoring the workaround from https://abp.io/support/questions/10904/Regression--setDisabledState-reactive-forms-disable-no-longer-works-on-Lookup-components-after-upgrading-from-1011-to-1061 resolves the issue.

Could you please investigate and confirm which release will include the fix? I’m opening a new ticket because I cannot reopen the original.

Thanks, S.

[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.