Ability to configure Export UI buttons + more

Development
1

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 3 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 (if the current user has the permission corresponding to the “extension scope”, otherwise the button will be greyed out).

  • 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>

Note that right now we document https://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/Tutorials/UIXTutorial/#HDisablingsomeExtensionPoints

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

2

Proposal 3 is an interesting feature, but might feel a bit overwhelming for an admin who is just trying to disable an export.

3

I think this is important from a user point of view to be able to achieve an action without having to know/manipulate additional concepts.
In this precise case, an admin should be able to deactivate a specific export without knowing the notions of UIX or Component.

Therefore, I’m +1 for:

At the implementation level, I’m +1 for Proposal 2 and 3. Though 3 can probably be the technical framework for proposal 2 iiuc.

Thanks

4

Thanks.

ofc if we have the time we should do everything.

My POV today is the same as when I wrote the proposal, ie that we should do 3 (even if it would take longer to implement than 1 probably), since it’s the most powerful one and that we will need it one day and if we don’t build on it, we’ll have to refactor more specific code in the future.

Then when we have more time we can work on 2 and then if we have even more time we can work on 1.

Even with just 3, we can document how to disable some Export buttons for an admin. It’d be a bit technical but still doable.

I’m glad to see that so far we all like option 3 and tend to agree it should be the foundation.

Thx

5

+1 for that plan