Administrative Console – Product Requirements Document (Draft)

Administrative Console – Product Requirements Document (Draft)

A central space to gather user input, data and requirements for the Administrative Console MVP.

1  Overview

1.1  Purpose

This console aims to centralize platform-level settings and administrative tasks—including roles and permissions (AuthZ) and, eventually, other key configurations—into a single, extensible UI. It reduces platform fragmentation and improves administrator efficiency.

1.2  Background & Context

Currently, Open edX administrators must rely on multiple disjointed tools (e.g., Django Admin, CLI, config files) for platform management. This situation results in overly broad permissions for simple tasks and inconsistent workflows. This MVP is the first step toward solving that by delivering a foundational admin console with RBAC support for Libraries as the first iteration of the tool.


2  Problem Statement

There is no unified interface for day-to-day platform administration. Basic operations require high clearance or technical skills, and platform extensions lack a consistent configuration entry point. This increases operational risk and limits flexibility for institutions.


3  Goals & Objectives

3.1  Primary Goals

  • Unify platform‑level administration in a single console.

  • Support AuthZ management in MVP; design for future settings (user groups, 3rd‑party integrations, etc.).

  • Provide an extensible foundation.

3.2  Success Metrics / KPIs

  • Reduction in superuser assignments for common admin tasks.

  • Qualitative feedback from pilot users (admin efficiency, ease of use).


4  User Personas & Use Cases

4.1  Personas

WIP

4.2  Key Jobs‑to‑Be‑Done (JTBD)

  1. Grant or revoke roles & permissions without leaving the console.

  2. Audit recent privileged actions?

  3. Configure external services (future).

WIP


5  Scope

5.1  In Scope (MVP)

  • AuthZ management (view, assign, revoke roles for Libraries).

  • Filter users by role and scope.

  • View list of available roles.

5.2  Out of Scope (MVP)

 

  • Configuration of services outside of RBAC.

 


 

6  Requirements

6.1  Functional Requirements

  • Display all users with roles in Library contexts.

  • Assign roles within allowed scopes.

  • Modify or remove existing role assignments.

  • Display list of available roles and their permissions.

  • Filter by scope or role.

6.2  Non‑Functional Requirements

  •  

     

 


 

7  Extensibility & Integration Needs

  •  

 


 

8  Architecture & Technical Constraints

8.1  MVP Architecture Decisions

  •  

     

8.2  Long‑Term Vision

  •  

     

 


 

9  UX/UI Considerations

  • Focus on utility, visibility, and clarity.

  • Prioritize readability of roles and scopes.

  • Future-proof design for extension of the dashboard.

  • UX/UI design to begin after architectural spike.


 

10  Milestones & Timeline

Milestone

Description

Target Date

M1

Architecture Design Spike

 

M2

UX/UI Design Spike

 

M3

Hi‑Fi MVP Screens & Handoff

 

 


 

11  Risks & Assumptions

  • Unclear location (Studio vs new UI) could delay frontend work.

  • Community plugin expectations exceed MVP scope.

 


 

12  Open Questions

  1. Which platform settings are highest value to expose in MVP besides RBAC?

 


 

13  Dependencies

  • Backend RBAC system (Grants, Roles, Scopes, Permissions).