Manage components/features at runtime

[unteem]

Feature Request

We should be able to activate or deactivate the components and feature at runtime

At the moment those are:

• La Gauffre (possible at buildtime)
• Proconnect button (possible at buildtime)
• AI (already possible with AI_FEATURE_ENABLED)
• Homepage vs go straight to login
• Footer (already possible if FRONTEND_PATH_JSON_FOOTER is not set)

Currently the way we can customize is not entirely consistent between what can be done at build time and runtime and how some components/features can be disabled or enabled.

La Gauffre and Proconnect can be disabled at build time but we should be able to do it at runtime. For instance as hosting provider I may want to activate proconnect for some of my users without needing to manage multiple themes at build time.

While AI can be enabled with AI_FEATURE_ENABLED, the footer can be disabled if FRONTEND_PATH_JSON_FOOTER is not set. This is not a big issues but is a bit inconsistent. AI could be enabled only if AI_BASE_URL is set.

Describe the solution you'd like
Option 1:
In Docs everything is done through environment variables so we would need new environment variables for each of those components or a single variables for instance COMPONENTS_ENABLED which contains a list of strings.

Option 2:
Ideally a json with all Docs config would be better than environment variables which will get messy at one point vs structured data in json.

In the end those variables ends up in a json, so maybe we can already override it if we mount our own custom json ?

Priority: Add a way to disable Homepage and go straight to login

[rvveber]

I would like to implement Option 2.
Can it be assigned to me?

[unteem]

I had a quick chat with @AntoLC about this, they have something in mind. Plan would be to have configs in the database in a table site_config, it would enable app administrators to configure it in the Django Admin interface.

I don't know how @AntoLC would like to proceed with this, it would need some synchronization to make a clean implementation.

I'm all in favor of a clean json config file on my side :), there is already too much environment variables it will be a mess to manage and document it all. With a structured json that would be a lot easier and we could make a schema to type it etc. we could even explore cue for that.

[AntoLC]

The frontend configuration is already a json:

{
    "AI_FEATURE_ENABLED": true,
    "COLLABORATION_WS_URL": "ws://localhost:4444/collaboration/ws/",
    "CRISP_WEBSITE_ID": null,
    ...
}

Seems more backend related so.
JSON keys backend side would have to be documented as well.

Ideally for you, how would it be backend side so ?

[rvveber]

I'm currently developing a PoC based on the approach above.
I'm doing it for the Footer because i think it is the best example for this.

[rvveber]

After some thoughts, discussions, and experiments, i am revoking my proposal above.

I think it's better to define the configuration schema in the backend — even for frontend-specific config. Mainly because when a user sets up their frontend through an admin interface, they expect their config to survive schema changes. that means we need proper migrations.

If the schema is generated (even partially) from the frontend, migration becomes ambiguous and painful.
It's less work for a frontend dev to define/update the schema in the backend upfront — than to deal with migrating frontend-defined data later.

--

We are already generating the openapi spec from the Django backend.
What we can improve though (frontend):
use openapi-typescript and openapi-fetch to auto-generate type generation and fetching utilities.