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?

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,

That's great, thanks for providing the example.

Thanks.

Hi,

Thanks for providing these details.

Thanks.

Hi,

please use below code in a new project.

using System;

using System.Linq;

using System.Threading.Tasks;
 
using Microsoft.AspNetCore.Identity;

using Microsoft.Extensions.Options;
 
using Volo.Abp.Application.Dtos;

using Volo.Abp.Authorization.Permissions;

using Volo.Abp.Caching;

using Volo.Abp.EventBus.Distributed;

using Volo.Abp.Identity;

using Volo.Abp.Threading;
 
namespace Test.Identity;
 
public class MyIdentityUserAppService : IdentityUserAppService

{

    public MyIdentityUserAppService(

            IdentityUserManager userManager,

            IIdentityUserRepository userRepository,

            IIdentityRoleRepository roleRepository,

            IOrganizationUnitRepository organizationUnitRepository,

            IIdentityClaimTypeRepository claimTypeRepository,

            IdentityProTwoFactorManager twoFactorManager,

            IOptions<IdentityOptions> identityOptions,

            IDistributedEventBus eventBus,

            IOptions<AbpIdentityOptions> abpIdentityOptions,

            IPermissionChecker permissionChecker,

            IDistributedCache<IdentityUserDownloadTokenCacheItem, string> userDownloadTokenCache,

            IDistributedCache<ImportInvalidUsersCacheItem, string> importInvalidUsersCache,

            IdentitySessionManager sessionManager,

            IdentityUserTwoFactorChecker userTwoFactorChecker,

            ICancellationTokenProvider cancellationTokenProvider)

            : base(

                userManager,

                userRepository,

                roleRepository,

                organizationUnitRepository,

                claimTypeRepository,

                twoFactorManager,

                identityOptions,

                eventBus,

                abpIdentityOptions,

                permissionChecker,

                userDownloadTokenCache,

                importInvalidUsersCache,

                sessionManager,

                userTwoFactorChecker,

                cancellationTokenProvider)

    {

    }
 
    public async Task<PagedResultDto<LookupDto<Guid>>> GetDummy(LookupRequestDto input)

    {

        var users = await UserRepository.GetListAsync();
 
        var items = users.Select(ObjectMapper.Map<IdentityUser, LookupDto<Guid>>)

                .OrderBy(u => u.DisplayName)

                .ToList();
 
        return new PagedResultDto<LookupDto<Guid>>(items.Count, items);

    }

}
 

See below AutoMapper configuration below:

CreateMap<IdentityUser, LookupDto<Guid>>()
            .ForMember(
                d => d.DisplayName,
                m => m.MapFrom(s =>
                    s.Name + " " +
                    s.Surname + " (" +
                    s.UserName + ")"));
 

Thanks, S.

Hi,

I have the log only at the moment. See below:

Thanks.

[sserestyen] said:

[sserestyen] said:

Hi,

I don't have any CronExpression in my project, apart from the ones which comes with the pro packages.

As I don't have access to its source code I cannot verify those.

What kind of workers and cron expressions do we have with the pro packages?

Thanks.

Hi,

I came across with related support tickets, and found that ExpiredAuditLogDeleterOptions can be configured.

But, even though I change its default CronExpression ("0 23 * * *") to below, which should be valid for Quartz, I still get the same exception.

Configure<ExpiredAuditLogDeleterOptions>(options =>

{

options.CronExpression = "0 0 23 ? * * *";

});

Could you advise what else needs to be change to work with Quartz?

Thanks.

Hi,

Just an update, I was able to get around it. It turns out that I needed to apply both of below settings, as their default values were not compatible with Quartz.

Configure<ExpiredAuditLogDeleterOptions>(options => { options.CronExpression = "0 0 23 ? * * *"; });

Configure<AuditLogExcelFileOptions>(options => { options.ExcelFileCleanupOptions.CronExpression = "0 0 23 ? * * *"; });

Based on the documentation those original values are not compatible with Quartz https://abp.io/docs/latest/modules/audit-logging-pro#expiredauditlogdeleteroptions

Also, the below is not correct on the documentation options.ExcelFileCleanupOptions.CronExpression = "0 23 * * *"; // Quartz Cron expression is "0 23 * * * ?"

The original cron is "0 23 * * *", which is "every day at 23:00", but Quartz Cron expression is "0 23 * * * ?" would mean every hour 23 mins. The correct configuration for Quartz Cron Expression is "0 0 23 ? * * *", which is identical with the original config.

Could this be highlighted in the documentation of Quartz integration?

Thanks.

[sserestyen] said: Hi,

I don't have any CronExpression in my project, apart from the ones which comes with the pro packages.

As I don't have access to its source code I cannot verify those.

What kind of workers and cron expressions do we have with the pro packages?

Thanks.

Hi,

I came across with related support tickets, and found that ExpiredAuditLogDeleterOptions can be configured. But, even though I change its default CronExpression ("0 23 * * *") to below, which should be valid for Quartz, I still get the same exception.

Configure<ExpiredAuditLogDeleterOptions>(options => { options.CronExpression = "0 0 23 ? * * *"; });

Could you advise what else needs to be change to work with Quartz?

Thanks.