The enrollmentStatusHash cookie value was created in commit f0030334
as an optimization, in order to determine whether the marketing site
needs to refresh the list of a student's enrolled courses with a
call to the LMS. To ensure that this value was kept up to date,
commit d7a7bcc1 reset the user's cookies every time they go to the
learner dashboard page (which used to be the next page loaded after
you enrolled in a course). This didn't just reset the
enrollmentStatusHash though -- it recalculated all the cookie
values, as if you had just logged in.
A number of things have changed since then:
1. Enrolling in a course now goes to that course's info/navigation
page, rather than going to the student dashboard.
2. It doesn't appear that the value of enrollmentStatusHash is
actually being examined anywhere -- it's set in a cookie on the
LMS and read/written by the edX marketing front end code, but
the value is never looked at to make any decisions.
3. The introduction of add_email_marketing_cookies (which triggers
off of the CREATE_LOGON_COOKIE signal) has made cookie resets
far more expensive, as there is a blocking call to Sailthru if
you have that enabled in EmailMarketingConfiguration (which
edx.org does). This can add over two seconds to the server
processing time for the student dashboard at certain times of
day.
Given this, I'm removing both the call to resetting the cookie on
the student dashboard page, as well as setting the value for
enrollmentStatusHash.
Currently, enrollment support tool is only allowing support members
to change course enrollment only one of the two modes i.e. audit and
verified.To move a learner other than these modes,they need to ping
devops.To broaden the scope of enrollment support tool,changes have
been done so that enrollment would be changed to other modes as well.
PROD-305
* Remove full table scan of VerificationDeadline.
Before this commit, we were doing a full table scan of
student_verificationdeadline, loading the results into a giant
dict, and reading/writing that to the cache. This was fine when the
code was introduced and there were dozens of courses, but now that
we're over 12K courses, it's becoming a major performance issue for
the Student Dashboard.
This uses a subquery to the course enrollment table so that we're
only ever pulling back the deadlines to a student's enrolled courses
for any given request. It removes the cache access entirely.
If already DEFAULT Number of emails are sent, then verify that user
is enrolled in at least one verified course run for which the course
has not ended else stop sending emails
LEARNER-7313
These were originally fixed individually, but had to be reverted, and
are now combined in one commit. The originals were:
7b9040f6b0 This enum was backwards
8774ff1f9b Use ref_name to disambiguate serializers that drf-yasg would otherwise assume are the same.
8a44397139 Is this field missing because it is None?
4a1154a7ca Give a safer buffer for clearing the rate limiting
64c47856dd DRF 3.7.4 changed how you delegate to another view, so don't
7359ca4fb2 Is this right? It fixes two tests
fdd66e5390 Adjust the expected error message for DRF 3.7.7
9257f68fd8 The default TIME_ZONE should be UTC
* Add IdentityServer3 Backend
This adds a backend for users who want to use IdentityServer3 as their
SSO provider. It can be used with the OAuth2ProviderConfig in django
admin to point to an external provider.
