| Previous · Next | |
| User | Message |
|
preaction
|
Date: 9/28/2009 12:35 pm · Subject: Trashing an asset with a descendant on the Clipboard · Rating: -1
Currently, when you place an asset onto the Clipboard, it still exists in the exact location in the asset tree. It does not show up in the asset manager, so a user does not think it will be affected by putting the ancestor on the Trash. However, if the ancestor asset is purged, the asset on the clipboard gets purged with it (disappears), and the user is left scratching his head. Here's the solution I propose: 1) Purge begins 2) Purge encounters asset on the clipboard 3) Purge moves asset on the clipboard to a sibling of the asset being purged, leaving it on the clipboard The problem now is that the asset on the clipboard may be a child of an asset it's not allowed to be (like a Thread asset as a child of a Page Layout). This is not a problem unless the asset gets restored from the Clipboard pane of the Admin Console. There are four potential solutions to this problem that I see: 1) Try using addChild() to add the asset to the parent. This means that the assetId changes and old revisions are lost. 2) Try using addChild() to add a new asset of the same class and then purging that asset if it succeeds. 3) Add a method to check if a certain asset class is allowed to exist normally under another. 4) Allow the asset to break the rules and be added to the tree in that spot, no matter what display problems it causes. Number 3 is obviously most correct, but number 2 would require the least amount of work (which is good for those assets out there that will never be updated). Anybody else have an opinion or a new solution? |
| Back to Top |
Rate [ | ]
|
|
JT
|
Date: 9/28/2009 1:10 pm · Subject: Re: Trashing an asset with a descendant on the Clipboard · Rating: -1
I agree that 3 would be the most correct solution, however, your case doesn't state what happens if no suitable parent is found. Could you talk about that? |
| Back to Top |
Rate [ | ]
|
|
preaction
|
Date: 9/28/2009 1:21 pm · Subject: Re: Trashing an asset with a descendant on the Clipboard · Rating: -1
If the asset is not allowed to live as a "published" asset at the current location in the tree, the restore fails with an error message (or, in the case of number 4, succeeds and the user assumes all responsibility). Assets are allowed to live as "clipboard" state where ever they want. |
| Back to Top |
Rate [ | ]
|
|
JT
|
Date: 9/29/2009 9:40 am · Subject: Re: Trashing an asset with a descendant on the Clipboard · Rating: -1
Perhaps William is right. Perhaps even though it is an expensive operation it would be worth it simply from a consistency point of view because cutting isn't used all that often. However, if we do go back to a separate node for clipboard, I think that we eliminate the "Restore" option in the clipboard manager, because since the branch is no longer attached to it's parent, it's parent could go away or be moved to another location where it no longer makes sense to be able to restore the item. And it would eliminate the need to track its original parent separately. |
| Back to Top |
Rate [ | ]
|
|
knowmad
|
Date: 9/30/2009 8:20 am · Subject: Re: Trashing an asset with a descendant on the Clipboard · Rating: -1
However, if we do go back to a separate node for clipboard, I think that we eliminate the "Restore" option in the clipboard manager I don't see an issue with this change.
William ---- |
| Back to Top |
Rate [ | ]
|
|
ekennedy
|
Date: 9/28/2009 3:55 pm · Subject: Re: Trashing an asset with a descendant on the Clipboard · Rating: -1
The scenario you're describing probably explains some situations in the past where a content manager explained that stuff just disappeared. Wouldn't a fifth option be to make the purge fail with an appropriate message stating that the asset on the Clipboard needs to be dealt with before the purging the ancestor?
|
| Back to Top |
Rate [ | ]
|
|
knowmad
|
Date: 9/28/2009 5:06 pm · Subject: Re: Trashing an asset with a descendant on the Clipboard · Rating: -1
I've seen this happen before as well. Would the scenario that Colin describes cause content that was copied and pasted to another location in the site to disappear?
Actually, I have another (perhaps naive) idea. Could the clipboard be it's own special case that could be a parent of any asset? When an asset is cut or copied to the clipboard, it would become a child of the clipboard. That would alleviate the purge issue along with the issues it creates. As I alluded to above, I don't know much about the clipboard, but does it do an addChild() method call when content is pasted?
William ---- |
| Back to Top |
Rate [ | ]
|
|
preaction
|
Date: 9/28/2009 5:54 pm · Subject: Re: Trashing an asset with a descendant on the Clipboard · Rating: -1
When discussing this on IRC, JT mentioned that Clipboard and Trash used to be actual asset locations. The problem here is that putting assets onto the clipboard is now an expensive operation, when the problem it tries to fix doesn't happen all that often. Otherwise, I'd agree that this would be the most straightforward and logical solution. |
| Back to Top |
Rate [ | ]
|
|
patspam
|
Date: 9/29/2009 0:11 am · Subject: Re: Trashing an asset with a descendant on the Clipboard · Rating: -1
I'd never really thought about it but I guess this behaviour is consistent with your typical O/S file explorer. But it feels more "wrong" in the Asset Tree case because the asset actually disappears when you Cut it rather than just greying out the icon.If moving the asset to a Clipboard location is expensive, maybe only do it in the Purge case? In which case it becomes more of a lost+found folder? On Tue, Sep 29, 2009 at 8:54 AM, <doug@plainblack.com> wrote: preaction wrote: |
| Back to Top |
Rate [ | ]
|
|
knowmad
|
Date: 9/29/2009 7:22 am · Subject: Re: Trashing an asset with a descendant on the Clipboard · Rating: -1
Perhaps I'm missing something but how often is the clipboard being used? How expensive is this operation? I can't see where this is being used so much that it's cause for concern. Regarding Patrick's suggestion to do it only in the Purge case, I'd vote against that option in favor of consistency. I think it makes the most sense to do it the same way all of the time.
William PS: Does anyone know if the "missing content" behavior I described in my previous post could be caused by the clipboard? When an object is pasted back into the tree, does an addChild operation occur?
---- |
| Back to Top |
Rate [ | ]
|
