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
This would let the team order translations for the beta language message
to ensure that it remains translated for a wide set of partially supported
languages.
LEARNER-4304
An older test was deleted based on flakiness around the ID
verification process; this test eliminates the dependency on IDV by
enabling manual ID verification (an enterprise-motivated workaround
for IDV requirements) via the auto_auth endpoint.
JIRA:EDUCATOR-1178
1. Use request.session instead of request.user, since request.user
won't necessarily be properly set.
2. Be extra paranoid by putting logging after session cookie deletion,
so that even if there is some error related to logging, the important
work will complete and the browser won't get left in a broken state.
3. Write out the full contents of the Cookie header (up to 4096 bytes)
in the log as a base64 encoded string. This way we can look at broken
cookie states and diagnose what's breaking them (the Python parser will
just silently skip anything past a corrupted cookie entry). We base64
encode mostly to prevent people from maliciously injecting garbage into
our logs.
