Problem adding Substitute User when large number of Users

I’m trying to add a Substituted User through the standard User screen, but it doesn’t work as expected when there are a large number of users.

In our system, we have about 50,000 users. The input box to select the substituted user seems to only load the first 10,000 users. If I start typing a valid login name, it works for some users (I guess in the first 10k), but doesn’t find others.

Is there any way I can work around this issue?

ps. Cuba 7.1

Here’s some screenshots that show an example of the problem.

First, if I just lookup the users in the User browser, I can find them:


But if I search for the same string when adding a Substitue User, it doesn’t find them:



Hi @rcolley,

I think there are some alternatives to workaround this problem:

  1. Increase cuba.defaultMaxFetchUI property value. As you noticed, default queries are limited to 10k records by default. You can increase this number if needed. But I suggest you consider other options, because you’ll probably have performance issues (especially with the generic filter).


  1. Use Entity Inspector instead of default user substitution screen. This screen do not uses a dropdown, so there is no problem with the 10k limit. This solution is feasable if only your application admins will update substitution information.
  • Administration >> Entity Inspector

  • Select User entity

  • Search / Edit the user you want to add a new substitution. Use the Substitutions tab.

  1. Extend User Substitution screen OR create a new screen to maintain user substitution (obsviously this screen should not use a dropdown to select users).

P.S.: I suggest you take a look at Entity Statistics. You’ll have the same problem when selecting users in the generic filter, so you’ll probably need to configure cuba to not use dropdown for users.

Hope it helps.



Thanks for the workarounds.

To Haulmont, would this be something a future release of cuba could address. When user input is received in the pick list, re-lookup the db to get the matches. That way the limit of 10,000 could be applied each time, on a smaller candidate list.

Thanks for pointing out the problem.
I’ve created a github ticket:

1 Like