Closed oanalavinia closed 8 months ago
This will also be of help for those that use custom groups instead of the standard XWikiAdminGroup
and XWikiAllGroup
. These users do not benefit from the fixes of #155 #156 (they need to specify manually the name of their custom groups)
As far as I understand the fix for this issue, it's basically bringing back issues #155 and #160 for all the cases when the user upgrades one of their Pro applications to a version that depends on Licensor 1.25 without updating the other Pro apps to a version that was updated to use Licensor 1.25 (the new style of validating licence introduced by this ticket).
@oanalavinia can you confirm that this is correct and this situation can arrive?
@lucaa Yes, this can happen if indeed there are apps that were not upgraded, while the Licensor was.
The old fix, with the rights object on the VelocityMacros page, was changed because there are cases were the XWikiAllGroup
or XWikiAdminGroup
are not used
Since not all pro apps have this issue reproducing, and also not for all of them is a problem (e.g. the error is displayed on the app homepage that is not used, or shouldn't be accessed by non-admin users), I am adding below the list of apps and the fix version, by category.
Error displayed while using the macro / app:
Error displayed only on the application homepage:
Error displayed on the app administration page:
For displaying the
There is no valid license for..
message on each licensed application, right now we have 2 macros getMissingLicenseMessage and getMissingLicenseMessageHTML from theLicenses.Code.VelocityMacros
page. E.g. of usages on diagram and pdfViewer The problem with this is that we need to explicitly give view right for theVelocityMacros
page, to avoid issues like https://github.com/xwikisas/application-licensing/issues/155The proposal is to have a rendering macro that will be registered without this view right (like it happens with translations) and use it
{{missingLicenseMessage extensionName="diagram.extension.name" /}}
We should also investigate a solution for the usage in pdfViewer, maybe to specify that the template uses wiki syntax by adding
##!source.syntax=xwiki/2.1
, such as in here.