Browser hangs when selecting a lot of users in admin-settings

[tschiebel]

Error description

Browser hangs.

Steps to reproduce

Steps to reproduce the behavior:

• All 1239 users of a instance (0183) selected.
• Edit login as batch.
• Attempt to select "NO

Expected behavior

All users can be deactivated by batch.

Actual behavior

All users were selected after a long wait. However, the NO could not be clicked.

Additional context

Epic says that the deployment is not yet complete, but the feature is available and also usable:
With smaller number (class with about 30 users) you could do the batch processing to deactivate and also to activate the login.

Comment

Browser crashes are annoying, but here the system was really challenged. However, I suspect that the instance 0183 itself (i.e. not only my browser frontend) was also damaged by this, because uploads of files failed afterwards (message for this is "unknown error"). The two screenshots with the filename Screenshot*.png in the attachment of this ticket could not be uploaded on 0183 anymore. The upload on instance 0146, on the other hand, worked.

[micbar]

@kulmann @janackermann we need to see what is feasible.

[JammingBen]

We re-fetch each user after the operation to ensure the data is up to date with the server. We could skip that, which would reduce the amount of outgoing requests by half. Instead we could simply re-load the users list. The only drawback I see here: the current selection gets lost. @kulmann What do you think?

Edit: Nevermind, I think I misunderstood the issue. The issue is that the options in the dropdown are not selectable because the browser hangs, right? The screenshots are way to small to see anything unfortunately.

[kulmann]

@JammingBen we also fetch each user individually (because we need to expand the drive data) upon selection. So things are going crazy even before any batch action is triggered.

Currently thinking about limiting the number of listed users to some amount (100? 200?) and enforce filtering with this. Maybe even show an empty list until filters have been applied.

[JammingBen]

True... although it makes me wonder why the dropdown-selection in the modal does not work after all users have been selected successfully 🤔 Either way, 1000+ rows per page without any pagination or lazy loading probably break the page under any circumstance.

[AlexAndBear]

Exactly, we've talked a long while ago about server-side pagination, but not been implemented...

Client-side pagination is the way to go for now IHMO

[tbsbdr]

yes, lets try a client side pagination / limit as temporary workaround with 200 max selected items.

[AlexAndBear]

@tbsbdr does this applies to all tables in admin-settings-app ? I vote for yes

[kulmann]

@tbsbdr does this applies to all tables in admin-settings-app ? I vote for yes

Yes, please in a consistent way for all three that we have.

[AlexAndBear]

@tbsbdr talked with involved web team members -> 50 items per page seems to be quite reasonable

[JammingBen]

Not technically fixed, but mitigated by #9119, so I'm closing here.