You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
Following up on #34066 ...
Tasks
def_keyfromLibraryXBlockMetadata(does this require frontend code changes?)content libraries misctickets: https://github.com/openedx/edx-platform/issues?q=is%3Aissue+is%3Aopen+label%3A%22content+libraries+misc%22get_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.content_library.learning_package is None