View the Github ticket for proposal status updates

Overview:

The proposed project involves the creation of an administrator console for the Open edX platform, a dedicated interface for site administrators to manage and configure their Open edX instances. While the platform currently provides LMS for learners and Studio for course authors, there is a gap in the administrative capabilities that calls for a separate, user-friendly console.

Problem

There is currently no unified place to manage configurations and day to day operations, and some of these things need to happen anyways, leaving the administrator with a scattered set of mechanisms, including altering model records via the multiple Django sysadmin consoles, doing things via Command line interfaces, changing configuration files and redeploying the applications etc. For some important operations there isn't even a way of getting things done. This increases complexity, limits adoption and success with the platform.
Regardless of how it is done, you currently need superadmin permissions to make any configuration changes, and this is too much clearance in some cases. For example, in order to unlock a user that for some reason did not get the activation email, you need to have staff access and this ends up in a situation where there are many users with unnecesary broad levels of access.
Some of the functionality or additional extensions that are built for the platform will need a place for their platform level configurations to be handled, and since this currently does not exists, different solutions will try to solve this need in different ways, adding unnecesary complexity to the platform and reducing the likelihood of adoption.

Key Use cases

As a platform administrator I need to see the status of my platform at a glance in order to understand the landscape and identify improvement opportunities, for example see what release is currently running, what xblocks are installed, where is the studio application parked, whether or not it has Aspects/discovery/credentials and where are they it parked, what theme is being used, branding package, paragon variables, etc.
As a platform administrator, I need to be able to discover the different global settings options and be able to change them in order to optimize the adaptation of the platform to my specific needs.
As a platform administrator I need to be able to configure and reconfigure some of the features in the platform without the need of redeploying the application, this increases exploration and usage of the advanced features and increases overall efficiency.
As a program manager, I need to create new organizations or manage the existing ones and also configure the certificate templates applied to each organization.
As a program manager, I need to grant my instructors with course creation permissions or remove course creation permissions for users that should no longer have them.
As a program manager, I need to check what courses a particular instructor is assigned to in order to be able to oversee their activity.
As a program manager I need to be able to do certain day to day operations with my user records in order to be able to support users and maintain control of the operation, for example, force reset a user password, activate a user manually, unlock users after they have tried the wrong password too many times, process account removals, batch import user accounts, etc.
As a program manager I need to be able to access some aggregated reports about the operation of the courses under my administration.
As a platform administrator I need a place to find and manage some key admin operations such as viewing the status of async tasks, checking for security updates, viewing the application logs, running django commands, etc. This allows me to efficiently manage the platform, resolve issues, maintain data security compliance and more.

Supporting market Data

At eduNEXT, we have worked with a diverse range of initiatives trying to adopt the open edX platform over the span of 10 years, including companies, NGOs, universities, and independent sites. Across these different types of organizations, a common challenge has always been identified, administrators consistently struggle with managing their Open edX sites effectively. Even basic configurations, such as student management, present significant challenges. Part of our business model has been to sell our support services to help them overcome these challenges, but you can argue that this model makes a pretty bad experience for adopters or the Open edX platform, making it inefficient and costly, and contributing to the high rate of initiatives that desist after a while.

An advantage of this approach is that everything our customers request assistance with becomes a ticket that is classified into a special taxonomy that we built, and we have processed over 27000 tickets to day, which has given us a lot of insight into the kind of things that are needed and how they are prioritized.. Here are the analysis of some specific items in the taxonomy that received the most requests in the past year:

This broad category took about 27% of the support requests, 16% related to LMS users issues and 11% related to Studio permissions. the most common stories in this category are:

granting / removing course creator permissions to a user
granting course staff permissions to a new user that joined the team or removing them to one that leaves.
activating learners that despite having the correct email do not receive the activation email
assisting a user with resetting a password
assisting users with changing email addresses
Deleting user accounts

This category gets about 13% or the total number of requests, and we often confirm during user interviews that Certificates are very important.

For learners, they attest the completion of the course.
For administrators, they can be one of the main metrics of the accomplishment of learner goals and is often coupled with the business model that the initiative is using to support the operations.

Most of the challenges with certificates happen at the administrator level: certificate templates per organization, certificates in multiple languages, gating configurations to be able to access certificates or not, reporting on the total numbers of certificates issued and the specific certificates issued, allowing to integrate certificates with external tools like digital credentials, linkedin, etc.

Example tickets:

“The sender is seeking advice on customizing a certificate template.”
“I am reaching out to request assistance with editing a certificate template.”
“We would like to implement the ‘effort_hours’ attribute in our certificates and need assistance with this customization.”
“I am currently working on creating a certificate template and would like some guidance on how to edit specific sections.”
“Dear colleagues, Please replace the certificate template with the new design provided in the attachment.
“Hello! I worked with you to have a custom certificate created, but it seems there is an issue.”
“Hi team, The customer has requested to create a new certificate for their course.”
“Hi team! The customer has requested to add a new certificate template for their program.”
“We request, if possible, that you create a custom template for our certificates.”
“Hi team, The customer has requested to add a new certificate for their training module.”

Other part of the challenges with certificates happen at the course level: configuring a course to offer certificates, configure that particular certificate for the course if needed, issue certificates, etc. These needs will probably best served in the instructor dashboard or Studio. and not the administrator console.

Nearly 11% of all requests where related to reports and accessing information, for example:

Getting platform level metrics overview
Getting platform level reports
Getting assistance with the existing course level csv reports
Custom queries to the database for specific purposes

