There is 1 comment.
 
 
Release Notes Application / cid:jira-generated-image-avatar-fcecbfaa-aed8-40ca-92c8-648463aa209d RN-71 Closed

Editing the configuration page requires force editing

 
View issue   ยท   Add comment
 

1 comment

 
cid:jira-generated-image-avatar-1fd734d5-9890-44c4-922d-fac58e389a69 Vincent Massol on 29/Aug/26 21:40
 

Reverted in 2.4.1

The fix for this issue has been reverted by RN-78.

The configuration XAR entry type does solve the force-editing problem reported here, but it has a second effect: it maps to UpgradeType.SKIP_ALLWAYS, which the Extension Manager implements as "only install the document, never upgrade it". The page is frozen at whatever an install first received, whatever it contains.

That became a bug as soon as RN-73, in the same 2.4 release, registered the application in the wiki Administration by adding an XWiki.ConfigurableClass xobject to that same page: the xobject only ever reached fresh installs, and upgrading an existing wiki to 2.4 left ReleaseNotes.Code.ReleaseNotesConfig untouched, with no Release Notes entry in the Administration.

The underlying mistake is that this page holds both administrator data (the product and template values) and application structure (the XWiki.ConfigurableClass xobject and the xclass definitions), and the configuration type freezes both. A survey of xwiki-platform confirms the type was the wrong tool here: all 49 pages that carry an XWiki.ConfigurableClass xobject use the default entry type and not one of them is declared in an <entries> block, while configuration appears on only three declarations in the whole code base (XWiki.XWikiAdminGroup and XWiki.XWikiAllGroup), which are pure-data pages carrying no application structure.

The concern stated in the "Fix" section above, that an upgrade must not overwrite the configuration an administrator set, is still met from 2.4.1 on: it is the 3-way merge of the default entry type that preserves those values, instead of the page being frozen. The merge additionally lets structural changes reach wikis where the application is already installed, which is what was broken.

As for the problem originally reported here, it is now solved by RN-73 rather than by the entry type: administrators configure the application from the Administration, which saves without going through the page editor, so they no longer have to open ReleaseNotes.Code.ReleaseNotesConfig at all and no longer meet the warning. Editing that page directly does show the "part of an extension" warning again.

One documentation follow-up on Configure the Release Notes Application: its FAQ entry "Will an upgrade of the extension overwrite my configuration?" currently answers that "the configuration page ships as a configuration entry of the extension, which an upgrade never overwrites". The answer stays "no" for 2.4.1, but the reason no longer holds and should be reworded: the values are preserved by the 3-way merge of the default entry type.