XWiki Platform
  1. XWiki Platform
  2. XWIKI-13493

The parent-child relationship of a page is not updated during a move

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 7.4.2, 8.1
    • Fix Version/s: 8.4.1, 7.4.6, 9.0-rc-1
    • Component/s: Refactoring
    • Labels:
      None
    • Difficulty:
      Unknown
    • Documentation:
      N/A
    • Documentation in Release Notes:
      N/A
    • Similar issues:

      Description

      The ancien parent field is updated during creation process, and thanks to XWIKI-13106, the children are also updated during a rename of the parent page. But, when a page is moved, the parent field of the page itself is not updated according to its new parent.
      Moreover, the NS Migrator App also update that parent field in addition to the normal rename process. Issue linked to parent field get notice very late in legacy application, since the parent field is properly maintained in all cases but this one. So I believe this is a bug that need to be fix, or there is no point to have manage all the other use cases.

      Step to reproduce:
      1) Create page A(.WebHome)
      2) Create page A.B(.WebHome)
      3) Create page A.B.C(.WebHome)
      4) Create page A.B.C.D(.WebHome)
      5) Move page A.B.C(.WebHome) to page A.C(.WebHome)
      5) Export all these pages to XAR, and check their <parent> tags.

      Page Storage parent Parent field Comment
      A (null) Main.WebHome Curious...
      B A(.WebHome) A.WebHome Ok
      C A(.WebHome) A.B.WebHome Wrong
      D A.C(.WebHome) A.C.WebHome Ok

        Issue Links

          Activity

          Hide
          Marius Dumitru Florea added a comment -

          For me there's no relation between the value of the parent field and the parent reference. You are mixing things. XWIKI-13106 was a bug because if A is parent of B and we rename A then we need to update B to the new reference of A. Semantically this means updating the back-links, because B has a "link" to A through it's parent field. But I don't see why we should update the parent field of A when we move A. The move operation is supposed to change the reference of A not the value of the parent field. To make things clear, forget about nested spaces/documents. Go back to XWiki 7.1.1. Move a page from Space X to Space Y. Its parent field is not updated and that's normal because the parent-child hierarchy is separated from the reference "hierarchy". I don't see why we should change this behaviour now. For me this is a Won't Fix.

          Show
          Marius Dumitru Florea added a comment - For me there's no relation between the value of the parent field and the parent reference. You are mixing things. XWIKI-13106 was a bug because if A is parent of B and we rename A then we need to update B to the new reference of A. Semantically this means updating the back-links, because B has a "link" to A through it's parent field. But I don't see why we should update the parent field of A when we move A. The move operation is supposed to change the reference of A not the value of the parent field. To make things clear, forget about nested spaces/documents. Go back to XWiki 7.1.1. Move a page from Space X to Space Y. Its parent field is not updated and that's normal because the parent-child hierarchy is separated from the reference "hierarchy". I don't see why we should change this behaviour now. For me this is a Won't Fix.
          Hide
          Denis Gervalle added a comment -

          So Marius, in my example, it will maintain the reference of the parent in page C, when I move page B, and to be tortuous, I gonna move it under D ! This gonna make a very unusable mess, while if we stay on the simple "backlinks" logic, could be considered from a theoretical point of view, perfectly correct.

          There are, however, two aspects that does not really follow properly:

          • the parent field is currently initialized on non-terminal pages newly created
          • the NS migrator is working around this issue, and update this parent field after move

          From these two facts, we have a consequence which is that, until a manual move, the parent field is currently in synchronization with the storage of the page. So currently, some legacy application that base their page management (creation/move/etc...) on the standard process, but that use the ancient parent field for some logic, continue to work properly, even after a migration into a deep hierarchy with the migrator, even after new page creation, but start to fail when a move is made.

          Can you explain why we have chosen to maintain the parent field up to a move ? And what would be the real benefit of a won't fix for users, knowing that the effort is low (a one-line patch) ?

          PS: OK, a two line one, since we also have to fix the copy of the page that follows the same theoretical logic.

          Show
          Denis Gervalle added a comment - So Marius, in my example, it will maintain the reference of the parent in page C, when I move page B, and to be tortuous, I gonna move it under D ! This gonna make a very unusable mess, while if we stay on the simple "backlinks" logic, could be considered from a theoretical point of view, perfectly correct. There are, however, two aspects that does not really follow properly: the parent field is currently initialized on non-terminal pages newly created the NS migrator is working around this issue, and update this parent field after move From these two facts, we have a consequence which is that, until a manual move, the parent field is currently in synchronization with the storage of the page. So currently, some legacy application that base their page management (creation/move/etc...) on the standard process, but that use the ancient parent field for some logic, continue to work properly, even after a migration into a deep hierarchy with the migrator, even after new page creation, but start to fail when a move is made. Can you explain why we have chosen to maintain the parent field up to a move ? And what would be the real benefit of a won't fix for users, knowing that the effort is low (a one-line patch) ? PS: OK, a two line one, since we also have to fix the copy of the page that follows the same theoretical logic.
          Hide
          Guillaume Delhumeau added a comment -

          If I remember correctly, the NS migrator updates the parent's field because, at some point, XWIKI-13106 was not fixed. Not that the migration does not enable the feature introduced with XWIKI-13106, since the results after the process should be the sames.

          Show
          Guillaume Delhumeau added a comment - If I remember correctly, the NS migrator updates the parent's field because, at some point, XWIKI-13106 was not fixed. Not that the migration does not enable the feature introduced with XWIKI-13106 , since the results after the process should be the sames.
          Hide
          Anca Luca added a comment - - edited

          Soooo, I experimented with this issue and here is my take on it:

          The behaviour on rename / move should depend on the value of the "core.hierarchyMode" property, as follows:

          • if the value is "parentchild" then indeed, the value of the parent should not be updated on rename/move because rename / move is about the location of the page which, in the case of a "parentchild" hierarchy mode, is supposed to be independent of the hierarchy: so it's normal for the parent to stay set to whatever the user set it and if the user wants it different they need to update it manually, as we did before the nested spaces (if a page in the space A had parent A.WebHome, moving it in space B would not automatically update its parent to B.WebHome).
          • if the value is "reference", then the value of the (deprecated) parent field should be updated to always correspond to the breadcrumb of that page, on rename, on copy, etc. The idea of the reference hierarchy mode is that location and hierarchy are one and the same thing, so being able to arrive in a situation when the value of the doc.parent is saying something else than the location of that page is a bug. In addition, not updating automatically the parent value once it has been set (on creation) is problematic because there is no way for a user to fix that value.

          Otherwhise put, this bug is only valid for the case when the hierarchy mode of the wiki in question is set to "reference" .
          Yet otherwise put, I think both Marius and Denis are right, but for different values of the hierarchy mode parameter.

          Show
          Anca Luca added a comment - - edited Soooo, I experimented with this issue and here is my take on it: The behaviour on rename / move should depend on the value of the "core.hierarchyMode" property, as follows: if the value is "parentchild" then indeed, the value of the parent should not be updated on rename/move because rename / move is about the location of the page which, in the case of a "parentchild" hierarchy mode, is supposed to be independent of the hierarchy : so it's normal for the parent to stay set to whatever the user set it and if the user wants it different they need to update it manually, as we did before the nested spaces (if a page in the space A had parent A.WebHome, moving it in space B would not automatically update its parent to B.WebHome). if the value is "reference", then the value of the (deprecated) parent field should be updated to always correspond to the breadcrumb of that page, on rename, on copy, etc. The idea of the reference hierarchy mode is that location and hierarchy are one and the same thing, so being able to arrive in a situation when the value of the doc.parent is saying something else than the location of that page is a bug. In addition, not updating automatically the parent value once it has been set (on creation) is problematic because there is no way for a user to fix that value. Otherwhise put, this bug is only valid for the case when the hierarchy mode of the wiki in question is set to "reference" . Yet otherwise put, I think both Marius and Denis are right, but for different values of the hierarchy mode parameter.

            People

            • Assignee:
              Guillaume Delhumeau
              Reporter:
              Denis Gervalle
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Date of First Response: