[MICROBA-1109]
* Remove the requirement for the `auto_certificate_generation` waffle switch to be enabled in order for a learner to be eligible for a certificate. This switch should control _when_ a certificate is generated, not _if_ a certificate will be generated for a learner.
* Move the `auto_certificate_generation_enabled` check to happen before we try to generate v2 certificates in signals.py
* Update unit tests
* Update documentation
* MST-734 Fix production issue on Learner Onboarding Status Panel
Fix the prod issue where learning sequence service object missing the needed get_user_course_outline service API
The user web API call currently returns 500
The version of proctoring 3.8.3 uses the onboarding exam due dates or course end dates as the testing date for learning sequence service to test the visibility of the onboarding status panel for learners. This change would allow onboarding exam with due dates to display to course enrollees correctly
MST-706. ID Verification is now valid for 2 years, so messaging used to notify learners about their ID expiration should be updated to reflect this. We have chosen to only update the messaging that is related to the current IDV flow (going through IDV on the account MFE), as the old IDV flow is no longer used by learners on edX.
This fixes TNL-7973 [1].
Background
----------
> An alert was sent out because a malformed capa problem caused block
> transformers to fail to run.
> This specific error/alert was triggered when an optionresponse problem
> lacked text. The authoring-based fix is to edit the offending
> option-response problem to remove the empty option.
> Expected behavior: We should be able to keep the error local to the
> ProblemBlock and not blow up the whole course publish block
> transformer collection process.
> This is a really easy error for authors to make, and the consequences
> to them (one problem doesn’t work) are disproportionate to the
> consequences [...] (alerting triggered).
- [1] https://openedx.atlassian.net/browse/TNL-7973
This was initially introduced as a temporary flag to be able to get more
information. But if we get this kind of issue again, we'll need
something like this logging to determine the source of the session
collision. Rather than removing the code and adding it back in later,
convert this temporary switch into an opt-in setting that can be used
again in the future.
BREAKING_CHANGE: 'safe_session.log_request_user_changes' switch no
longer exists and is replaced with the 'LOG_REQUEST_USER_CHANGES' django
setting which defaults to 'False'
Previously they also had to have a valid JWT cookie which led to a weird
corner case where a user was logged in but still showed the login form
resulting in some confusion and odd behavior.
This change gives precedence to the session token to determine whether
or not someone is logged into the LMS but ensures that if you go through
the login flow, you refresh your JWT cookies. This should not cause any
breakage for MFE flows that might redirect to the LMS login page since
the JWT would get refreshed if it's out of date but the session is
valid.
Six frames was not enough because for DRF views the request gets wrapped
in a proxy object and so we need more of the stack to see what part of
the code we're in that actually invokes the use change.
Video SJSON transcripts are supposed to be UTF-8 encoded, but SJSON
is an ad hoc thing we made up to make it easier to build the
transcripts viewer in the VideoBlock, and it's not well specified.
Prior to this commit, if you had an SJSON file with Latin-1 encoded
text outside the standard ASCII range (e.g. û), then we'd error out
while trying to export it.
This was blocking an effort to export some Old Mongo courses (TNL-8007).
Exposed the Date header on the outline api so clients can accurately compute times relative to the dates returned by the API; this was previously done with the course API (#26979)
Browser time is notoriously unreliable for this, especially for a Learner-facing countdown call-to-action based on the access expiration date. (REV-2126)
Using the Date header for this allows the client to make use of information that is already sent, does not require additional calls nor modifying the API, and could be generalized to more or all our APIs without modifying them.
