JIRA: MST-736
Due to inconsistencies in the way we handle attempts in past due practice proctored/onboarding exams, learners can end up in an unintended liminal state after attempting to reset their onboarding attempt. If a learner attempts to reset their rejected onboarding attempt after the exam's due date, we process the reset request and move their attempt into the "onboarding_reset" state. Theoretically, a new exam attempt should be created immediately thereafter. However, we have code that prevents the creation of an exam attempt after the exam's due date, so the call to create a subsequent exam attempt fails, leaving the learner with an exam attempt with the "onboarding_reset" status. Theoretically, this situation should never occur, and the fact that it does is a bug. Because of this, we did not handle the "onboarding_reset" status in the StudentOnboardingStatus panel, and this status appears as "null". As an intermediate step, while we think about our due date logic, this pull request bumps the edx-proctoring library to version 3.8.5, which adds a new onboarding status "onboarding_status_past_due". This status is displayed as "Onboarding Reset Failed Due to Past Due Exam" in the StudentOnboardingPanel in the InstructorDashboard, which should provide course staff with a clearer explanation.
JIRA: MST-745 tracks the removal of this intermediate code from the code base once we fix the underlying cause of this bug.
JIRA: MST-749 tracks the fix for the behavior that allowed for this state to occur.
* Commits:
feat: Implement POST endpoint for discussions API
feat: Implement update helper for discussions API
feat: Implement to_internal_value helper for discussion API
feat: Add lti_configuration to discussions API payload
refactor: Base discussions serializer off of ModelSerializer
refactor: Remove unused helper from discussions API
fix: Use the correct name for serializer to_internal_value
We don't need to execute instuctor code for the problem response
report because we're grabbing existing student state and scores.
Running codejail is expensive, slow, and risks report failures if
there is CPU intensive instructor code that is run at times when
the servers are already heavily loaded (and things start timing
out). This came up in TNL-8183 (and many others).
The /jump_to/ LMS endpoint is used in a number of places
to direct users to courseware. It currently only redirects to
Legacy courseware URLs, which then conditionally may
redirect to the Learning MFE.
Two issues with this:
1. Performance Impact: In most cases, going to Legacy first
is just an extra redirect.
2. Confusion for Privileged Users: Neither course nor global
staff are auto-redirected from the Legacy experience to the
MFE. Thus, these priviliged users confusingly never see the
MFE by default; they must always manually click into it.
This commit makes it so that /jump_to/ directs
users to whatever the default courseware experience is
for them. For staff of courses active in the new experience,
this will impact (at a minimum) the "View Live"
links in Studio, all links on the old and new LMS
course outline, and the "Resume" links on the course
dashboard. Learners should see no difference other than
a performance improvement when following courseware links
from the LMS.
This also adds an optional 'experience=[legacy|new]'
query param to /jump_to/, allowing us to specifically
generate Legacy courseware URLs for the
"View in Legacy Experience" tool.
TNL-7796
'section' is a very outdated (<2012) way to refer sequences,
which we also call 'subsections'. The old terminology still exists
throughout the courseware djangoapps, but I decided to clean up this
one test case while I'm working on it.
This:
1. Introduces a new override using the `pluggable_override` decorator.
It is now possible to specify a custom way of getting XBlock's icon
by defining `GET_UNIT_ICON_IMPL` in settings.
2. Introduces a way to add custom `XBLOCK_MIXINS` by defining
`XBLOCK_EXTRA_MIXINS` in settings. This allows, e.g. to add
new fields to XBlocks.
