Make WordPress Core

Opened 10 years ago

Last modified 5 years ago

#26195 new enhancement

Deleting users asks for reassigning posts even when there is no post/comment

Reported by: marcelwaldvogel's profile MarcelWaldvogel Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.7.1
Component: Users Keywords: has-patch dev-feedback
Focuses: Cc:

Description

When deleting a single user or bulk deleting users, the confirmation page asks what should be done with the posts of the user.

However, this question should not be displayed, if the sum of the posts of these user(s) is 0. Then, the delete button should become immediately active.

This change would make deletion safer, as "real" users would be less likely to be deleted in error.

Recommended user interface:

  • No posts present: "This user/these users have no post", followed by an active "delete users" button
  • Posts present: "This user/theses users have a total of [number] posts", followed by the current delete/assign query.

Attachments (1)

26195.diff (4.2 KB) - added by leewillis77 10 years ago.

Download all attachments as: .zip

Change History (6)

@leewillis77
10 years ago

#1 follow-up: @leewillis77
10 years ago

  • Keywords has-patch dev-feedback added

Patch attached. This meets the users original request:

"However, this question should not be displayed, if the sum of the posts of these user(s) is 0. Then, the delete button should become immediately active."

It doesn't provide a count of posts for users although could be extended to if required.

My only reservation about this is that it effectively defaults to "delete posts" in the absence of a "choice". There's a slim chance that if a user due to be deleted creates a post between the start of the process, and the user confirming the action then that post will be silently deleted.

We could extend it to not delete the post, but that would leave data consistency issues.

We could (If anyone feels the issue is significant enough) also amend it so that the user will not be deleted (Nor their posts) if this route is followed.

#2 in reply to: ↑ 1 ; follow-up: @SergeyBiryukov
10 years ago

Replying to leewillis77:

My only reservation about this is that it effectively defaults to "delete posts" in the absence of a "choice".

Looks like 26195.diff essentially reverts [22166].

#3 in reply to: ↑ 2 @MarcelWaldvogel
10 years ago

Replying to SergeyBiryukov:

Looks like 26195.diff essentially reverts [22166].

The way I read the patch (not knowing too much about the WP internals), I don't think it reverts [22166] or contradicts #20045. *If* there are posts, the functionality of [22166] and #20045 remains, and only in that case is their functionality useful.

  1. It enhances the user's respect of the system (avoids "why does this dumb computer force me to do an additional click, if there is no real choice?!?")
  2. It keeps the user from making a mistake, i.e., the deletion of a series of users with content (likely more "valuable" users) is different from deleting users with no content)
Last edited 10 years ago by MarcelWaldvogel (previous) (diff)

#4 @downstairsdev
10 years ago

+1 Giving an option to re-assign posts is confusing when there are no posts.

I tested 26195.diff and I think it's an improvement. But I agree that the edge case of user creating post as the user delete happens is problematic.

How about converting this to an AJAX function so that the delete could happen straight from the initial screen? If a new post appears, the function could abort. This would also save a screen reload.

Note: See TracTickets for help on using tickets.