Add a step to the Data Removal/Erasure UX for deleting a user account

[coreymckrill]

In the ERASURE.md file over on #43602, it is mentioned that processing an erasure request does not actually remove the user's account, as that should be a separate step. However, this isn't mentioned anywhere in the UX, and may not match the expectations of some admins who are trying to fulfill a request to completely remove a user.

Perhaps the request could include a row action that initiates the process of deleting a user account? Or at least a blurb at the top explaining that account deletion is a separate step over on the Users table.

[allendav]

Add username and Delete User action to personal data erase request rows

[coreymckrill]

Does deleting a user also erase/anonymize their comments and other potentially personal data? If not, I wonder if this row action should only be available after the erasure request has been completed...

[allendav]

Replying to coreymckrill:

Does deleting a user also erase/anonymize their comments and other potentially personal data? If not, I wonder if this row action should only be available after the erasure request has been completed...

Mostly no. Deleting a user does dump their user meta as their user is deleted. It also removes their authorship from posts. Nothing else is cleaned up. In general, you could actually run these actions (erase personal data, delete user) in either order safely.

[iandunn]

I think it'd be good to add a current_user_can( 'delete_user', $user->id ) check before displaying the link, to avoid showing the admin a link for something they won't be able to do, if a plugin has removed that cap from them.

[TZ Media]

Great work. This functionality could utilize a feature similar to what is proposed in #43880 to ensure an anonymous user is present and auto-reassign the posts to that user.

Also, it might be useful to add a filter for the $row_actions to allow plugins to add their stuff, if possible.

[iandunn]

#44009 was marked as a duplicate.

[desrosj]

Moving gdpr tickets that are not bugs to Future Release until the next steps can be properly evaluated.

[desrosj]

Moving to the new Privacy component.

[desrosj]

Removing the GDPR keyword. This has been replaced by the new Privacy component and privacy focuses in Trac.

[davidbaumwald]

Latest patch fails against trunk, so marking needs-refresh.

[davidbaumwald]

With 5.5 Beta 1 releasing tomorrow ans this still needing a refresh and a review, this is being moved to Future Release. If any maintainer or committer feels the remainder of this ticket can be resolved in time, or wishes to assume ownership during a specific cycle, feel free to update the milestone accordingly.

[ozgursar]

When I try to apply the patch 43923.diff against the trunk (7.0-alpha-61215-src) it fails to apply to /wp-admin/includes/user.php with the following error:

patching file 'src/wp-admin/includes/user.php'
No such line 1014 in input file, ignoring
3 out of 3 hunks failed--saving rejects to 'src/wp-admin/includes/user.php.rej'

As the patch can not be successfully applied to the latest trunk, I'm removing the needs-testing but keeping the needs-refresh.