Console M1: Laying the Console Foundation - Architecture Design Spike

[MaferMazu]

Define the architectural design for the Administrative Console.

Spike 1 - Foundation, evolution, tech stack - task link
Spike 2 - Pluggability & extensibility - task link
Spike 3 - Integrations with Open edX Ecosystem - task link

Context

• Administrator console for Open edX
• Administrative Console – Product Requirements Document (Draft)

Produced documentation

• Technical Approach: Administrative Console

[mariajgrimaldi]

Here is the proposal for the long-term architecture of an administrative console, with these objectives:

• Implement and iterate quickly to allow experimentation
• Gather feedback early
• Be open to extension and closed to modification, with a small core that supports strong extensibility across the community
• Reuse existing technologies

https://openedx.atlassian.net/wiki/spaces/OEPM/pages/5120196610/Long-Term+Technical+Approach

To address more immediate needs, such as authorization for Ulmo, we decided to treat the console as an iterative project with a phased rollout. The first phase is the MVP, focused on managing authorization requirements and testing the location and concept of an administrative platform for admins and operators.

The console’s vision goes beyond authorization. The architecture aims to solve more complex use cases, but these will not be part of short-term iterations. The main goal of this proposal is to gather enough community feedback to build a shared understanding of what the console should be and how it should evolve.

[dcoa]

The Administrative Console PRD and technical approaches lives here: Administrative Console Folder

We’ve recently integrated the feedback related to both the short- and long-term approaches for the console, and we believe the documentation is now in a solid state. We’d like to propose moving the documentation towards final approval and pass the associated card to done. To ensure everything is aligned, we suggest a final review cycle, if needed, between now and 27 August.

Looking forward to hearing your thoughts! @gviedma-aulasneo @jmakowski1123 @sarina

[sarina]

Took a pass on this. cc @rodmgwgu to review as well.

[rodmgwgu]

Added some comments in the wiki, overall matches what I've seen on the needs for this Administrative Console.

My opinion is that, long term, we should leave the Django admin only to developers and highly technical people. For day-to-day operations, everything should be done from user-friendly UIs, that implement clear validations and permissions to avoid breaking the platform, and guide the users on the actions they may want to make.

[dcoa]

Thank you @rodmgwgu, do you have any extra comment for the technical approaches?

[rodmgwgu]

I'm aligned with the phased approach that is being proposed, however I still have some questions on details for the long-term approach, but it may be too early to define these as there are unknowns that should be ironed out as we advance.

Some points on the long term approach that I see:

• On the frontend plugability: I recently attended a call where the new frontend-base approach was being discussed, there I learnt that the new approach seeks to bundle all MFEs in one bundle at build-time. This will affect this, as in my understanding, for a full Marketplace integration we would like these bundles to be installable at run-time, which is incompatible with the new frontend-base approach. The alternative would be to deploy these pluggable frontends as a separate bundle, which would be still supported by the new frontend-base approach, but we would lose some of the advantages of this approach.
• On the backend and tutor plugability: this will probably require some work to reach the same level of pluggability, I'm thinking specially about some of the configuration variables, as there are some tutor plugins that require changes at build time, or at deploy time - this would need to be clearly differentiated and mechanisms would be needed for a better configuration management that doesn't require injecting variables into python code as it's done currently - but this may be part of a bigger discussion, do you know if there is any initiative on this matter?

[rodmgwgu]

The new frontend-base initiative also bring another question: For this MVP, will we implement the new panel views on the authoring codebase after it's upgraded to frontend-base? or over the current state?

I'm guessing the latter, as I don't see the Authoring MFE being ported to frontend-base in time before the Ulmo release

[sarina]

For this MVP, will we implement the new panel views on the authoring codebase after it's upgraded to frontend-base? or over the current state?

I'm guessing the latter, as I don't see the Authoring MFE being ported to frontend-base in time before the Ulmo release

Yes, this will not be frontend-base native