| When the user clicks "Add User Change" (or "Add Admin Change" / "Add Developer Change") on a release note, ReleaseNotes.Code.EntryVelocityMacros's #handleAddAction computes the name of the new entry and redirects to it with:
$response.sendRedirect($xwiki.getURL($versionPageReference.toString(), 'inline', "..."))
inline is a deprecated action that only exists in xwiki-platform-legacy-oldcore. On a wiki built without the legacy module, inline is not a known action, so /xwiki/bin/inline/ReleaseNotes/Data/<Product>/<Version>/Entry001/WebHome is parsed as a view of a document in a top level space literally named inline. The user lands on "The requested page could not be found." instead of the form for the new change, and cannot add a change at all. This does not show up on the standard XWiki distribution, which ships the legacy module, but it does on any installation without it — and the action being deprecated, it may eventually disappear from there too. Note
- The application already uses the modern form elsewhere: the "Add contributors" button of ReleaseNotes.Code.ReleaseNotesContributorsMacro goes through $contributorsDoc.getURL('edit') with editor=inline. #handleAddAction should do the same.
- ReleaseNotesIT#changeNumberingIgnoresContributors does not catch this: it only asserts that the resulting URL contains Entry001, which is still true when the URL resolves to the wrong document. Fixing this should also strengthen that assertion.
Found while working on RN-9, whose functional test has to use edit?editor=inline for this reason. |
