|
| Description: |
h2. Steps to reproduce
* Create a page holding an {{XWiki.WikiMacroClass}} object whose {{visibility}} is {{Current Wiki}} \(the default\), with some Velocity in its {{code}} property.
* Open "Information" > "Review required rights" and read the recommendation.
* Select the recommended right, enforce it, and save.
* Look at a page that uses the macro.
h2. Expected result
The analysis recommends _Wiki Admin_, because that is the right the document author needs for the macro to be registered at all.
h2. Actual result
The analysis recommends _Script_, which is only what the macro's body needs. Enforcing it caps the document author below what registration requires, so the macro is silently never registered and every page using it renders {{Unknown macro: }}. Nothing in "Analysis Details" hints at the cause, and the page that breaks is not the page that was edited.
h2. Why
{{DefaultWikiMacroFactory.isAllowed}} checks, against the _macro document's author_, {{Right.PROGRAM}} for {{Global}} visibility and {{Right.ADMIN}} at {{EntityType.WIKI}} for {{Current Wiki}} visibility. That has been the intended behaviour since XWIKI\-7880.
The analyzer never learned about it: there is _no_ {{RequiredRightAnalyzer}} registered for {{XWiki.WikiMacroClass}}. The only one the module ships is {{WikiMacroParameterObjectRequiredRightAnalyzer}}, for {{WikiMacroParameterClass}}, which analyses the parameter's wiki content. So a {{WikiMacroClass}} object falls through to {{DefaultObjectRequiredRightAnalyzer}}, which reads the object's wiki\-content properties, sees the Velocity in {{code}} and stops at Script.
The two analogous cases _are_ handled, which is what makes this easy to miss:
* {{UIExtensionRequiredRightsAnalyzer}} maps a UI extension's {{scope}} to wiki admin, and even carries a dedicated message for it \({{uiextension.requiredrights.wiki}} / {{uiextension.requiredrights.global}}\);
* {{TranslationDocumentObjectRequiredRightAnalyzer}} does the same for a wiki\-scoped translation bundle.
h2. Suggested fix
A {{RequiredRightAnalyzer}} for {{XWiki.WikiMacroClass}} that reads {{visibility}} the way {{UIExtensionRequiredRightsAnalyzer}} reads {{scope}}: report wiki admin as required for {{Current Wiki}} and programming right for {{Global}}, in addition to whatever the macro body needs. Registering it under the class\-name hint is enough to stop the fall\-through to the default analyzer.
h2. Verified on
Checked by reading the shipped jars of the {{jetty\-hsqldb}} flavors of _17.10.9_ and _18.6.0_: in both, {{META\-INF/components.txt}} of {{xwiki\-platform\-legacy\-rendering\-wikimacro\-store}} declares only {{WikiMacroParameterObjectRequiredRightAnalyzer}}, and no other module declares an analyzer for {{WikiMacroClass}}. The behaviour is therefore present in the current LTS line and in current dev. It has most likely been there since required\-rights analysis was introduced; 17.10.9 is simply the oldest release I confirmed rather than the oldest affected.
h2. How it was found
In xwiki\-contrib/application\-releasenotes \(RN\-111\) the analyzer was asked page by page over the {{requiredRights}} REST resource and its recommendation applied verbatim. It reported Script for all five of the application's wiki\-visible macro pages; the resulting build failed 6 of 10 functional tests with {{Unknown macro}}, and the cause was invisible both to {{mvn install}} and to a local wiki that already had the macros registered from an earlier install. See [https://github.com/xwiki\-contrib/application\-releasenotes/pull/51|https://github.com/xwiki-contrib/application-releasenotes/pull/51] for the diagnosis.
|
|
