LEARNER-7136 populate expiry date and add mechanism for new verification
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.
Currently, ajax calls in courseware is handling 403 like 401.
In this PR, proper modifications have been done to make it
coherent with its intended behaviour.
LEARNER-7131
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.
We've been running into OoM issues with this functionality while
executing on one of our smaller application servers.
- Sometimes this manifests by preventing the entire page from loading
(exception during the GET).
- At others, it occurs using the `Delete course from site` functionality
by breaking during the POST handler. This case is particularly
frustrating because the course actually is deleted, but looks like it
may not have been. Internally, this is because the 500 error occurs
_after_ the course has been successfully deleted, though this is
opaque to the end-user.
While this doesn't address the underlying memory issue,
it does at least allow the app to recover gracefully.
Basically, this was done by:
1. Adding new class type in [common/djangoapps/student/message_types.py]
2. Adding new files for the ace template in a new directory named
[common/templates/student/edx_ace/emailchangeconfirmation]
3. Removing old template files
[confirm_email_change.txt] and [email_change_subject.txt]
from the directories:
[lms/templates/emails] and
[common/test/test_sites/test_site/templates/emails]
4. Converting the [confirm_email_change] code to use [ace.send()]
Currently, ajax calls in courseware is handling 403 like 401.In this
PR, proper modifications have been done to make it coherent with its
intended behaviour.
LEARNER-7131
