Clearer warning that content will be deleted when a user account is deleted

[angrybrad]

Created by: Mark ([email protected]) on 2016/10/05 13:42:54 +0000
Votes at time of UserVoice import: 20

---

When a user account is deleted, all content input by that user is also deleted. There is a modal that pops up asking what you want to do with their content (ie you can transfer it to another user), but the warning needs to be bigger and scarier! One client didn't read the message properly thinking it was just a 'delete user' confirmation pop up. A simple update but it might prevent some major stress.

[angrybrad]

Posted by André Elvan ([email protected]) on 2015/03/10 17:52:06 +0000

---

Same thing here, the client accidentally deleted half their site after an employee quit. :)

[angrybrad]

Posted by Ryan ([email protected]) on 2016/10/31 10:06:35 +0000

---

I had the same thing. Deleted half the site. Luckly we had a back up but many don't.

[angrybrad]

Posted by Iain Urquhart ([email protected]) on 2016/06/12 21:46:37 +0000

---

Client just nuked the majority of their site content because of this... they simply didn't realise that was going to happen...

[angrybrad]

Posted by Matt Wilcox ([email protected]) on 2015/11/12 11:03:22 +0000

---

We've had this happen too. People don't read, and for action as bad as this they need to. Elsewhere destructive actions require the user to put their password in again - this should be the same.

[MattWilcox]

Ok, we have had two clients do this now. Destructive actions should require the user to put their password in again.

[startingnowco]

I just had a client do this (thankfully, the damage was minimal). Requiring a password entry with a clear prompt is a great idea.

[MattWilcox]

We have had this happen again recently, and the client deleted the previous "master user". They nuked 80% of the site, and didn't tell us for a couple of weeks. No backups available.

This is really dangerous default behaviour.

[brandonkelly]

Someone pointed out on Craft Slack:

I think the issue is more that they are not understanding the content of ‘Transfer it to’ is. Where as they have already decided to delete a user therefore they are then seeing ‘Delete it’ as the quick and easy option.

[khalwat]

@MattWilcox Backups definitely should be part of any site, imo: https://nystudio107.com/blog/mitigating-disaster-via-website-backups

That said, I'd tend to agree that it should at least be made harder for this to happen. I see two ways to do that:

1. In a scrolling field below the confirmation dialog, list all of the content that will be DELETED if this user is deleted
2. Require users to re-auth their password before the deletion takes place

The former gives people an idea of the implications of their action, which they may not have otherwise. It's reasonable that some people would think that deleting a user would delete just that user. Even though the dialog indicates that "all the content created by that user" will be deleted, actually showing the things that will be nuked I think will make a better connection with people.

The latter forces people to slow down, and hopefully read the former. And the implication of having to re-auth forces them to consider that the action they are about to take is important.

[narration-sd]

Just caught that this had moved to here - good. Upgraded from #craft3:

From 'some' experience anyway, would suggest there's no effective way to enlighten clients on the fly about this kind of thing - they will just look away and keep pressing that button or enter key.

How does it sound to just disable (or copy to another stack) any user being 'deleted'. Then provide a way for a superadministrator to curry - or reinstate -- later?

[angrybrad]

@narration-sd something like that would probably be done more at the element level: #867

[narration-sd]

@takobell Indeed, that would be great. Upvoting...

And maybe the framework for another request, duplicating content. (I know, head in hands on that one, but understandably desired...)

[khalwat]

The problem is the person clicks "Delete" and what looks to them like an "Are you sure you want to delete?" dialog pops up, so without thinking they click on "Delete it" (confirming yes, I really want to delete it), and then click Delete. Hiding it in a dropdown slows them down.

Better UX might be a dropdown menu that defaults to "Transfer it to" so they can't even see "Delete it" without slowing down and reading what's on the screen. Which is actually the problem. And maybe a warning symbol with warning text if they select "Delete it"

[MattWilcox]

Even if they do choose to delete, that should trigger exactly the same protection as when editing a user account - force them to put their password in. It makes them slow down and actually pay attention. I'd also suggest doing an automatic database backup on such massively destructive actions as this.

[khalwat]

I saw this UX on YouTube, thought it might be a pretty good fit here, too...

Not only does it explicitly tell you what's going to happen, and that you can't undo it... but it forces you to read it by disabling the button and counting down for 5 seconds.

[brandonkelly]

While we do want to improve the modal (mainly to spell out exactly what will be deleted by the action), we’re also thinking we should implement #867, so even if the content is chosen to be deleted, both the user and their entries will really just be archived, and only give admins the ability to actually hard-delete anything.

[MattWilcox]

Just make the ability to actually delete things a permission? Admin only won't work for all situations, but the idea is right. Only privileged users should be blessed with such destructive powers.

[MattWilcox]

You also end up with a front-end problem; if the user thinks they've deleted/archived another user, should pages that the archived user created be displayed on the front end? That's what the people making these mistakes believe should happen because they're not reading that deleting a user also deletes the content they made... but if we instead archive things then those pages that the user made won't show because that's not what happens when we archive pages.

[brandonkelly]

Just make the ability to actually delete things a permission?

Not a bad idea. Can you post as a new FR though?

You also end up with a front-end problem; if the user thinks they've deleted/archived another user, should pages that the archived user created be displayed on the front end?

No, but the point of the archive is, when it happens, it is easily fixable (just un-archive the entries).

[ianseyer]

Wow, we just deleted our website as a result of this preposterous default behavior.
I see zero reason for this to be the default behavior, except for bad database design. Objects shouldn't belong to users and you shouldn't CASCADE on delete (guessing this is what's happening, could be wrong)

We will now be looking at alternatives.