there is currently a limitation in ConfigurableClass that prevents displaying a configuration section in any space and in the wiki administration (see https://jira.xwiki.org/browse/XWIKI-18723).
This is an old limitation, but this is currently a problem because of a recent regression it’s causing with Like right (see https://jira.xwiki.org/browse/XWIKI-18823): to sum up we used to display the Like right in the standard right UI with a ugly hack, that we removed by introduced the Extension Rights. However, this new section is only displayed in the Wiki administration, because of the ConfigurableClass limitation.
So I worked on that limitation and came up with a solution being a new property
configureGlobally: I performed the changes as part of a PR (see: XWIKI-18723: Make ConfigurableClass support all space and wiki administration cases by surli · Pull Request #1663 · xwiki/xwiki-platform · GitHub), which worked and was applied.
However I had to revert my work because of a migration issue: I wrote two migrations mechanism to move
configureGlobally property to
scope, the first triggered at wiki startup (an hibernate migration), and the other one triggered when an extension is installed or upgraded so that old extension providing a ConfigurationClass would work properly.
But that cannot work because the current mechanism of ConfigurableClass is provided through XWiki documents in
So the current mechanism is the following, we have:
- XWiki.ConfigurableClass: an XWiki document providing both the XClass definition and a velocity script that defines the behaviour of the administration sections (this is what we see when we go to an administration page)
- XWiki.ConfigurableClassMacros: defines some macros used by XWiki.ConfigurableClass and actually the macro using the old
xwiki-platform-administration-ui is only upgraded when the XWiki flavor is upgraded, so only when an admin is following the digital wizard steps. It means that my current hibernate migration is called way before that module is upgraded, and an administration could see the whole administration broken before he upgraded the flavor, since the documents would still use the old
configureGlobally property while the migration would have removed it in favor of scope.
As I indicated, to avoid this I currently reverted my work, however we need to fix this limitation in ConfigurableClass, at the very least to fix the Like right regression without putting back an ugly hack.
I see three solutions for fixing this migration issue:
we don’t migrate the
configureGloballyproperty value and we keep supporting both
scopein XWiki.ConfigurableClassMacros. This is the easiest solution, it means developers would see a deprecated property when checking their old ConfigurableClass until they removed them manually to use scope. Note that in that case, we’d need to define the macro to always gives the priority to
scopewhen both properties are available.
we completely change the logic of Administration application to rely on a MandatoryDocumentInitializer for the ConfigurableClass xclass, and on velocity templates for the ConfigurableClassMacro and for the velocity script contained in ConfigurableClass. This is probably the cleanest solution, but that means a big refactoring, and probably a refactoring breaking the compatibility with previous versions. Now it would be probably cleaner since that’s a mechanism we want in any version of XWiki, so it should probably not be dependent on the flavor. Also this refactoring could allow us to rely on Java components instead of velocity scripts, which would allow to provide better testing.
we keep same code that I committed, but we just change the way we trigger the migration to perform it when the flavor is upgraded first, and then when any extension is installed / upgraded. It probably involved some ad-hoc checks. That’s probably the quickest solution.
I’m personally not a big fan of solution 3, but it would allow to fix quickly the regression we have. IMO it cannot be a long term solution though.
I do prefer solution 2, but that’s something which will have a big impact, especially since Administration Application is an old one, so it can be used in many places, and have had many different customizations.
Solution 1 is probably the safest if we want something working and if we consider it’s not a big deal to have deprecated properties. Now on the long run, the problem will remain.