Problem The application is designed to be copyable/renameable to another top-level space: each page resolves its own space at runtime with
#set ($topSpace = $doc.documentReference.extractFirstReference('SPACE').getName())
Twelve places do not follow it and write the literal ReleaseNotes. prefix instead. include targets: WebHome; Data/WebHome (three includes); Code/HomeReleaseNotes; Code/HomeReleaseChanges; Code/Change/ReleaseNotesChangesMacro; Code/Change/ChangeDisplayerSimple, ChangeDisplayerList, ChangeDisplayerFlow, ChangeDisplayerGrid; Code/Change/ChangeSheet. Live Data suggest URLs (inside XWiki.JavaScriptExtension objects with parse=1): Code/HomeReleaseNotes (2 sites, classname=ReleaseNotes.Code.ReleaseNoteClass) and Code/HomeCustomReport (5 sites, classname=ReleaseNotes.Code.EntryClass / ...Change.ChangeClass). Data/WebHome computes $topSpace and then hardcodes the prefix eleven lines later. Consequence A copy of the application installed under another top-level space renders against the original space's helper pages and breaks outright once the original is uninstalled. The seven suggest URLs silently stop suggesting anything, because the classname names a class that does not exist in the copy and the suggest endpoint returns an empty list rather than an error. Notes Both shapes are fixable. Code/Change/DisplayChangesMacro already proves an include reference can be interpolated when it sits inside a velocity block:
{{include reference="${topSpace}.Code.Change.ChangeDisplayer${stringtool.capitalize($displayer)}"/}}
and the JSX objects are parse=1, so they only need their own #set ($topSpace = ...). Also worth deciding as part of this: GetChangesMacro and DisplayChangesMacro derive $topSpace from $xcontext.macro.doc while the other 16 pages derive it from $doc. These coincide in a single installation and diverge otherwise; which one is canonical is currently unstated. |
