Bug: Very easy to lose data permenantly when deleting multiply-linked objects

[rleigh]

See attached screenshot.

In this case, I have a plate linked to two screens. If I choose to delete the plate from one screen, it is not made clear that it will be deleted from both. How do I delete a plate from a single screen only? "Cut" appears to do this, but normally this action only takes place after the corresponding paste (e.g. file managers, excel), and there's nowhere to paste it /to/, leading to some confusion over whether it was or was not unlinked.

It would be a bit less dangerous if the delete dialogue warned the user if it was present in multiple screens, and perhaps added an additional checkbox "Delete from all screens" which defaulted to off, so that by default the action would affect just the screen being operated on, rather than all screens.

This also applies to project/dataset as well, and potentially other places.

[jburel]

Big difference delete and unlink. If the same object is linked to 2 screens then yes. It is not a deep copy.
We have other tickets related to deep copy or even not allowing to link same object to 2 different containers.

[rleigh]

Does the user need to care about the difference between "unlink" and "delete"? If we look at a Unix filesystem with hardlinks as a related example, I can have the same file linked into multiple directory entries. But unlinking one does not affect the others; in fact, it's not even possible to delete them all in one go--I need to find and unlink each separately, and the delete only occurs when the reference count drops to zero. The point is, the user doesn't need to care about when deletion occurs--it's completely transparent and happens in the background. What's the use case for permitting the user to delete, rather than unlink? Would it not be safer, and more intuitive, to have a single "remove" operation which unlinks, and to not expose "delete" at all in the UI or indeed the API? I'm not sure I see what the value is in allowing it. It's completely counter to most user's expectations. In fact, I had Paul Felts contact me today to re-import a file he had accidentally deleted when trying to move it between groups, so there is an obvious usability issue here, and I think it would be better to err on the side of caution when dealing with the irrevocable deletion of precious data--the pop up confirmation dialogue is not an effective guard here, since users will just learn to click through it.

[rleigh]

Just to clarify with move dataloss. If you copy and paste an image or dataset, and then delete it from the original dataset or project (or plate, etc), all the "copies" are deleted. Even with the warning message, I don't think that most users even understand what it's telling them. "Yes, I do want to delete the image." Without being even aware of the implications of the action. The message "other users will no longer be able to access the data" or similar, does not spell out clearly "this action will delete all copies of the data, and there is no undo". In contrast, an unlink is far, far safer, and doesn't break typical expectations. Is copy+delete equivalent to cut+paste? Clearly not, but it probably should be.

[jburel]

As I said, we have various tickets related to that topic i.e. remove/unlink delete. It is true that it can generate confusion. We need to consider the various role: admin, member group owner and depending on it performs the correct action

[jmoore]

Simon: is this a duplicate of your #10278? If so, can you close it "duplicate" (since there's been more discussion here)