-
Bug
-
Resolution: Fixed
-
Blocker
-
3.5.4
-
None
Moving nodes can create inconsistent website-trees on author and public system
Can be reproduced by the following:
(on author instance)
- login as superuser:
- create the following page structure (website)
+ ...(some other pages, does not matter)
+ page1 (Magnolia Samples: One column page)
+ page2 (Magnolia Samples: One column page)
+ page10 (Magnolia Samples: One column page)
- activate everything
- publish everything (in the workflow)
- create a new user 'emil', set some nice password
- add the role 'editor' (role, not group, and no other rights)
- logout
- login as emil
- move page1 to page10, click yes to deactivate nodes (tree should now look like the following)
+ ...(some other pages, does not matter)
+ page10
+ page1
+ page2
- logout
++++++++++++++++++++++++++++++++++++++++++++++++
---> notice that the pages on the demopublic (the public instance) are still the 'old' one:
+ ...(some other pages, does not matter)
+ page1 (Magnolia Samples: One column page)
+ page2 (Magnolia Samples: One column page)
+ page10 (Magnolia Samples: One column page)
++++++++++++++++++++++++++++++++++++++++++++++++
- login as superuser
- activate page1
- publish page1 (in the workflow)
- activate page2
- publish page2 (in the workflow)
++++++++++++++++++++++++++++++++++++++++++++++++
---> error-message in workflow (for page2): Can't activate: : Message received from subscriber: Parent not found (not yet activated): page10/page1
---> on demopublic are still the same pages published!
+ ...(some other pages, does not matter)
+ page1 (Magnolia Samples: One column page)
+ page2 (Magnolia Samples: One column page)
+ page10 (Magnolia Samples: One column page)
on demoauthor (author instance) is the 'new' page structure, all 'green' except page2 (-> looks like published)
+ ...(some other pages, does not matter)
+ page10
+ page1
+ page2
++++++++++++++++++++++++++++++++++++++++++++++++
--> page1 and page2 can not be removed on public anymore
--> page1 and page2 can not be published anymore
Suggestion: why not disable moving published pages?
--> de-activate, move, activate is the correct sequence anyway
- depends upon
-
MAGNOLIA-1899 activation: if the page (uuid) exist in different hierarchy content is activated to the old place
- Closed
- is related to
-
MAGNOLIA-2173 Moving / rename a page on author should not deactivate it on public instances
- Closed