Increment lockout counter upon `NonCompliantPasswordException` to prevent further
login attempts after 6 attempts and also to prevent further reset password emails.
Reports from some users receiving 100s of password emails, upon investigation seems
like their password is not compliant with edX and has been compromised.
VAN-192
Partner Support commonly raises the issue of instructors' custom Python problems not generating any response report on the instructor dashboard. Such errors are due to the operating restrictions placed on codejail. Sometimes not all answers can be processed by the server, which kills off some to accommodate. Instead of spiking the whole report, this change logs not only the error in our system, but also allows the mostly complete response to reach the instructor.
This PR will decrease friction not only for Partner support and instructors, but T&L, who have periodically implemented workarounds to the problem.
The PR merely implements exception handling for generating reports which logged exceptions and added them to the report, continuing the work done in TNL-8218 which did the same for grading.
We ignore the missed_deadlines because this endpoint is used in the Learning MFE for
learners who have remaining attempts on a problem and reset their due dates in order to
submit additional attempts. This can apply for 'completed' (submitted) content that would
not be marked as past_due
This adds support for course staff masquerading as any other user when
viewing their own course, via user={username} querystring parameter.
Rules:
* Anonymous users are repesented by a blank "user" value.
* If there is no "user" parameter at all, render for the user making the
request.
* Global staff can view any course as any user.
* Course staff and instructors can view their own course as any user
(including other staff, the anonymous user, or users not enrolled in
their course).
This commit supports TNL-8330 (switching the frontend-app-learning MFE
to use the Learning Sequences API instead if Course Blocks).
[MICROBA-678]
When a certificate is in an unexpected state (i.e. notpassing with a
passing grade) this alert will allow the user to attempt to resolve the
issue on their own. It will run the code that checks the certificates
status. It requires that the course is configured to allow users to
Request Certificates though.
This change adds three new filters to the threads API. They are:
* Filtering only threads that are flagged for abuse
* Filtering by the thread type (discussion or question)
* Filtering by the thread author
In addition it also adds a new ``abuse_flagged_count`` field for threads. It
returns a count of the number of comments in a thread that are flagged for abuse.
This is only visible to users that have moderator privileges or higher.
Finally it also adds a ``abuse_flagged_any_user`` field that is set if any user
has flagged a thread. This field too, is only visible to moderators or above.
Co-authored-by: Kshitij Sobti <kshitij@opencraft.com>
and CourseSectionSequence to ensure that cascading deletes will occur to delete
the relation upon deletion of a foreign-keyed object.
This commit is phase 3 of 4 in order to ensure a smooth deploy. The phases:
1) Add separate through models for user partition groups, add fields to point to the
separate models, and start writing to those fields as well. (COMPLETE)
2) After all models have been re-generated, switch code over to use separate through
model fields backed by the separate through models *and* stop writing to the original
ManyToManyField field. (COMPLETE)
3) After phase 2 is deployed smoothly, remove the original ManyToManyField fields. (This PR!)
4) After phase 3 is deployed smoothly, rename the new fields to have the same name
as the old fields, so new_user_partition_groups -> user_partition_groups.
This PR is designed to be able to easily be rolled-back if anything goes wrong.
