When deleting a user, that user should not appear in the re-assign articles drop-down

[jools-r]

Expected behaviour

On the Admin › Users panel, when deleting a user with articles, you are asked to reassign those articles to another user. I expect to see only other users in the "Select author drop-down".

Actual behaviour

As above but you still the user you are about to delete in the user drop-down.

If you go through and choose "Go", the error is thankfully trapped and you get the error “You cannot assign assets to a deleted account”. As such the "bug report" is only a cosmetic problem. See screenshot below.

Steps to reproduce

• Set up txp
• Add a new user
• Duplicate the start article, set to live and assign to the new user name
• Visit Admin › Users, place a checkmark in the box next to the new user, and choose "Delete" from the multi-action choice menu at the bottom. The “re-assign to another user” dropdown still includes the user that is about to be deleted.

Additional information

Textpattern version: 4.8.8

Web server vendor and version: Apache + nginx

Database server vendor and version: 8.0.30

PHP version: 8.1.9

Operating system: Linux / Darwin

Thanks to @uli-on for spotting it and reporting it.

[Bloke]

This is one of those tricky ones. When the page is built, the drop-down is built with it containing all known users. There's no knowlege of which checkboxes you'll select, what search terms you'll use to filter the list, yahde yahde.

So when you click one or more users we'd have to go through the drop-down and remove them. Then if you uncheck the user, we'd have to go and put that one back in the list. With thousands of users, that's probably going to slow things down considerably - and I've seen sites with that many users. It's bad enough waiting for it to populate the page in the first place and find the user you want to reassign from the huuuuge list in the drop-down, let alone waiting for the interface to dynamically alter the drop-down entries.

I've never thought of a decent way to handle this. Maybe @bloatware has some ideas?

[jools-r]

That's a pretty convincing explanation. I guess 95 is probably the most users you'll be able to select at once if you extend pagination to 96 so maybe that limits it a little bit, but I get what you say.

A really wild guess without having thought it through: might one be able to leverage css here? Something like when a checkbox is set/unset for a user, a corresponding class is set/unset that controls the hide/show display of the item in the drop-down. The dropdown wouldn't need rebuilding dynamically, it would just be classList.add / .remove. That would get most computationally expensive when choosing the tick box for "all users" – which is a possible but probably also relatively rare occurrence.

[bloatware]

Altering a drop-down list via JS should be fast enough, but we'd better do it properly, e.g. not on users (un)check but on selecting 'Delete' option. And since some other actions/tabs (like reassigning the parent category) would benefit from this feature too, we'd need to enhance the multi-edit widget with some general mechanism.

[Bloke]

If we can build some cool generic behaviour into the multi-edit tool to handle situations where we want to post-modify the content that'd be ace.