(cherry picked from commit 6d7a6b8e)

Co-authored-by: Manuel Leduc <manuel.leduc@xwiki.com>

(cherry picked from commit d3ade07e)

Co-authored-by: Manuel Leduc <manuel.leduc@xwiki.com>

The test is failing from time to time, and it seems like the failures
could be caused by unreliable initialization. We generally add
xwiki-platform-search-solr-query to the extraJARs also in other tests
due to initialization issues, so this might improve the initialization
here, too.

(cherry picked from commit 24e70cbb)

- Add XWiki.Mail object with French content to page XWiki.ForgotUsernameMailContent

(cherry picked from commit 7b4c0fda)

  * Ensure to use the proper configuration source component in
    notification configuration

(cherry picked from commit 277d1aa5)

  * Use the extension hooks not only when adding a new object class but
    also when adding an object from an already existing class

(cherry picked from commit 6deba692)

(cherry picked from commit a50a6465)

* Improve the test duration (setting large text with sendKeys is very slow)
* Reduce the flickering on stable-16.4.x at least (but for a different stacktrace than on master): it seems that Chrome WebDriver ignores sometimes the get(URL) calls done right after a new web page is loaded.

* getRealPath() now returns null when the path doesn't exist (used to return non-existing paths with Jetty 10)

(cherry picked from commit 42b4147e)

XWIKI-22505: Pinned pages markers and action are not displayed from time to time in Nav panel admin ui
XWIKI-21606: NavigationPanelAdministrationIT#navigationPanelAdministration is flickering
* Fix stupid mistake...

(cherry picked from commit 89fe791f)

(cherry picked from commit 4520c2ea)

Co-authored-by: Manuel Leduc <manuel.leduc@xwiki.com>

Fix coverage ratio.

* Fix the test for 16.4.x

(cherry picked from commit 51718c85)

Co-authored-by: Manuel Leduc <manuel.leduc@xwiki.com>

XWIKI-22626: Long file names collide with elements from the right side on Office Importer on Firefox (#3761) (#3938)

* Fixed the overflow by adding a max-width. This is a safe change that will only act when there's an overflow. The regular use case shouldn't be influenced by this change.

(cherry picked from commit 83139b92)

Co-authored-by: LucasC <lucas.charpentier@xwiki.com>

  * Fix the query for getting children references to use current
    document wiki
  * Fix related test

(cherry picked from commit 3a728589)

XWIKI-18687: The first heading is only partially excluded and transformed into content on Include/Display Macro when including a section

* Properly remove the first heading when including a section.
* Adjust the test case to cover headings with several words.

(cherry picked from commit 4450d4e2)

  * Introduce a new instance input property to exclude certain property
    classes.
  * Use this mechanism to exclude email and password properties in the
    Document API.

(cherry picked from commit 742ee348)

This reverts commit 9f6cb03a.

  * Fix wrong deprecated annotation

(cherry picked from commit 97cab6fb)

  * Start work to have specific handling of WebPreferences in case of
    move/rename/copy of a full space
  * Fix unused import
  * Provide integration test
  * Fix wrong conditions
  * Add unit tests

(cherry picked from commit 594fd60d)

  * Fix problems when trying to rename an entire space
  * Ensure to cover this UC in unit tests

(cherry picked from commit ba4bd1e0)
(cherry picked from commit 61fd5777)

XWIKI-22571: Backlinks update changes an absolute reference to the moved page into one relative to the current wiki

  * Update test

(cherry picked from commit 4904b347)

XWIKI-22571: Backlinks update changes an absolute reference to the moved page into one relative to the current wiki (#3654)

  * Use default serializer if the wiki is present in a link, not the
    compact serializer
  * Provide unit test and integration test to cover this
  * Fix DeletePageIT tests
  * simplify condition by using the relative resource reference resolver
  * fix tests

(cherry picked from commit d2d9a575)

  * ugly fix of the page reference regression and cover it with
    integration test

(cherry picked from commit 60b05424)

The idea of this work is to:

    * Change the way AbstractCopyOrMoveJob works to perform computation of couple source/target documents before processing them
    * Provide a way to access that map source/target documents
    * 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

The refactoring of references is currently called at two places:

    by the BackLinkUpdaterListener for all backlinks after a document has been renamed (triggered by a document event)
    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.

Note that this work currently includes a known regression when renaming links on the form `page:../SubSpace/Page`, this is going to be handled in further work.

(cherry picked from commit fc01c140)

(cherry picked from commit 65acde03)

  * Minor improvment

(cherry picked from commit a5f4f86c)

Thomas Mortagne authored 3 months ago and Simon Urli committed 2 weeks ago

* remove unused import

(cherry picked from commit b845a4a7)

  * Provide EntityReference#getParentType
  * Use it in AbstractReferenceEntityReferenceResolver
  * Provide a new test
  * add more explanatory tests
  * Improve a bit the checks when setting the fallbackParentType
    parameter value
  * use back parentType parameter key name

(cherry picked from commit c5b9c605)

(cherry picked from commit 4e2efc81)

Vincent Massol authored 3 months ago and Simon Urli committed 2 weeks ago

(cherry picked from commit 95e312ab)

XWIKI-22583: Allow users with edit rights on a page and all its children to use the Pinned Pages feature

  * Mitigate possible flickering behaviour

(cherry picked from commit 4dd45461)