Investigate how we can make the main menu bar more configurable

[NuclearRedeye]

Description

There are now a couple of use cases that have come up that would require the main menu bar in editor-client to be customisable, so that integrators can customise the functionality exposed to the user to suit their specific needs. PKP for example would like to be able to add a 'return' control that a user could use to navigate back to OJS. eLife have another use case where we would want to hide the PDF button and replace it with a publish button.

To start with, we would like to be able to...

• Remove buttons
• Add buttons
• Customise the appearance of buttons, e.g. supply a custom SVG icon.

We also might want to consider...

• The order of the controls in the menu bar.

Definition of Done

• [ ] Recommendation or PoC, shared with stakeholders, on how to customise the menu bar in editor-client.

[will-byrne]

There is a prototype / POC here

This allows for the menu to be customised as per the requirements with custom svgs and the configuration file being provided in the public folder

[NateWr]

Thanks @will-byrne! This looks great and very easy to use. :+1:

I notice that the custom buttons only permit a url to be passed that will result in a GET request. This satisfies our use-case (PKP), but may not satisfy cases where someone wants to send a POST or PUT request with some payload. Are there risks associated with using a JS configuration file and permitting a callback function to be passed?

[will-byrne]

There would be the standard security issues with JS on the web in that people could modify the post request or alter the callback in the browser. It would be better for the callbacks to be loaded in at build time so they can be obfuscated / minified with the rest of the JS.

The biggest issue would be securing the configuration file. I would recommend that a new docker image be created using the editor one as a base which just copied the configuration file to the new image in the correct place.

The code could be modified to allow any POST, PUT, or any other HTTP method as long as the endpoints are sufficiently secured, the difficulty would be in generating the payload.

[NateWr]

Ahh, right, of course. :) Well, anyway, this satisfies our requirements. But one idea to throw out there is to maybe pair this with #839 at some point, so that it might be possible to inject the config object into the App at run-time. We won't be running libero off of docker. We'll be mounting the client to the dom in our own application. So that would be the obvious place for us to (safely) define configuration callbacks.