openedx / openedx/openedx-core

Implement Media Asset Management as a first class entity

Open
#499 16 comments 4 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

arch data model
Dominant language
Python
Stars
10
Forks
32
Avg merge
2d 17h
Merged PRs (30d)
12

Description

This feature was originally proposed by @holaontiveros and @rodmgwgu, in a workshop session during the Axim/WGU dev summit in Feb '26, though I'm reframing it somewhat here. All of this is subject to Product approval, of course.

Use Cases

Western Governors University uses a Digital Asset Management System for its various media files. This serves to provide a centralized, searchable repository of such assets, as well as providing a way to remove assets if it becomes necessary for copyright reasons. In their current deployment of Open edX platform, WGU stores nothing in course Files and Uploads, and uses links for all assets.

The goals for this would be:

  1. Create a system that allows for centralized Media asset management in Open edX Platform.
  2. Allow for pluggable integration with external digital asset management systems, where libraries contain local references and metadata, but the actual asset is stored and served via that external system.
  3. Use this foundation to re-platform course Files and Uploads on top of openedx-core, and help to unblock the migration of course data.

Non-goal: We are not trying to grow Open edX Platform to be a first-in-class Digital Asset Management System. We basically want our platform to be good enough for the 80% use case that includes centralized management for copyright reasons, as well as being able to serve assets at scale.

The current state of media files in openedx-core

We currently support the storage of media assets with the media applet in openedx_content. However, the media app is a very low-level system, and only really gives us blob storage. The only place where media assets can be leveraged by end-users is through the components applet, which has models that map a particular component-local path name with a corresponding media file, e.g. static/diagram.webpMedia:

https://github.com/openedx/openedx-core/blob/848f6633fa4d1c8ede8db90c22a6d4eab485acf9/src/openedx_content/applets/components/models.py#L226-L250

(Note: the comments say "Content" here, when they should say "Media"--I missed this in the refactoring.)

High Level Proposal

  1. Create a new assets applet in openedx_content.
  2. Create a new publishable model called Asset.
  3. Design it such that Assets can be backed either by local file storage via the media app, or act as local references to external digital asset management systems.
  4. Use Assets as the basis for course Files and Uploads.
  5. Use Assets as an alternative method of storage for Components that want to store media. An Asset would become a publishing dependency of the Components in which it is used, giving us a similar version vs. side-effect semantics as we currently have with container parents and children.

Open Questions

  1. Would we migrate current component/media associations in libraries to use assets, or allow for both modes?
  2. What sort of access control is practical on the LMS side?
  3. How will namespacing work, e.g. importing multiple courses into the same library without causing collisions?
  4. How are assets addressed? Many DAM systems have the notion of an Asset having multiple files, e.g. different formats, encodings, translations, or sizes of the same logical asset.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the openedx_content media applet and the component associations in src/openedx_content/applets/components/models.py#L226-L250. Before implementation, resolve the listed questions about migration, access control, namespacing, asset addressing, and Product approval; done would require an agreed design for the assets applet and Asset model.

Written by the indexing model from the issue text.

Assessment

Tech stack
django, python
Domain
backend, databases
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.