U4-2842 - When moving a media item from recycle bin / trash back to content media is still marked as trashed

Created by Mads Krohn 11 Sep 2013, 21:05:52 Updated by Lindsay Avery 04 Aug 2015, 19:43:22

When moving a media item back from recycle bin, the save and move events are fired. However, in the MediaService.Moved event the current media item is still marked as being trashed, although the Path is correctly updated. Further saving the media item will not restore the state to Trashed:false. This could cause trouble with integrating parts that counts on the trashed state of an item to be correct.

2 Attachments

Comments

Morten Christensen 12 Sep 2013, 07:56:27

This must be the same for Content then. As far as I can tell from the code the Trashed state is only changed if an item is currently Trashed and the parentId is the recycle bin, which isn't true for children of the root trashed item. Has anyone tried to verify this?


Mads Krohn 12 Sep 2013, 08:23:29

Not yet, but I will tonight :)


Mads Krohn 15 Sep 2013, 22:06:29

I did a few quick tests, and there seem to be no issues with trashed state for content.


Shannon Deminick 19 Dec 2013, 01:27:17

Content doesn't have this problem because it recursively moves each child item.


Sebastiaan Janssen 19 Dec 2013, 07:27:45

For reference, pull request: https://github.com/umbraco/Umbraco-CMS/pull/137


John Bear 04 Feb 2014, 11:21:59

I have just experienced this myself with nodes (not media) - Umbraco v6.1.5 (Assembly version: 1.0.4993.19246).

Client logged an issue that she was not able to save and publish a node. We saw an error message that said the node could not be published due to validation issues. We checked the properties on the node, but none had any validation of any kind. We then checked the logs and found a message that said "Content 'Product and Suppliers' with Id '11732' is trashed and could not be published". When we checked the database (umbracoNode) we saw that the "Trashed" flag was set to True but the path was fine (no recycle bin in the path) and the node was showing in the correct place within the content tree.

We have no idea how this could have happened. Just thought we'd log it and let you know.


Shannon Deminick 09 Feb 2014, 22:37:15

Thx John, if you can replicate this issue please log a new one and we'll have a look


Mads Krohn 09 Feb 2014, 23:59:11

John, I'm curious, how did you, if you did, get the node back on track ?


John Bear 10 Feb 2014, 09:35:29

@Mads - We had to open the database and go to the {{umbracoNode}} table, find the offending node by ID and update the {{trashed}} field to {{false}}. This, for us at least, seemed to fix it. Hope this helps. We also noted that even though the node was set to trashed, the recycle bin id ({{-20}}) was not in the path at all (weird).


Mads Krohn 10 Feb 2014, 10:16:03

@John ok, thanks. So you don't know if a move action or something like that would fix it? You didn't by any chance check the audit trail to see if you could figure out which actions your client performed to make the node end up in this false trashed state?


Steve Voltmer 10 Jul 2014, 12:24:09

@Mads, I can verify that moving the unpublishable nodes then moving them back, will allow you to publish them again without changing the database table manually.


Priority: Major

Type: Bug

State: Fixed

Assignee: Shannon Deminick

Difficulty: Normal

Category:

Backwards Compatible: True

Fix Submitted: Pull request

Affected versions: 6.1.5, 7.2.6

Due in version: 6.2.0

Sprint:

Story Points:

Cycle: