Note that the features in this release are opt-in, and course and video
behavior will remain the same unless a course explicitly opts in.
Major pieces of functionality with this commit:
Allows the listing of a user's enrollments, course videos, and updates. In
order to make a course available for mobile use, course staff must explicitly
set the Course Advanced Setting "Mobile Course Available" to true. Course staff
will always see their own courses through the Mobile API regardless of this
setting, but students will only be allowed to see a course through the Mobile
API if this setting is set to "true". By default, a Course will *not* be
available for mobile use.
This is a Django app for video resource management. It is completely optional,
and is intended to allow video and operations teams to create new encodings of
videos (e.g. low res for mobile) and change CDNs without having to edit course
data directly. Course teams can now use a "EdX Video ID" setting for Videos,
which will leverage VAL. Video units that do not fill in an "EdX Video ID" will
behave exactly as they always have.
* The Mobile API is enabled with the ENABLE_MOBILE_REST_API feature flag.
* VAL is enabled with the ENABLE_VIDEO_ABSTRACTION_LAYER_API feature flag.
* VAL and the Mobile API both require ENABLE_OAUTH2_PROVIDER).
* The Mobile API is a read-only API, but VAL requires database migrations.
* Applications that make use of either the Mobile API or VAL must be registered
with the OAuth2 provider app in Django Admin.
Lots of plumbing to allow an asset named python_lib.zip to be imported
by jailed Python code.
This function can find the "python_lib.zip" asset, and is passed down
through ModuleSystem and LoncapaSystem so that capa problems have access
to the zipfile.
These were failing on Solano builds because the save button was clicked
before the datepicker was done its work. (The EmptyPromise was still satisfied
because the input field value had been updated, but the datepicker widget
caused issues about 3/4 of the time.)
The actions are now consolidated in one location for each piece of
content. Primary actions (vote, follow, endorse, mark as answer) are
buttons, and secondary actions (pin, edit, delete, report, close) are in
a menu. This also includes improved front-end error handling for the
actions and significant test cleanup.
Co-authored-by: jsa <jsa@edx.org>
Co-authored-by: marco <marcotuts@gmail.com>
Co-authored-by: Frances Botsford <frances@edx.org>
Co-authored-by: Brian Talbot <btalbot@edx.org>
This commit adds validation for course advanced settings. Currently when course
administrators make invalid changes in the Settings/Advanced Settings tab,
they're not notified through a new modal window of the list of invalid settings
changes.
* Extending CourseMetadata
- Previously, we only had update_from_json method in CourseMetadata.py,
and it was only validating one field every POST request.
- Now we have validate_and_update_from_json method that encapsulates the
functionality of update_from_json into a validation call
- To avoid discrepancy of validation standards between modules, validation
uses the from_json method implemented to each field in xblock.
* Different Response in advanced settings ajax requests
- After receiving a POST ajax request, course.py calls
validate_and_update_from_json, and sends a json object of either:
1) valid course metadata model
2) error objects
* Error Messages shown in validation-error-modal
- error objects passed through ajax are shown in a separate modal.
TNL-46
I've changed Studio to catch JavaScript errors when rendering xblocks, log the error, but to then continue as normal. This means that the user is still able to interact with the xblock to delete, duplicate etc. This seems reasonable as the xblock is only rendered as a WYSIWYG representation so if it isn't fully interactive that shouldn't be a big problem.
