Bug 43861

Summary: Restoring from archive can create ghost nodes
Product: Lenya Reporter: Markus Angst <mangst>
Component: Site ManagementAssignee: Lenya Developers <dev>
Status: NEW ---    
Severity: normal    
Priority: P2    
Version: Trunk   
Target Milestone: 2.0.1   
Hardware: PC   
OS: Windows XP   

Description Markus Angst 2007-11-14 13:18:40 UTC
If you restore a subtree from archive, you can create a "ghost" node. Steps to
reproduce:
- build clean / build
- import example content
- go to site tab
- select subtree "Tutorials"
- create a new document called "World" with file / new xhtml document
- copy subtree "Resource type examples"
- select subtree "World"
- paste subtree "Resource type examples"
- archive subtree "Resource type examples"
- delete subtree "World" with edit / delete
- go to archive, select subtree "Resource type examples" and restore it
- you get a "ghost" entry between "Tutorials" and "Resource type examples"
  called "World" that is greyed out and thus can't be selected / modified
Comment 1 Andreas Hartmann 2007-11-15 07:29:12 UTC
What should we do about this?

a) don't allow to restore if parent doesn't exist
b) allow to manipulate (delete) "ghost" nodes
c) ... ?
Comment 2 Markus Angst 2007-11-15 07:50:58 UTC
> What should we do about this?
> 
> a) don't allow to restore if parent doesn't exist

Yes, and show a message like "The node or subtree cannot be restored to its
original position. Use cut and paste instead to move the node out of the archve
to the desired position." or something like that.

> b) allow to manipulate (delete) "ghost" nodes

I think this should only be done if it is necessary for other situations, too.

> c) ... ?

Automatically skip dead nodes while restoring. This will most probably lead to
unexpected/unwanted results (like name conflicts).
Comment 3 Andreas Hartmann 2007-11-15 07:57:53 UTC
(In reply to comment #2)
> > What should we do about this?
> > 
> > a) don't allow to restore if parent doesn't exist
> 
> Yes, and show a message like "The node or subtree cannot be restored to its
> original position. Use cut and paste instead to move the node out of the archve
> to the desired position." or something like that.

OK, whereas we have to be careful with cut&paste because of the workflow.

Comment 4 Markus Angst 2007-11-15 09:03:25 UTC
> OK, whereas we have to be careful with cut&paste because of the workflow.

Does a restore atm work different from cut&paste concerning workflow?

Comment 5 Andreas Hartmann 2007-11-15 09:24:50 UTC
(In reply to comment #4)
> > OK, whereas we have to be careful with cut&paste because of the workflow.
> 
> Does a restore atm work different from cut&paste concerning workflow?

AFAIK the workflow is not triggered with cut&paste. This operation should
actually not be allowed, if it is, it's certainly a bug.
Comment 6 Markus Angst 2007-11-15 12:14:35 UTC
> AFAIK the workflow is not triggered with cut&paste. This operation should
> actually not be allowed, if it is, it's certainly a bug.

You are right. Cut & paste out of the archive does not work. Well, cutting out
of the archive *seems* to work (menu entry black and no error message after
cut), but pasting does not (menu entry black, but error message after paste: "An
error occured. Please contact your system administrator."). Hmm.

Maybe we could allow deleting ghost nodes in the archive? :-\ How do other CMS
handle this? Maybe ghost nodes should be reanimated on restore?
Comment 7 Andreas Hartmann 2007-11-19 04:43:32 UTC
(In reply to comment #6)
> > AFAIK the workflow is not triggered with cut&paste. This operation should
> > actually not be allowed, if it is, it's certainly a bug.
> 
> You are right. Cut & paste out of the archive does not work. Well, cutting out
> of the archive *seems* to work (menu entry black and no error message after
> cut)

Cut/copy from any area but authoring is now disabled.
Comment 8 Richard Frovarp 2007-11-27 13:14:30 UTC
(In reply to comment #1)
> What should we do about this?
> 
> a) don't allow to restore if parent doesn't exist

I would do this. I've done some testing and since the parent is determined by
path instead of UUID, a new parent can be created and restored content will go
back under it. 
Comment 9 Richard Frovarp 2007-11-27 14:32:37 UTC
(In reply to comment #8)
> (In reply to comment #1)
> > What should we do about this?
> > 
> > a) don't allow to restore if parent doesn't exist
> 
> I would do this. I've done some testing and since the parent is determined by
> path instead of UUID, a new parent can be created and restored content will go
> back under it. 

This is what I've done. It's in r598789. Users can now no longer restore if
ghost nodes will be created. User must recreate the parent nodes, then they can
restore. 

I'm not saying this should be the final solution, but I do think it allows us to
defer the issue until 2.0.1.