I've seen it happen on a number of occasions:

A user wishes to delete a node attachment. They click the checkbox labeled "delete" in the file attachments fieldgroup, then they scroll the short distance to the bottom of the page and click the (node) "delete" button thinking "delete, yes, that's what I want to do," and they breeze through the delete confirmation page, and, "OMG! I deleted the whole node, not just the attachment!"

Possible solutions to this issue might be:
1. Changing the checkbox label from "delete" to "remove" (to soften the association that users make).
2. Change the label on the delete button to "Delete [content type]" (again, softening the association).
3. Ajax-ify attachment deletions so that they happen without the user having to think "delete-then-save". Of course one would want some sort of modal confirmation, so that it wouldn't be _too_ easy to accidentally delete an attachment.

I think 3 is probably the best option as it makes removing attachments work in the same way that adding them does while also resolving the accidental node deletion issue.

Thoughts?

Comments

StevenPatz’s picture

What is the fallback for those without javascript enabled?

m1mic’s picture

I would like to see a combination of all three. If the javascript route is implemented, then we would definitely want to have it degrade gently. Since I work with people that have a hard time even cutting and pasting, any little clue like changing the verbiage on the delete checkbox and the delete button would be a tremendous help IMO.

mlsamuelson’s picture

@spatz4000

The fallback for those without Javascript in option 3 would be the current behavior. Thus also adding on option 1 or 2 might be desireable.

catch’s picture

I like 3. We could always hide the files with javascript, but still not actually delete them until the node is saved, and add a "changes to uploaded files will lost unless you save this form" warning similar to the one on drag and drop ages. That way no need for a dialog since you'd still have to do the extra step to get rid of them completely. Would probably need a 'delete' (or remove) link on the drag and drop table to replace the checkbox.

+1 to changing 'remove' to 'delete'. There's the ability for uploaded files to be associated with uid rather than nid now (I think), which means increasingly files will be shared across nodes, and removing from one may not actually delete the file itself.

brianV’s picture

Issue tags: +Usability

Tagging for the Usability team. I've seen this happen before as well.

David_Rothstein’s picture

I've seen this happen too, and I agree that 1 and 3 seem worth implementing in their own right.

The real solution to fixing this though probably lies in #196758: Having delete as a button on the node edit form means certain users don't have access to it when they should...

dugh’s picture

subscribe

Bojhan’s picture

Version: 7.x-dev » 8.x-dev

I see this is an issue, but not critical enough to fix in this phase of the release cycle. So moving this to Drupal 8, lets see if we can find a more solid solution. I also believe having an actual action is better then a checkbox.

adaddinsane’s picture

I have written a D6 module which addresses this issue if you're interested...

http://drupal.org/project/attachments

(It does some other things as well.)

pingers’s picture

Status: Active » Fixed

The button has been renamed to "Remove" on file fields. Calling it done.

Status: Fixed » Closed (fixed)
Issue tags: -Usability

Automatically closed -- issue fixed for 2 weeks with no activity.