You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The issue is that the modification dates of XWiki pages created by the migrator do not corresponds to the modification dates of the confluence pages, the modifications dates of XWiki pages are instead set to the date of the migration. This is problematic because the modification date is very important in some cases, for example to order/display the pages chronologically using some macros.
Steps to reproduce :
On XWiki instance version 14.10.17 install Confluence Migrator Application Pro version 1.7.9
Export a space from Confluence that contains pages with modification dates prior to today's date, see screenshot
On XWiki Confluence Migrator Pro run a new migration using the exported confluence space with default configurations and observe the result
Expected results : The space pages are correctly imported and the modification dates of the XWiki pages corresponds to the modification dates of the original confluence pages
Current results : The pages are correctly imported but the modification dates of the XWiki pages are initialized with the migration timestamp. See screenshots :
Note that the page creation date is correctly initialized.
According to the XWiki page history it seems that the issue is caused by the Nested Pages Migrator which is not preserving modification dates generated by the Confluence XML extension.
The text was updated successfully, but these errors were encountered:
Hello, @mouhb . I believe that this is the expected thing to happen. Running a renaming job (what NPM does) on XWiki will add a new version to the renamed/moved page with the same date as the execution time.
Page before moving:
Page after moving:
I don't really think we should work around how the refactoring job functions (unless the majority of people that use the application need it). Maybe a script would be a better solution for whoever needs it.
Hello, @mouhb . I believe that this is the expected thing to happen. Running a renaming job (what NPM does) on XWiki will add a new version to the renamed/moved page with the same date as the execution time.
Page before moving:
Page after moving:
I don't really think we should work around how the refactoring job functions (unless the majority of people that use the application need it). Maybe a script would be a better solution for whoever needs it.
This issue was reported by a client and for them it is very important to keep the original modification dates from confluence. I don't know if other users asked for it, maybe @snazare knows more about this. And yes, a script would be a solution for the issue.
The issue is that the modification dates of XWiki pages created by the migrator do not corresponds to the modification dates of the confluence pages, the modifications dates of XWiki pages are instead set to the date of the migration. This is problematic because the modification date is very important in some cases, for example to order/display the pages chronologically using some macros.
Steps to reproduce :
Expected results : The space pages are correctly imported and the modification dates of the XWiki pages corresponds to the modification dates of the original confluence pages
Current results : The pages are correctly imported but the modification dates of the XWiki pages are initialized with the migration timestamp. See screenshots :
Note that the page creation date is correctly initialized.
According to the XWiki page history it seems that the issue is caused by the Nested Pages Migrator which is not preserving modification dates generated by the Confluence XML extension.
The text was updated successfully, but these errors were encountered: