It's safe to remove this because non-staff [1] users cannot access [2]
an `ErrorBlock`. We were able to reproduce this with and without this commit
with the following results:
1. Staff users were seeing the `ErrorBlock`.
2. Non-staff users were getting an empty `<div class="vert-mod"></div>`.
In theory, error blocks should be hidden in the Learning MFE because of this
option [3]. However, when we manually set `hide_access_error_blocks` to
`False`, we kept getting identical results (with and without this commit), so
it looks that the removal `NonStaffErrorBlock` was just omitted at some point.
[1] a4ec4c1b8e/lms/djangoapps/courseware/access.py (L419-L436)
[2] a4ec4c1b8e/lms/djangoapps/courseware/access.py (L150-L151)
[3] 92ca176fde/lms/djangoapps/courseware/views/views.py (L1547-L1551)
JIRA: https://openedx.atlassian.net/browse/BOM-2580
This PR aims at refactoring the discussion xblock sub project and moving it within the xmodule directory effectively removing its position as a sub project within edx-platform
- Moving xmodule folder to root as we're dissolving sub-projects of common folder in edx-platform
- More info: https://openedx.atlassian.net/browse/BOM-2579
- -e common/lib/xmodule has been removed from the requirements as xmodule has itself become the part of edx-platform and not being installed through requirements
- The test files common/lib/xmodule/test_files/ have been removed as they are not being used anymore
Unfortunately, some code in edx-platform is imported
relative to sub-projects instead of the repository root.
The only three remaining instances of this are:
* common/lib/xmodule/xmodule (imported as just 'xmodule')
* common/lib/capa/capa (imported as just 'capa')
* openedx/core/lib/xblock_builtin/xblock_discussion
(imported as just 'xblock_discussion')
For more details on the situation, see:
https://openedx.atlassian.net/browse/BOM-2579
(public, but requires Atlassian account creation).
We would like to get to a point where all edx-platform
import paths match their folder paths, relative to the repo
root. For now, though, all common/lib/capa and common/lib/xmodule
code should be imported as just `from capa` and `from xmodule`,
respectively. Importing using the full `common.lib.xmodule.xmodule...`
path will often work, but it instantiates a second instance of all
modules imported this way, which in the past has led to very
difficult-to-diagnose bugs. It also confuses tooling such as
import-linter, which we are trying to add to edx-platform
(see https://openedx.atlassian.net/browse/BOM-2576)
* feat: Adds discussions settings for new discusions experience
This commit adds new discussions settings for the new discussions experience. These are stored in the course so they can be a part of course import/export flow.
These are also added to the discussions configuraiton API to allow MFEs to update the settings.
The discussions API is currently available via LMS, however that means it cannot save changes to the modulestore. This also adds the API to the studio config so it can now also be accessed from studio and be used to save course settings.
* fix: tests
This commit adds new discussions settings for the new discussions experience. These are stored in the course so they can be a part of course import/export flow.
These are also added to the discussions configuraiton API to allow MFEs to update the settings.
The discussions API is currently available via LMS, however that means it cannot save changes to the modulestore. This also adds the API to the studio config so it can now also be accessed from studio and be used to save course settings.
created CustomPagesCourseApp class
feat: created custom pages course app plugin
created CustomPagesCourseApp class
added CUSTOM_PAGES_HELP_URL to lms and cms settings
added entry point to setup.py
feat: added toggle to ENABLE_CUSTOM_PAGES in lms and cms settings
feat: removed the option to enable/disable the availability of custom pages course apps.
* feat: Course Apps API
This adds a new concept called course apps. These are exposed via a new
"openedx.course_app" entrypoint, which helps the LMS and studio discover such
apps and list them in a new rest api for the same.
These course apps will drive the pages and resources view in the course authoring
MFE. This system will track which apps are enabled and which are disabled. It
also allows third-party apps to be listed here by using the plugin entrypoint.
* Apply feedback from review
This minimizes our footprint outside of the djangoapp, now and moving
forward. Not only can we drop the `lms/envs/common.py` change, but we
can also avoid touching `lms/urls.py` when we add the API. Everything
can stay contained within `openedx/core/djangoapps/discussions`.
This PR lays the groundwork for a an LTI tab that can embed any LTI1.1-based
tool as an course tab. It also adds another tab based on this LTI Tab that
offers special support for embedding LTI-based discussion tools in a course
tab. If enabled this will replace the existing discussion tab.
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.
