The old line:
from path import path
produced pylint errors because of the baroque way that path.py defined
"path". We tried to get them to change how they defined it, but they
deleted the name instead: https://github.com/jaraco/path.py/issues/102
(Jason then changed his mind, but this is a better way to use path.py,
it avoids the pylint error at least.)
Filter by Language:
Designation for course language(s) in Studio
allows for filtering of courses based on their language in the sidebar
Reuses active filter view UI/IA from find courses page on edx.org
view for clearing individual or all filters, as with edx.org filtering
After deleting a course, creating one with the same URL did not
work because its mapping is not removed from the modulestore. This
fix adds a more robust check to see if a course with the URL
actually exists.
This allows course authors to choose between two difference licenses for their
course content: All Rights Reserved, or Creative Commons. In the backend, XBlocks
that wish to allow custom licenses need only inherit from LicenseMixin, which
adds a `license` field as a string.
License information is displayed in the Studio editor view, and just below the
rendered XBlock in the LMS. In addition, if the course block itself has a custom
license set, this license will display just below the main body of the page
on courseware pages.
This entire feature is gated behind the LICENSING feature flag.
Context: We have witnessed multiple, seemingly random "CSRF verification
failed" errors while signing in (with valid ID) to the Studio.
Explanation: The login form does not initially include a CSRF field.
The CSRF header of the request is appended to the studio login request
headers by intercepting the form validation. This intercept is performed
by the login.js script. Unfortunately, the login.js script is loaded
pretty late (at the end of the template). So if the login form is
validated sufficiently fast, the login.js script has no time to load and
append the X-CSRFToken header to the request.
Proposed solution: the CSRF token is already passed to the template via
the login view, so we just add a hidden field to the login form to
include the csrf token.
