Opened 13 years ago
Closed 13 years ago
#20769 closed enhancement (duplicate)
User Delete fails with large groups of users
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | minor | Version: | |
Component: | Users | Keywords: | |
Focuses: | Cc: |
Description
In the process of deleting users, an admin is faced with a choice of either deleting all their content or reassigning it to another user. Unfortunately to create this interaction on larger installs, a massive select list is created.
In my local development environment, I have a small subset (about 60K users) of our production user base, which generates 3.3MB of markup. If you attempt to use the list, Chrome locks up.
Our production database has considerably more users and just fails to generate the list at all.
So, somewhere before 60K, this option becomes unusable, and somewhere after that, causes the entire delete operation to fail.
I have commented out the reassignment form option in our production code to allow user deletion, however, I would like to be fully on core, and I can't imagine I'm the only person to hit this issue. I think there are a few ways to make this happen. Please let me know which one would be the most agreeable and I would be happy to patch it.
- Leave the reassignment option, but push to a second page to choose the user. This would leave the reassignment failure as an open bug but allow the basic delete functionality to be unencumbered.
- Leave the reassignment option, but provide a numeric entry to indicate the user ID to push content to.
- Hide the option when users over an arbitrary limit.
- Make the user listing more intelligent, choosing the same group. Similar to 3, if a limit is reached, hide the option. If you had a large pool of commenters and a small pool of authors, it would allow you to reassign an author's content to another author, but you couldn't reassign a commenter's content were the pool too large.
Thanks,
-Kenton
Yes, dropdowns cause multiple issues when there are many users. Going to close this as duplicate of #19867