Skip to content

Follow-ups from Learning Core Switchover #34283

@kdmccormick

Description

@kdmccormick

Following up on #34066 ...

Tasks

  • ADR for Public Python API Conventions openedx-learning#186
  • Refactor to authoring package openedx-learning#184
  • Support static assets in the Learning Core runtime #34737
  • Write up a high level description Learning Core openedx-learning#167
  • [DEPR]: Blockstore public-engineering#238
  • Rip out def_key from LibraryXBlockMetadata (does this require frontend code changes?)
  • All content libraries misc tickets: https://github.com/openedx/edx-platform/issues?q=is%3Aissue+is%3Aopen+label%3A%22content+libraries+misc%22
  • Better consolidate some of the runtime related logic. I've written "get the component for this usage key" at least three times.
  • Make Content and file data for content 1:1 by encoding the mime type as part of the file saved... (? though this would make changing mimetypes text much more expensive...) Anyhow, figure this out while implementing static asset support.
  • Figure out what fields are actually needed in the library listing view and optimize the data model if necessary (things like publish status and count are somewhat expensive to aggregate right now). Can be punted if it's not necessary for MVP.
  • See if we can remove some of the computations that would be more expensive from the get_metadata() calls that are meant to operate over a queryset of libraries (things like getting the size of a library, whether there are unpublished changes, etc.)–these queries are fine for any one particular library, but the expense scales with the size of the library, and we probably don't want it in a list view.
  • Figure out how we really want to model the LibraryKey
  • In order to make duplication and import work robustly, write and implement ADRs around the do-not-query-old-libraries-versions decisions.
  • Maybe we can use slugs rather than UUIDs for the UsageKeys of blocks in libraries? We could make them type in the title in a modal when creating a new block, and use a slug of that maybe? We could also allow them to freely change it until they publish (after which we preserve it so that content linking to it doesn't break)?
  • Make get_block return Draft vs Published based on an initialization parameter. Currently it's hardcoded to Draft because we're just supporting CMS for now.
  • Avoid importing from openedx-learning models; perhaps even use importlinter to enforce this. Models we need should be exposed through api.py. Better yet, we should return data objects instead of models.
  • Figure out how to write a get_library_blocks function that returns a queryset of XBlock metadata objects rather than a list.
  • chore: unpin django-stubs now that we're on django 4.2 #34237
  • Remove unnecessary type-ignore comments once ^ merges
  • Remove whole-library version number from REST API
  • Handle cases where content_library.learning_package is None

Metadata

Metadata

Labels

content libraries miscLibraries Overhaul tech work not captured in the stories

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions