Summary: | Restoring from archive can create ghost nodes | ||
---|---|---|---|
Product: | Lenya | Reporter: | Markus Angst <mangst> |
Component: | Site Management | Assignee: | 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
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) ... ? > 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). (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. > 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?
(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. > 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?
(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. (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. (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. |