This change will prefer putting assignments before other course
events (such as end date or verification deadline date) in the
case where they share the same date.
- 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
Updated the displayed start date for a learner in a self paced course
that appears in the Learner Dashboard and the Dates tab.
Used the max of the course start date and the learner's enrollment date.
We saw an increase in response time with recent changes to the logic
behind get_course_assignments. This effort works to better access
the information we need in order to improve performance.
Namely, this is done by using the course_blocks_api
I wanted to make a byte-sized contribution but there were no Jira tickets so we decided, thanks to a conversation with @jmbowman through the Open Edx Community #incr (Slack) channel, to collaborate in the elimination of warnings listed in the Warnings Report at https://build.testeng.edx.org/job/edx-platform-python-pipeline-master/warning_5freport_5fall_2ehtml/
This PR contributes to the elimination of deprecation warnings, specifically the one mentioned above and reported in the Warnings Report.
Changed logger.warn to logger.warning in the following files:
lms/djangoapps/experiments/utils.py
lms/djangoapps/lti_provider/outcomes.py
lms/djangoapps/courseware/module_render.py
This warning occurs due to deprecation in python 3.4+: https://docs.python.org/3.5/library/logging.html#logging.Logger.warning
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
* Reenable Learning Sequence MFE redirect tests
TNL-7157 These tests may were the cause of intermittent test failures a couple weeks ago. Here they are reenabled after changing the way ExperimentWaffleFlag is overridden.
* Update is_experiment_on and add ExperimentWaffleFlag override test
* Update test_flags.py
* Add docstring about overrides
* prefer is_experiment_on over _is_enabled
TNL-7157 These tests may were the cause of intermittent test failures a couple weeks ago. Here they are reenabled after changing the way ExperimentWaffleFlag is overridden.
- 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
This looks like the last failing unit test under Django 2.2. One of a series of such failures resulting from Django no longer accepting None as POST data (since you can't really get it from a real request), most of which were already fixed by the Arbisoft team in the last few days.
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.
