* 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
Move command parameter arguments, resend-days and days-range, to
common settings. This will help in creating a consistency when the
default values are changed in the future.
LEARNER-7313
datetime.now(UTC) gives unexpected results. Using "now()" function
from django.utils.timezone tends to be a much more reliable way to
get a time zone aware timestamp for the current time.
PROD-190
Template for email added (email/verification_expiry_email)
The management command filters the SoftwareSecurePhotoVerification model on the basis of following criteria :
-- the verification is approved
-- the start_date < expiry_date < today or specified days have passed to resend email
After the basic filtering batches are created to send email. For each verification in a batch email is sent and
email_expiry_date is set to 15 days from today (default days are 15, it can be changed too)
Between each batch there is a delay of sleep_time seconds
Method approve() is overridden to accommodate new users that will have their verification approved in the future.
The approve() method is called from software secure results callback every time a Software Secure Photo Verification
is approved.The method overridden now updates expiry_date and then calls super to perform task it was performing
before this change.The expiry_date set is the same as the one sent in verification approval email.
In results_callback for sspv the expiry_date and expiry_email_date for the most recent previous verification if exists
are also updated to NULL.
Implementation for DE-1089.
Centralize the definition of context into a single method. This is in
common/djangoapps/track because the context is originally set there by
middleware.
Previously Verfication status emails are sent using sail-thru.Now,
Separate templates are added in the platform that will be used to
sent status emails to the learners.
LEARNER-5931
- Change retire mailings endpoint to use new USER_RETIRE_THIRD_PARTY_MAILINGS signal, currently only used by Sailthru retirement
- Move USER_RETIRE_MAILINGS signal firing to the LMS misc endpoint
- Remove duplicate clearing of UserOrgTags
- Remove LMS imports in openedx/core and update usage to use new USER_RETIRE_LMS_CRITICAL and USER_RETIRE_LMS_MISC signals
- Add testing for new signal handlers and app registration for the LMS survey app
Django 2.0 will make this field required for `ForeignKey` and `OneToOneFields`.
In previous versions the option defaulted to `models.CASCADE` when not
specified. This change should make the deprecation warnings in the current
Django version go away.
The migrations where also modified, but the changes should not cause a change in
the database schema since `models.CASCADE` was already the old default.
Support needs to inform a learner different states of its
id-verification.In order to achieve it email will be sent
to learner about its verification state using sailthru.
LEARNER-617
This reworks what was done #17930, since it had to be reverted from the IDVerificationAggregate migration.
We decided to abandon that model and directly read from both id verification models.
