Create an `openedx_catalog` app with a representation for CourseRuns

[ormsbee]

The Learning Pathways project would benefit from having a representation of CourseRuns in this repo, since the first Pathways will be configured using CourseRuns.

As a migration step, we would push data into this new model from openedx-platform's CourseOverview. At some later point, we can reverse the dependency relationship.

Some high level thoughts/ramblings:

1. We probably want a very small table because it's going to be joined against a lot in the future. Common metadata should go in 1:1 models that we optionally join on. We want to avoid CourseOverview's "just one more field" syndrome, and try to divide up supplementary data into logical pieces like CourseSchedule.
2. For phase one, we only need the minimal set of course data needed for Learning Pathways to query.
3. We could make the initial model more general, e.g. LearningContext, even if we only push the course keys to it for now (and then subclass or 1:1 for CourseRun). I'm not sure if this is really the way we want to go though, because LearningContext feels like it's only a catalog concept by coincidence because of how the system evolved.
4. We should use actual opaque key Django fields.
5. I'm guessing we'll want to use RBAC (opeendx-authz)?

[bradenmacdonald]

Some related discussion in ADR for an edx-platform representation of Catalog Courses #34156

[bradenmacdonald]

Some notes to self from the earlier discussions:

• Need for grouping CourseRuns together:

  • They often re-use 90+% of the same content, which is part of why I'd like to eventually see multiple runs of the same course stored in the same LearningPackage

  • The Studio course listing page is eventually going to have the runs grouped by course.

  • Right now this concept lives in course-discovery but that comes with a lot of baggage that we don't want. Being able to house a core concept in edx-platform and then push a lot of the rest into things that either plugin or otherwise interface with the core bits here seems like it would make the platform more generically usable.

  • be wary of adding too much additional metadata to these CatalogCourses. Can we draw a bright line around what this is meant and not meant to do? Some things that would be red flags for me: ecommerce (including "entitlements"), certificates, programs (probably).

  • We could say that a CatalogCourse model (or virtual model) to group CourseRun's together exists in the core for the purposes of organizing CourseRuns (in Studio), de-duplicating content storage (internally in openedx_content), and providing primitives (models and events) that higher-level apps/plugins can use (programs, ecommerce, enrollment), but which otherwise don't affect core functionality.
• Strong desire for the ability to create CourseRuns (for marketing & enrollment) without any attached content yet.
  • To achieve this, we would likely want/need to move some core metadata (start date, enrollment date, etc.) from the platform's Course XBlock to new models attached to CourseRun. See Dave's prev proposal

    The tricky part in that scenario would be figuring out the migration path and what happens to import/export of those fields that already exist in Modulestore. I think it's totally doable, but there are a lot of details to work out.

  • Product question: would we ever also allow creating re-runs of a CatalogCourse that don't have content attached yet? (And then you could create a completely new version of the course instead of modifying a previous run)

Figure 1: Studio Home Page with course runs grouped together (mockup)

[bradenmacdonald]

We could make the initial model more general, e.g. LearningContext, even if we only push the course keys to it for now (and then subclass or 1:1 for CourseRun). I'm not sure if this is really the way we want to go though, because LearningContext feels like it's only a catalog concept by coincidence because of how the system evolved.

Yeah. If we think of LearningContext as "a context in which we will display learnable content (to learners OR authors) and be able to track user state/grades" (i.e. any context where we render XBlocks), then "content library", "blog post", "course", and perhaps "pathway" are all learning contexts.

If we define this "catalog" app as something like "core data/models to facilitate learner discovery and enrollment into enrollable things", then courses and pathways would be in scope for it, but other learning contexts like content libraries and the (theoretical) "blog post" context would not.