I'm not sure if this is the right forum, but since this isn't inherently a bug, then i'll post it here.
I work at a Digital Bureau, where we among other things, create Umbraco solutions for other medium to large sized companies. The people creating the content for the umbraco solution are editors, not technicians, which means they have a laymans view on backoffice. As i understand it, Umbraco is built on the foundation of simplicity and being editor-friendly, and as such i would like to bring up an issue we had to deal with yesterday.
I received a phonecall from an editor regarding a content node that he had deleted, but hadn't realized it would delete the entire sub-tree of content. Of course, the first thing is to look at the recycle bin in backoffice, but alas, search as i might, the content is not there. I ask him what he did, and he tells me he made a new content node, deleted the old, and renamed the new to have the old ones name, but then realized his mistake.
After a bit of rummaging around i find the node id of the content-tree in the umbracoTraceLog, where i find the last unpublishing event of a node of the same specific name, occurring around the same time as the editor mentioned.
I search backoffice for the node id, but no content turn up. Last resort, i look through the database, but no content (trashed or not) exists with that id. At this point i have to inform the editor that he unfortunately has to manually re-create the entire subtree.
After the phonecall i look at how this permanent deletion could happen, and i find the following in the database log-table:
Apparently he did delete it twice himself, once from the content-tree, once from the recycle bin.
But it makes little sense that he would accidentally delete it from the recycle bin and not know it himself, and the timing makes very little sense. After deleting it (moving it to the recycle bin), he had 3 seconds to scroll the backoffice to the recycle bin, open it, scroll all the way down to the bottom (there's a lot of items in there), right click the item and misclick delete. I tried doing it and it took me 3.5-4 seconds, and i knew what i was doing. The editor barely knew the recycle bin functionality.
Obviously, the item was manually unpublished then 2 seconds later deleted from the content-tree (automatic process would not take 2 seconds to do that), but the 3 seconds still bothered me.
So i checked the other way of deleting an item (the normal way we do, is to rightclick the item in the menu), using the Action button in the top right. Now it turns out that if you are on an item, click Action -> delete, then you are not move away from that item, but it just falls out of the menu on the leftside. What you can then do is click Action -> delete again, and with no warning or indication, the item is deleted permanently. Funny sidenote: you are actually still on the item, even after it's permanently deleted. If you try to delete it a third time you get a 404 error.
So, by just being on an item and pressing Action -> delete, then if you miss the deletion animation in the menu, you wouldn't really know that it's deleted, since nothing about 80% of the screen changed (none of the screen changes if you press "OK" while in the "compact" version where the menu isn't shown). Oh, okay, maybe i didn't press properly, i'll just delete again, and so the item is permanently, unretrievably deleted.
What if he on the frontpage of a municipal website? That would be potentially thousands of nodes disappearing forever. Of course, we can retrieve backups of the server from the day before and such, but that's besides the point.
There should be some way to know when you delete the item, like going to the parent item instead, a very visible change in environment.
TL;DR: Editor deleted an entire subtree of content permanently by using the Action -> delete button twice while on the content node, because there is no change after you delete the node (except in the menu, which you might not see because it gets hidden when you have a smaller window). There should be a visible change, like going to the parent after a deletion.
Permanent deletion and Editors
Hello
I'm not sure if this is the right forum, but since this isn't inherently a bug, then i'll post it here.
I work at a Digital Bureau, where we among other things, create Umbraco solutions for other medium to large sized companies. The people creating the content for the umbraco solution are editors, not technicians, which means they have a laymans view on backoffice. As i understand it, Umbraco is built on the foundation of simplicity and being editor-friendly, and as such i would like to bring up an issue we had to deal with yesterday.
I received a phonecall from an editor regarding a content node that he had deleted, but hadn't realized it would delete the entire sub-tree of content. Of course, the first thing is to look at the recycle bin in backoffice, but alas, search as i might, the content is not there. I ask him what he did, and he tells me he made a new content node, deleted the old, and renamed the new to have the old ones name, but then realized his mistake.
After a bit of rummaging around i find the node id of the content-tree in the umbracoTraceLog, where i find the last unpublishing event of a node of the same specific name, occurring around the same time as the editor mentioned.
I search backoffice for the node id, but no content turn up. Last resort, i look through the database, but no content (trashed or not) exists with that id. At this point i have to inform the editor that he unfortunately has to manually re-create the entire subtree.
After the phonecall i look at how this permanent deletion could happen, and i find the following in the database log-table:
Apparently he did delete it twice himself, once from the content-tree, once from the recycle bin.
But it makes little sense that he would accidentally delete it from the recycle bin and not know it himself, and the timing makes very little sense. After deleting it (moving it to the recycle bin), he had 3 seconds to scroll the backoffice to the recycle bin, open it, scroll all the way down to the bottom (there's a lot of items in there), right click the item and misclick delete. I tried doing it and it took me 3.5-4 seconds, and i knew what i was doing. The editor barely knew the recycle bin functionality.
Obviously, the item was manually unpublished then 2 seconds later deleted from the content-tree (automatic process would not take 2 seconds to do that), but the 3 seconds still bothered me.
So i checked the other way of deleting an item (the normal way we do, is to rightclick the item in the menu), using the Action button in the top right.
Now it turns out that if you are on an item, click Action -> delete, then you are not move away from that item, but it just falls out of the menu on the leftside. What you can then do is click Action -> delete again, and with no warning or indication, the item is deleted permanently. Funny sidenote: you are actually still on the item, even after it's permanently deleted. If you try to delete it a third time you get a 404 error.
So, by just being on an item and pressing Action -> delete, then if you miss the deletion animation in the menu, you wouldn't really know that it's deleted, since nothing about 80% of the screen changed (none of the screen changes if you press "OK" while in the "compact" version where the menu isn't shown). Oh, okay, maybe i didn't press properly, i'll just delete again, and so the item is permanently, unretrievably deleted.
What if he on the frontpage of a municipal website? That would be potentially thousands of nodes disappearing forever. Of course, we can retrieve backups of the server from the day before and such, but that's besides the point.
There should be some way to know when you delete the item, like going to the parent item instead, a very visible change in environment.
TL;DR:
Editor deleted an entire subtree of content permanently by using the Action -> delete button twice while on the content node, because there is no change after you delete the node (except in the menu, which you might not see because it gets hidden when you have a smaller window).
There should be a visible change, like going to the parent after a deletion.
is working on a reply...