Moto has a vendored version of HTTPretty which also monkey patches the
socket object. If you activate both, you get weird errors like
https://github.com/spulec/moto/issues/750
So we're opting not to activate both in this test. We're are just using
the moto vendored version of httpretty for both our usage and the
mocking of boto.
I also removed the logic that seemed like it was just testing that our
mock is a mocking s3 correctly.
* 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
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.
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
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
