The Randomized Content Block XBlock only randomizes the selection of
the children blocks and has unpredictable randomization of
the order of the selected child blocks due to the usage of sets, which
are unordered, for storing the selected blocks. This becomes apparent
when all the available child blocks in a library are chosen for a
Randomized Content Block, to randomize just the order of the child
blocks and not just the selection of the blocks. The order of the
selected blocks ends up being similar for multiple learners.
This change modifies the XBlock to store the selected child blocks in
a list, instead of a set, after randomly shuffling them.
A new block structure transformer, ContentLibraryOrderTransformer has
been added to transform the order of the selected children XBlocks to
match the order of the selections made in the
ContentLibraryTransformer. This ensures that same correct randomized order
of blocks is also returned by the course blocks API.
This also has an initial use case for Personalized Learner Schedules
to add CTAs to capa and vertical blocks to allow users to shift their
course deadlines.
ORA2 (openassessment) problems have multiple dates associated with are
not bound to the `due` date that is modified by Personalized Learner
Schedules. We expose the ORA2 dates separately in the dates page
so that learners aren't surprised by the differing deadlines.
[AA-223]
The Randomized Content Block XBlock only randomizes the selection of
the children blocks and has unpredictable randomization of
the order of the selected child blocks due to the usage of sets, which
are unordered, for storing the selected blocks. This becomes apparent
when all the available child blocks in a library are chosen for a
Randomized Content Block, to randomize just the order of the child
blocks and not just the selection of the blocks. The order of the
selected blocks ends up being similar for multiple learners.
This change modifies the XBlock to store the selected child blocks in
a list, instead of a set, after randomly shuffling them.
This was originally a separate plugin called openedx-olx-rest-api.
It provides a Studio API that any user with course authoring permission can use to get the OLX of an individual XBlock or a unit. Without this, the only way to get an XBlock's OLX was to download the tarball of the entire course.
Examples of usage (be logged in to Studio on devstack):
Simple HTML XBlock:
http://localhost:18010/api/olx-export/v1/xblock/block-v1:edX+DemoX+Demo_Course+type@html+block@030e35c4756a4ddc8d40b95fbbfff4d4/
Exporting a unit:
http://localhost:18010/api/olx-export/v1/xblock/block-v1:edX+DemoX+Demo_Course+type@vertical+block@134df56c516a4a0dbb24dd5facef746e/
Example output for an HTML block:
{
"root_block_id":"block-v1:edX+DemoX+Demo_Course+type@html+block@030e35c4756a4ddc8d40b95fbbfff4d4",
"blocks":{
"block-v1:edX+DemoX+Demo_Course+type@html+block@030e35c4756a4ddc8d40b95fbbfff4d4":{
"olx":"<html display_name=\"Blank HTML Page\"><![CDATA[\n<p><strong>Welcome to the edX Demo Course Introduction.</strong></p>\n]]></html>\n"
}
}
}
The code is designed primarily for use when importing content into Blockstore. So it will:
* Export HTML blocks as a combined OLX/HTML file, with the HTML in a CDATA section
* Convert vertical blocks to unit blocks (unit is like a vertical but has no UI elements)
* Detect static files (such as images) used by the XBlock and list the absolute URL of each static file in the "static_files": {...} JSON element for each XBlock that has at least one static file usage. This can handle static files that are in mongo ("contentstore" / "Files & Uploads") as well as files generated on-the-fly during OLX serialization via the export_fs API (mostly this is video transcripts).
https://github.com/edx/edx-platform/pull/20645
This introduces:
* A new XBlock runtime that can read and write XBlocks that are persisted using
Blockstore instead of Modulestore. The new runtime is currently isolated so
that it can be tested without risk to the current courseware/runtime.
* Content Libraries v2, which store XBlocks in Blockstore not modulestore
* An API Client for Blockstore
* "Learning Context" plugin API. A learning context is a more abstract concept
than a course; it's a collection of XBlocks that serves some learning purpose.
The Randomized Content Block XBlock only randomizes the selection of
the children blocks and has unpredictable randomization of
the order of the selected child blocks due to the usage of sets, which
are unordered, for storing the selected blocks. This becomes apparent
when all the available child blocks in a library are chosen for a
Randomized Content Block, to randomize just the order of the child
blocks and not just the selection of the blocks. The order of the
selected blocks ends up being similar for multiple learners.
This change modifies the XBlock to store the selected child blocks in
a list, instead of a set, after randomly shuffling them.
The Randomized Content Block XBlock only randomizes the selection of
the children blocks and has unpredictable randomization of
the order of the selected child blocks due to the usage of sets, which
are unordered, for storing the selected blocks. This becomes apparent
when all the available child blocks in a library are chosen for a
Randomized Content Block, to randomize just the order of the child
blocks and not just the selection of the blocks. The order of the
selected blocks ends up being similar for multiple learners.
This change modifies the XBlock to store the selected child blocks in
a list, instead of a set, after randomly shuffling them.
- Add announcements view using JSX to the dashboard sidebar
- Create a new maintenance interface to edit and manage announcements
- Adds an override to main.html template to include new skip links
- Add plugins required for announcements to TinyMCE
This is motivated by a desire to have system wide messages for students
that show on the dashboard. Enabled with FEATURES['ENABLE_ANNOUNCEMENTS'].
Global staff are allowed to edit from the studio maintenance view.
All code in this PR should be removed after REVE-52 is merged and mobile
traffic from older app versions falls to < 5% of the mobile traffic
to the course_blocks api
Content Type Gating: Xblocks that have a graded component cannot be
accessed by audit track users.
- Caveats:
- In studio, instructors can set certain xblocks to be available to
all users, but graded components will default to not being
available for audit users
- If a course does not have a verified mode option, all users will
have access to graded content.
The Waffle Flag: The waffle flag is of for now.
It's name is: ```content_type_gating.debug```
This Commit Does NOT Include: Displaying for a user WHY they do not have
access to a specific piece of content. That change will be part of
another PR.
Doing modulestore lookups is expensive, so commit 695b036 created a
course_publish listener that would materialize the discussion ID to
XBlock usage key mapping into the CourseDiscussionSettings model.
However, the signal wasn't hooked up to the Studio process, so that
async task was never called. When hooking it up, I also discovered that
bok choy tests related to partitioning were failing because of a race
condition where multiple processes are overwriting the discussion
settings. To make sure this wasn't an issue, I moved the mapping to
its own table.
This is part of ARCH-111, and the overall Course Structures API
deprecation.
