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.
This partially reverts commit ee1c3a4548.
The migration files introduced by the commit have been kept since they have been run
already on several enviornments.
Support Team need to handle bulk of tickets every month
about the verification status of learners.To avoid it,
suitable changes have done to send verification email
to the learner.
LEARNER-1488
Support Team need to handle bulk of tickets every month about the
verification status of learners.To avoid it,suitable changes have
done to send verification email to the learner.
LEARNER-1487
Support Team need to handle bulk of tickets every month about
the verification status of learners.To avoid it,suitable changes
have done to send verification email to the learner.
LEARNER-1487
