- use new dates banner template on course outline page
- remove old banner from main.html
- let dates tab use new dates banner template
- remove dates banner completely from the courseware problem view
on the web app
- use new banner on the courseware problem view on the mobile app
- update banner util to use get_course_blocks
TNL-7053
The courseware_api view will use check_course_access - which now returns AccessResponse objects, and all other uses of check_course_access will now use check_course_access_with_redirect, which is a drop-in replacement for the original check_course_access implementation.
We also added a few new helpers to access_utils:
- check_public_access is a replacement for allow_public_access, which now returns AccessResponse objects
- check_enrollment checks if the learner is enrolled, and uses check_public_access to account for COURSE_ENABLE_UNENROLLED_ACCESS_FLAG
- check_survey checks whether there is a required survey that the learner must complete prior to accessing the course.
There are two new kinds of AccessError subclasses:
- SurveyRequiredAccessError
- EnrollmentRequiredAccessError
- remove code for displaying banner in mobile dates fragment
- replace button with link to web app in reset dates banner on
the mobile problem template
- adjust spacing of reset dates button in banner when button wraps
on smaller screen
We're seeing slow commits on production for courseware_studentmodule
updates. Based on the slow queries during those times, we think it
might be because multiple worker processes are trying to update the
same rows from within long-running transactions (since courseware
is relatively slow).
The risk with this is that since the whole view execution is no
longer wrapped in a big implicit transaction, it's possible that
XBlock state will update and things that key off of that (e.g.
completion progress information or pre-req milestones) will fail
in a way that will leave the database in an unplanned-for state,
though this is already the case for those actions that trigger
asynchronous tasks like grades recalculation.
The query counts for the index view test were adjusted down
because save points count towards the total and we're no longer
setting them at the top level around the view as a whole.
- for self paced courses, if a sequential's due date has passed
and it is incomplete, allow the user to reset the start_date
for the related schedule to now, thus shifting all due dates
for all sequentials within the course by the pre determined
due date offset.
- add historical table to the Schedule model.
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 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.
This patch would make financial
assistance form help message to be
consistent with implementation. Using
characters limit instead of word limit.
PROD-733
* Update Financial Assistance logic
Use the zendesk proxy app instead of the unsupported zendesk library.
* Move to pre-fetching the group IDs.
Rather than making extra requests to zendesk to list all groups and find
a specific group ID. Just make a pre-filled list of group IDs for the
groups we care about. When a group name is passed in, it is checked
against this list and the ticket is created in the correct group so the
right people can respond to it.
