1. Created a new celery queue with key `SOFTWARE_SECURE_VERIFICATION_ROUTING_KEY`.
2. Added a celery task with retry logic.
3. sorted imports with isort.
4. Changed deprecated `log.warn` => `log.warning`.
We sometimes update preexisting SAML SSO providers to configure them
to automatically create SSO identity verification (IdV) records when a
learner links an account via that provider. Turning that configuration
from off to on does make it such that when learners log back in via
their linked account, a new IdV record will be created for them. But
it's possible we'd want this process to happen more automatically and
seamlessly, for which this management command will be helpful.
Note that this does not help with removing SSO verification records
for a provider for which this configuration has been turned off.
JIRA:EDUCATOR-4947
Learners are not allowed to make an attempt of the procotored exam if
they verify their identity near to proctored exam date.To make them,
aware about their expiry date, modification are done to the status card
so that user experience will be improved.
PROD-769
changes made to fix jenkins/quality errors
changes made as suggested
added the docstring to fix quality issue
made a few changes to fix some tests
replaced json.loads with a util to handle bytes
changes made to fix jenkins/quality errors
changes made as suggested
added the docstring to fix quality issue
made a few changes to fix some tests
made changes as suggested
made changes as suggested
updated the requirements with make upgrade
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
