There is 1 comment.
 
 
Release Notes Application / cid:jira-generated-image-avatar-677f5791-eb25-4c6d-b313-9154ee2e010d RN-74 Open

Depend on the latest XWiki Standard LTS cycle (17.10)

 
View issue   ยท   Add comment
 

1 comment

 
cid:jira-generated-image-avatar-c11ba020-ce48-41b9-b46c-c8749b137a8a Vincent Massol on 29/Aug/26 11:43
 
Moving the parent from {{org.xwiki.contrib:parent-platform:14.10-7}} Correction to {{17.10.0-2}} (minimum XWiki 17.10, Java 17) is not enough on its own my previous comment : the {{displayChanges}} macro silently displayed nothing application was *not* broken on XWiki 17.10. Sorry for the noise - the earlier analysis drew the wrong conclusion from a functional-test failure.

Root cause What actually happens : {{Code/Change/DisplayChangesMacro}} read the list published by {{getChanges}} with

{code}
#set ($changeItems = $xcontext.get('vcontext').get($xvariable))
{code}

On XWiki 17.10 {{ $xcontext Context .get( 'vcontext' String )}} no longer resolves is annotated {{@Programming}} and returns null without programming right. On a real wiki the current Velocity context application pages have programming right , so this works - which is why xwiki.org (currently XWiki 18.4.3) shows its release notes and its Changes Report correctly, and why nobody ever saw a problem.

What changed is the *test* environment, not the platform: the Docker functional-test framework of XWiki 17.10 enables a programming-right checker that the 14.10 one did not have. It logs

{ noformat}
PRChecker: Block programming right for page [xwiki:ReleaseNotes.Code.Change.DisplayChangesMacro]
{ $changeItems noformat } } was always

so under test the call returned
null and the macro {{displayChanges}} rendered nothing at all - not even its own "No changes!" fallback. This affected every change list in the application (release note pages, custom reports), not only the comparison filters; it was caught by That is what made {{ReleaseNotesIT#getChangesComparisonFiltersIncludeTheBoundaryVersion}} , which passes pass on 14.10 and failed fail on 17.10.

Fix So this was a latent programming-right dependency that the newer test framework surfaced, not a regression. The fix removes the dependency : read the caller-named variable is now read with {{#evaluate}} , ( the read counterpart of the {{#setVariable}} that {{getChanges}} already uses to publish it ) , which needs no programming right, and resolve {{$topSpace}} is resolved in the macro instead of relying on it leaking in from {{getChanges}}.

Verified with {{mvn clean install -Pquality,integration-tests,docker}} on XWiki 17.10.0: all 6 functional tests pass.