Make toolbar / waffle configurable

[rvveber]

Feature Request

openDesk wants to have a universal Header to access any openDesk applications and Account settings from.

Currently all applications integrated in openDesk need to implement it individually.

It should look like this:

The specification of what functionality needs to be implemented is currently beeing discussed and this issue will be updated later.

Anything that could benefit other users and contribute to the general whitelabeling of Docs, should go into the main branch.
All customization in regards to openDesk should go in the main-opendesk branch for now.
Maybe a Fork with openDesk customizations would make sense in the future.

[virgile-dev]

@rvveber For me it doesn't really fit in the generic product and could even be a customization layer that admins have to make on their deployment repo.
A middle ground would be make this so that's something that is configured by the admin sys who deploy the product.
@AntoLC What are your thoughts on this ?

[virgile-dev]

here is an example of how we did it in another project :
https://github.com/openfun/fun-richie-site-factory/tree/main/sites/ademe/src/frontend
https://github.com/openfun/fun-richie-site-factory/blob/main/sites/ademe/src/frontend/overrides.json

[rvveber]

Thanks! Overriding a single component seems like flexible idea!

So after some more exploration it looks like we just need this app menu, next to the logo.

Since we can already change logo (red) and colors via theming, i would wrap the docs title in a component (purple)

that we would replace in our deployment to be the app menu instead.

For Docs itself, that wouldn't change anything.
Just encapsulating the title into it's own <Title /> component.
And i would work on providing an overriding mechanism, similar to what richie-education has implemented.

What do you think?
@AntoLC @virgile-dev

[rvveber]

@virgile-dev After looking into it a bit more, it is not as easy as i thought it was.

I couldn't find a way to override at runtime, like import a module only if it exists.

And we can't really override at build-time because kubernetes will use the image that is already built, compiled and without the source to build on.

Maybe we really need the intermediate location, similar to the site-factory mentioned above.
And there.. we will pull this repositories latest release and apply a patch?
I'm not sure yet.

[virgile-dev]

I really think we should do all these config at build time.
With Docs, we are not in the scenario of ZenDis working with an software editor, DINUM and ZenDis are the editors.
So I strongly recommend having a deploy repo or subrepo with all configs and overrides (the toolbar, i18n custom strings).
Especially since OpenDesk will be deployed by ZenDis to several clients with different requirements. We want Docs to remain generic so as many contributors as possible can join.
Happy to join in a call to discuss this whenever.