[Bug]: Administrative Account Page hangs when having many (ldap-)groups

[someone-somenet-org]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

During testing the migratability of a bigger owncloud instance to nextcloud i encountered an issue that the Administrative Account Page will not load, in the form that the tab will hang indefinitely or crash.

It seems that something goes awry with "too many" groups.

(10000 LDAP/AD-users, 15000 LDAP/AD-groups and 10 local-db-users, 500 local-db-groups; most of which are dead/inactive)

Steps to reproduce

1. Have 10000 LDAP/AD-users, 15000 LDAP/AD-groups + 10 local-db-users, 500 local-db-groups
2. Open https://.../index.php/settings/users
3. Tab hangs or crashes.

Disable LDAP-Groups (set group filter to for example (&(|(objectclass=groupp))))

1. Have 10000 LDAP/AD-users, 0 LDAP/AD-groups + 10 local-db-users, 500 local-db-groups
2. Open https://.../index.php/settings/users
3. Tab loads after a while.

Expected behavior

The Tab to load always.

Nextcloud Server version

30

Operating system

RHEL/CentOS

PHP engine version

PHP 8.2

Web server

Apache (supported)

Database engine version

MySQL

Is this bug present after an update or on a fresh install?

None

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Additional info

No response

[oculos]

I can confirm that I have the same issue. If I remove group configuration, things work fine. If I ender an ldap query for groups, the admin interface hangs when browsing to the accounts view.

[come-nc]

After looking into it, the group list is not paginated at all, it’s loaded entirely before the template is rendered to populate the left sidebar group list.

So indeed this cannot scale if there are 15000 groups, whether LDAP or another backend.
The groups API have the same possibilities than the user one so I suspect this to be fixable mostly on frontend side.

But it’s not clear how to fix that properly from a design perspective, because with that many groups one needs to be able to search them by name rather than browsing pages. But as a first fix, limiting initial listing to less than 100 groups would be a first step to make the page usable again.

[sorbaugh]

After looking into it, the group list is not paginated at all, it’s loaded entirely before the template is rendered to populate the left sidebar group list.

So indeed this cannot scale if there are 15000 groups, whether LDAP or another backend. The groups API have the same possibilities than the user one so I suspect this to be fixable mostly on frontend side.

But it’s not clear how to fix that properly from a design perspective, because with that many groups one needs to be able to search them by name rather than browsing pages. But as a first fix, limiting initial listing to less than 100 groups would be a first step to make the page usable again.

Hi @marcoambrosini , I think we would require a bit of your expertise here

[marcoambrosini]

I think it's more of a question for @skjnldsv

From a design perspective this should be just like files, with a search bar as a first element on top of the navigation.