...

Future direction and technical debt

1. When the Course Blocks API is used (e.g. for mobile, the Progress page, and the new grading code) to retrieve the structure of a course that includes Randomized Content Blocks, if the randomized selection of a problem has not yet occurred (because the learner has not viewed that unit in the LMS), then a new selection is made for the current learner but is not saved, and will change every time. This is because the Course Blocks API does not allow XBlocks to save changes they've made to their fields, and the Randomize Content Block saves the selection into an XBlock field. (See this TODO in the code.)
2. Libraries currently cannot store assets (e.g. images), which is a big limitation. (See also GridFS Replacement.)
3. When editing a component that was sourced from a library, authors cannot tell which fields are Scope.content fields (changes will be lost when updating the parent Randomized Content Block with the latest version of the library) and which fields are Scope.settings fields (changes are considered course-specific overrides and are preserved when updating the Randomized Content Block). The Scope.content fields should be disabled and authors should be prevented from editing them within the course.
4. We need a new XBlock like the randomized content module, but allowing manual selection of one or more components from the library, instead of random selection. This was part of the original plan but was cut from the MVP.
5. We need a way to tag content in the library (e.g. align with a taxonomy) and then have the randomized content block only draw problems that match certain criteria (difficulty, topic, etc.). This can also be the basis of adaptive learning features.
6. Currently, content libraries support a very limited subset of XBlocks. More types of XBlocks should be tested and enabled for use in content libraries.
7. The Library Content XModule (Randomized Content Block) should be converted to an XBlock. This is currently not possible because it depends on the following methods which are part of the XModule API but not the XBlock API:
   • get_child_descriptors()
   • has_dynamic_children()
   • get_content_titles()
8. Libraries do not currently have a draft/published workflow, though the basic support for that exists in the split modulestore, analogous to courses.
9. Libraries can support nested structures and can hold chapters, sections, units, etc. However the studio UI does not provide a way to do this. It could be interesting to explore use cases where authors have access to a library of course units or chapters and can build new courses by combining existing units or entire chapters that are sourced from a library.
10. Enable search and filtering of content library content in the Studio UI and the Randomized Content Block UI
11. If a course contains two randomized content blocks that each select one problem from the same library, there is a chance the student will have to do the same problem twice. It would be cool to prevent such duplicate random selections from happening, but is likely not worth the trouble.
12. Brian Wilson suggested: Eventually, "research and course design teams may wish to be able to have access to scores, aggregated on a single [library component] across courses."
    • This may be easier to implement once the Robust Grades work is completed.
    • The tracking log events emitted by any blocks that were sourced from a content library already emit a "context" section that includes the original_usage_key and original_usage_version fields, which are required to identify library components across courses (see documentation).
13. Authors should be able to move/copy a component from a course page into a content library.
14. Support for external content libraries could allow a central repository of content, used by multiple Open edX instances.
15. There seems to be a bug in XModuleMixin's location.setter: it sets def_id and usage_id to the same UsageKey value, but def_id should not be a UsageKey and should not be the same as usage_id in general. The code should use .runtime.id_reader to get the definition key. It's unclear why this bug isn't causing more problems, or if fixing it will cause any issues - this needs investigation.

16. Jira Legacy
    server JIRA (openedx.atlassian.net) serverId 13fd1930-5608-3aac-a5dd-21b934d3a4b4 key TNL-5947