Proposed solution

Overview

The use cases for an administrator console are very diverse and we are not proposing a single project will address them all. The first thing we are proposing is to have a centralized and extensible place for all these use cases to be addressed.

We refer to this place for now as the “administrator console”, but even the name can be iterated and improved.

Key elements of the proposed solution are:

It leverages the core + extensions framework, so There will be an “admin core” first, that will be ideally part of the core open edX product, and a number of “admin extensions” that certain Open edX operators may want to leverage, as well as the possibility built in from the get go, to build your own “admin extensions” when needed (We envision that the code to add your admin extension is co-located with the code of your extension.)
Here are potential examples of “admin extensions”, in no particular order:
- an extension to add learner management capabilities to the admin core.
- an extension to add certain reports to the admin core
- an extension to add Aspects charts or dashboards to be integrated into the admin core
- an extension to add roles and permissions definition and management (once RBAC goes through)
- an extension to add configurable theming capabilities to the admin core
- an extension to add mass email configuration and sending capabilities
- an extension to add advanced configuration capabilities for a particular extension of the platform (a plugin, an Xblock, etc)
- an extension to allow the discovery and setting of feature switches and flags.
- an extension to centrally manage the available LTI tools course authors can reuse in studio
It will not need to be built all at once. we’ll start with the first version of the admin core and perhaps a few extensions, as well as a well defined set of ground rules for additional extensions to be created later on.
It will leverage Django and APIs for the backend, and React+paragon for the frontend.
It will leverage the platform auth and user models, the way Studio does.
It will allow to integrate other pieces of the extended platform into the administrator experience, for example one “admin extension” could allow certain Aspects dashboards, charts or reports to be served inside the adminstrator console.

Technical feasibility

In terms of “How can this solution be built”, besides what was mentioned in the previous section, here some the initial assumptions and considerations:

The “admin core component will need to have the following capabilities.
- be able to access the different models in lms and studio
- be able to access the different models in all the openedx services (credentials or discovery), to enable the extensions posibilities in the admin console.
- be able to “read” or “be aware of” the settings that are not stored in data models, but in lower layers such as django configs or python package entry points.
TBD - comments and contributions are most welcome

UX / UI considerations

The UX / UI should be simple and convenient for administrators, who are often used to handling this kind of consoles in many other applications.
The UX / UI should be able to accomodate all the flexibility that comes with the “core + extensions” approach.
- Include any UX/UI designs. COMING SOON.
- Proposed plan for any relevant usability/UX testing

Other approaches considered

We explored the possibility of integrating administrative functionalities directly into Studio and / or the LMS. This approach was also dismissed because it would add unnecessary complexity to these platforms, which are already intricate in their own right. By distributing administrative functionalities across Studio and the LMS, administrators would lack a unified and user-friendly interface, leading to fragmented workflows and reduced efficiency. Instead, a dedicated Admin Console will centralize these tools, providing a streamlined and accessible experience.
Another approach we have explored and pursued is to build some of the missing funtionality in our external product, the console we built to deal with our customer dossiers, payments, contracts, etc. We built and shiped a small portion of theses capabilities, but this proved to be on the one hand confusing and even unacceptable for the users, to go to a different platform to make configurations for their Open edX platform, and on the other hand, this approach is not well aligned with the collective construction of a product that serves the needs of all.

Competitive research

In moodle, the LMS, the authoring platform and the administration console are all part of the same web application.

This interface has a search function that filters all the settings by keywords and presents a list of search results that can directly be interacted with, and a save button for applying the changes made in any of the components of the search results page. This eliminates the need to navigate to a different page for each of the components you want to alter.

some of the more elaborated interfaces, even after apperaring in the search results page, will need the user to navigate to a dedicated page, for example this is the page where ad administrator will list and manage users:

a few elements of this interface worth hightlight:

there is a breadcrum navigation to locate this page in the structure of administration pages or go to the parent category
there is the option to manually add a new user
Filters can be applied to the list
each learner listed has an action(s) button (edit)
multiple users can be selected and the same action can be applied to all of them (similar to the way wordpress does)
you can download the list of learners in a number of different formats

other pieces that are also complex will have different intefaces, for example here is how roles are assigned to users:

moreover, some settings can be defined at different levels, with the setting at the parent level being imposed or being the default for the lower level. (example rss enablements TBD).

In Canvas, the LMS, the authoring platform and the administration console are all part of the same web application. In Canvas, a user can be granted “subaccount administration”

Administrators can find a specific user (learner or instructor) and find out what courses they have assigned and the pages they have viewed. They can also email them from the application.

Implementation Plan:

Edunext is commited to drive this proposal through the initial stages, gathering community reviews and support or critics as part of its core contribution commitments.
As the proposal gains traction and it is improved with all the community reviews and comments, we'd hope that Axim considers to commit some FC resources to speed up its development.
Over time, as it has been the case with other parts of the platform, we plan for the core - extensions framework to be the right environment in which other adopters of the open edX platform that want to accelerate innovation and specific features will also contribute funding or technical resources to build and maintain additional admin extensions.

Plan for long-term ownership/maintainership

TBD - comments and contributions are most welcome

Open questions for rollout/releases

TBD - comments and contributions are most welcome

Authors

Proposal prepared by @Juan Camilo Montoya and @Santiago Suarez . Initial review by @Felipe Montoya

Open edX Product Management

Administrator console for Open edX