[wp-trac] [WordPress Trac] #23361: Deleting a user in Network Admin still defaults to "Delete all posts"

[WordPress Trac]

#23361: Deleting a user in Network Admin still defaults to "Delete all posts"
-------------------------------------+-------------------------------------
 Reporter:  SergeyBiryukov           |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Future Release
Component:  Users                    |     Version:  3.5
 Severity:  normal                   |  Resolution:
 Keywords:  needs-patch ux-feedback  |     Focuses:  administration,
  needs-screenshots 2nd-opinion      |  multisite
-------------------------------------+-------------------------------------
Changes (by callumbw95):

 * keywords:  needs-patch ux-feedback needs-screenshots => needs-patch ux-
     feedback needs-screenshots 2nd-opinion


Comment:

 Hi all,

 I have taken a look into this, and this is still working today as
 @cgrymala documented. I agree that we could look at adding more context in
 the form to show what content is under the user for each site within the
 form.

 - We could either display this as a counter detailing how many posts, and
 potentially each post type, under each of the sites. My concern with this
 method would be that potentially users would want to split out the post
 types and assign them all individually to different authors. This isn't
 necessarily a bad thing, and could evolve the current form in to more than
 it is now. But I would argue that the form itself is somewhat
 circumstantial and most of the time migrating all of a users posts to
 another user will be enough on its own.

 - Alternatively we could hide the a site from the form if there are no
 posts for that user for that site. My concern with this is that this would
 arguably be less clear to the user as hiding a site or fields under a site
 would need some context to explain why the site wouldn't be showing.

 Both options would help make things more clear and less cumbersome
 overall, however they would both add a level of overhead to the page load,
 but if it aids the user then this is not necessarily a bad thing. Either
 way I am keen to hear the communities thoughts on this, as there is an
 argument that the way the form is currently set up is fine as is.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/23361#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform