[wp-trac] [WordPress Trac] #15855: Dropdown isn't shown when doing a user 'removal'
WordPress Trac
wp-trac at lists.automattic.com
Sat Dec 25 21:32:33 UTC 2010
#15855: Dropdown isn't shown when doing a user 'removal'
-----------------------------------+------------------
Reporter: scribu | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: 3.1
Component: Multisite | Version:
Severity: normal | Resolution:
Keywords: has-patch i18n-change |
-----------------------------------+------------------
Comment (by nacin):
I've just gone through these processes in 3.0 and again in 3.1. To be
clear:
- Single site, wp-admin/users.php. Delete a user, you get the
confirmation and you are allowed to reassign posts. Same for 3.0 and 3.1.
- Multisite, wp-admin/users.php. Remove a user, you get a confirmation
but are ''not'' allowed to reassign posts. Same for 3.0 and 3.1. Not
ideal, and would be a good fix. '''needs-patch'''
- Multisite, wp-admin/network/users.php (3.1) and wp-admin/ms-users.php
(3.0). Delete a user, you get a confirmation and are allowed to reassign
posts for each user. This is good.
- Multisite, wp-admin/network/site-users.php (3.1). Remove a user, and
you get no confirmation at all. This is bad. (Not a regression from ms-
sites.php in 3.0, though, which had one ugly UI.) ''needs-patch''
I am going to now evaluate the underlying code and the proposed patches
and implement what I can, in the least intrusive way possible. The smaller
amount of code churn, the better. I am less concerned about DRY code for
3.1 if that means that we risk breaking less things.
To be clear, there is no regression here, at all. I would be fine punting
all together, but it's inconsistent enough (and damaging enough, as it
causes authorless posts) to deserve a good look.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/15855#comment:23>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list