This reverts commit cdb0619846,
which itself reverted 3ca006214e.
The original commit (3ca006) was reverted because it was suspected
that it was causing unexpectedly-increased memcached usage and
500s in the Gradebook API. It is not clear whether that is actually
the case. We are optimistically reinstating 3ca006 and will monitor
production to see if there is an adverse effect.
MST-105
Learner who have already earned PDF honor certificates in old courses
are unable to see the certificate links on dashboard and course progress
pages since `course.cert_html_view_enabled` is deprecated and default to
True for all courses.
PROD-60
The functions `CourseOverview.get_from_id_if_exists`
and `CourseOverview.get_from_ids if exists` are bug-
prone, in that they do not go to the modulestore
when a CourseOverview is out-of-date or uncached.
The docstrings spell this out, but callers seem
not to understand the implications.
So, in this commit, we:
* Remove both functions
* Add `CourseOverview.get_from_ids` for almost-as-fast
yet safer bulk-fetching of overviews
* Update call sites to use `course_exists` or `get_from_ids`
in place of the old functions.
* Add tests for @verify_course_exists.
This PR should specifically fix an issue where
the program_enrollments API was breaking when the CourseOverview
version was bumped.
CR-1708
The Video Player XBlock will sometimes make API calls to /couses/yt_video_metadata, a REST API endpoint that in turn loads video metadata from YouTube using the configured settings.YOUTUBE_API_KEY.
However, in the Blockstore-based XBlock runtime, we are running XBlocks in a secure sandbox, and the user's browser cannot pass session cookies when calling REST API endpoints. So currently, the video XBlock tries to request YouTube metadata from that API endpoint, but it fails if run within such a sandbox.
The existing API also doesn't work for anonymous users (users who are allowed to see video XBlocks but who have not logged in to an LMS user account).
This commit updates the Video XBlock so that it can use a handler to load the data from YouTube instead of a generic REST API. This works well in the new runtime, because it has code to support calling handlers within the sandbox, including by anonymous users.
I also fixed a bug where on a default devstack, the endpoint will try calling YouTube using PUT_YOUR_API_KEY_HERE as an API key, and get a "bad request" error from YouTube.
The code could be re-organized by moving things around, but I've left everything as-is for now to keep the diff as small as possible.
