XWIKI-12987: Relative links are made absolute or even broken after moving a page

[surli]

Jira URL

https://jira.xwiki.org/browse/XWIKI-12987

TODO

• Document properly abstract methods in AbstractCopyOrMoveJob
• Improve SubWikiIT#movePageToSubwiki
• Why not checking if the doc exists in updateResourceReferenceAbsolute conditions?
• Verify all new FIXME in the code
• Check the problem of renaming or not the title

Changes

Description

The idea of this work is to:

1. Change the way AbstractCopyOrMoveJob works to perform computation of couple source/target documents before processing them
2. Provide a way to access that map source/target documents
3. Use that information when performing a call to ReferenceRenamer to define if a relative untyped link should be handled or not

The PR provides mainly:

• new APIs in ReferenceRenamer and MacroRefactoring to integrate the map of references that have been moved as part of same job
• refactorings of AbstractCopyOrMoveJob:
  • specific computation of getEntities to actually visit the hierarchy and populate the entities with the couple of source/target documents
  • new abstract methods to avoid duplications (not strictly needed for this work)
  • new method to retrieve the map of source/target documents
• new conditions in ResourceReferenceRenamer to decide if a link should be renamed or not: most of the logic of the fix is encoded there (see also clarifications)
• new calls in XWiki#updateLinksForRename and BackLinkUpdaterListener#updateBackLinks to give the map of source/target when calling the rename of references
• new integration test simulating the scenario indicated in the ticket and also performing a supplementary check related to a regression found afterwards
• same integration test also performed on a subwiki in SubWikiIT

Clarifications

The refactoring of references is currently called at two places:

1. by the BackLinkUpdaterListener for all backlinks after a document has been renamed (triggered by a document event)
2. by XWiki#updateLinksForRename to rename the internal links of the current document (which is always a call to updateResourceReferenceRelative, see below)

The problem of XWIKI-12987 is that XWiki#updateLinksForRename is called first and does perform an absolute rename of the relative links.
Now ResourceReferenceRenamer APIs names might be misleading: updateResourceReferenceRelative and updateResourceReferenceAbsolute are not about the references being absolute or relative: it's about the renamed references being absolute or relative respectively to the current document. It took me a while to integrate this, and I'm still struggling a bit with it.

So the problem was to find a proper condition to decide when to not refactor links, for this I'm performing a check for assessing if a link is absolute or not, by trying to resolve the ResourceReference without any parameter: if the result equals the reference with parameter then it was absolute.

Then for the updateResourceReferenceAbsolute the idea is to only perform update of the links, if the provided link is absolute, or if it's relative but the current document hasn't been moved as part of same job: in such case we do need to update the relative link, because there won't be a call to XWiki#updateLinksForRename on that document to update the link, we only get the call from BackLinkUpdaterListener.

For the updateResourceReferenceRelative the check is a bit more complex.
We only update links that are relative here, we don't want to update absolute references (is that correct? Can't find a counter example right now).
Then since we only perform refactoring of links relative to current document, we also check that the link about to be refactored is not related to pages that are part of the moved document in the same job: if those are also moved in the same job, then they're moved using same "direction", they're part of same hierarchy and we don't want to change the relative links wrt to them. This check is the main part of avoiding to update the relative links.

And finally we perform the update of the link only if the doc actually exists: we would create absolute links for those not existing doc, which doesn't make sense, we should keep the relative link we don't really know what the user wanted to do with those. Note that we could do the same check in updateResourceReferenceAbsolute but we don't really have the need since this is only called from the BackLinkUpdaterListener and if I'm correct we'll never have registered backlinks for a not existing doc.

Note that initially we discussed about using untyped link as a condition to perform or not the refactoring: I dropped the idea because we currently always create image resource references as untyped references from the WYSIWYG editor.

Screenshots & Video

Tested and supported UCs

In RenamePageIT:

• Rename of links outside moved hierarchy: My.Page contains link to [[1.2.WebHome]] and 1.2.WebHome full hierarchy is renamed to A.B.
• Rename of absolute links in content, macros and images inside a hierarchy: X.WebHome contains content with absolute links to sub pages in X space. X is renamed, we check that all absolute links / images are properly updated.
• Rename of relative links inside hierarchy: case of a hierarchy of pages containing Alice and Bob, WebHome contains simplest relative links (e.g. [[Alice]]) we check that those links are not updated if the whole hierarchy is moved. Test also performed when moving on a subwiki.

TODO:

• Check refactoring of relative / absolute links in translations

Executed Tests

Run of tests on following modules / integration test:

• xwiki-platform-refactoring
• xwiki-platform-flamingo-skin-test-docker
• xwiki-platform-attachment-test-docker and specifically AttachmentMoveIT
• xwiki-platform-index-test-docker and specifically AllDocsIT
• xwiki-platform-wiki-test-docker and specifically SubWikiIT

Expected merging strategy

• Prefers squash: Yes
• Backport on branches:
  *

[surli]

Original PR created in #3553 and recreated here after renaming the branch for CI.