Remove option in cancel screen to delete users AND their content

[kevwalsh]

User Story or Problem Statement

TBD

• As a CMS account admin, i shouldn't have an option to delete an [account], or [a user's content.]

Acceptance Criteria

• [ ] These two option have been removed from the account cancel screen:
  • [ ] "Delete the account and its content" is removed from the account cancel screen.
  • [ ] "Delete the account and make its content belong to the Anonymous user".

Implementation steps

TBD

Design principles

Which CMS design principle is at play?

• [ ] Purpose-driven: Creates an opportunity to involve the editor community in VA’s mission and content strategy goals.
• [ ] Efficient: Removes distractions and create clear, straightforward paths to get the job done.
• [ ] Approachable: Offers friendly guidance over authoritative instruction.
• [ ] Consistent: Reduce user’s mental load by allowing them to fall back on pattern recognition to complete tasks.
• [ ] Empowering: Provide clear information to help editors make decisions about their work.

CMS Team

Please leave only the team that will do this work selected. If you're not sure, it's fine to leave both selected.

• [x] Platform CMS Team
• [x] Sitewide CMS Team
  • [x] ⭐️ Content ops
  • [ ] ⭐️ CMS experience
  • [ ] ⭐️ Offices
  • [ ] ⭐️ Product support
  • [ ] ⭐️ User support

[kevwalsh]

There's a Prevent User Delete, Reassign Content to Anonymous contrib module to remove #3.

One implementation idea is to patch the module and extend it to also remove #4 (although that doesn't align with the module's name). Another approach is to make a more generic module "Prevent User Delete".

[stefaniefgray]

Performed a content audit; there is currently no content on the site where Authored By = Anonymous except in the case where the authored by field is blank due to the CMS Migrator

[stefaniefgray]

Dilemma: This issue may affect Drupal CMS admins' ability to remove "ghost" users.

“Ghost” accounts are troublesome, because they can block VA Drupal CMS Helpdesk staff from creating new user accounts, and can block [VA.gov](http://va.gov/) editors from getting logged in.

If you do not cancel the “fake” account created by the user’s attempted PIV card login attempt, they will not be able to log into the real account that a VA Drupal CMS Helpdesk team member has created or will be creating for them.

If you locate an Active user account on the production site with no roles added and no sections assigned, it means that they attempted to log into https://prod.cms.va.gov/ using their PIV card before their account was actually created.

In turn, the user cannot get logged into https://prod.cms.va.gov/ using their PIV card until a member of the VA Drupal CMS Helpdesk team has deleted the "ghost" account.

Here's the user story: As an admin, I am adding a new user to Drupal who just joined VA Cityname as their new Public Affairs Officer.

This user was very excited to use their new PIV card, and had attempted to log into https://prod.cms.va.gov/ before their account was actually created by a member of the VA Drupal CMS Helpdesk team.

In order to create their new Drupal CMS account assigned to the proper roles and sections, I have to delete the falsely created "ghost" user and create a new account from scratch. This allows the new VA Cityname PAO to log in with their PIV card as intended.

Related Slack thread: https://dsva.slack.com/archives/CT4GZBM8F/p1657222065278309

@kevwalsh Question: Is there any way we could test whether keeping the mistakenly created "ghost" account is a bad thing? Perhaps we could just add roles/sections to it? But to the best of my knowledge, something technical is blocking us from being able to do that, and that's why the account has to be deleted and recreated -- it might have to do with their PIV card being linked to their account from within the system.