Ability to configure Export UI buttons + more

Hi devs,

We need to have a way for admins to configure which export buttons are visible in the Export UI. For example:

  • Choose if the server-side PDF export is visible vs the LaTeX PDF export (or the new client-side PDF export)
  • Choose if XAR export is visible or not on a given wiki, etc

I can think of 2 solutions.

Proposal 1: Dedicated UI

  • Use a UIX filter (public List<UIExtension> getExtensions(String extensionPointId, Map<String, String> filters)) in the Export UI template.
  • Make that filter take its config from an XWiki Configuration (xobject in a page in the current wiki, fallback on the main wiki, fallback on xwiki.properties)
  • (optional) Provide an Admin UI to list all Export UIX (for the buttons) in a LD and with an action to enable/disable them.

Proposal 2: Generic UI

  • Introduce a concept of enable/disable an UIX (add a method isEnabled() in UIExtension)
  • Modify UIExtensionManager#get() and UIExtensionScriptService#getExtensions() to only return enabled UIXs
  • Provide an Admin UI to list all UIX for all UIXPs in the wiki, in a LD, with actions to enable/disable UIXs
  • The LD would list the UIX id and the UIXP ids in two columns
  • I’d propose to not modify the xproperties of Wiki UIXs so that we have a common way to configure all UIXs whether they’re in Java or in wiki pages. And I propose to use a configuration for this (map). Same as above, xobject in a page in the current wiki, fallback on the main wiki, fallback on xwiki.properties.

Example config:

uixextension.disabled = <uixp id> = <uix id>

Proposal 3: Super generic UI

  • Add the ability to unregister/register components
  • Provide an Admin UI to list all components from the JVM in a LD with an action column to unregister/re-register
  • Since UIXs are components this should allow to enable/disable them but it also allows to do the same for any other components of XWiki (like JIRA does BTW). This is ultra powerful.
  • The LD should have a column showing the component manager in which the component is registered.
  • The less nice thing is that the UI is very generic and the Admin user will need to find what it’s looking for just based on the component role and hint.
  • Note: We would need to store the enable/disable state in the perm dir somewhere and load it at startup so that we re-register only the components that are enabled.

My preferences goes to proposal 3 and maybe 2. I think both could be implemented. Since the configuration of the Export UI is not a major use case, I don’t think we absolutely need proposal 1 (it’s more work), but the 3 proposals could all be implemented as they are complementary. The reason I tend to think that 2 is also needed is to make it easier for users. OTOH the need is a pretty technical one so I’d go for implementing 3 first and then if we have time, implement 2 too.

WDYT?

Thanks