This is a fix for the performance issues in EDUCATOR-3374
AWS's Aurora backend for MySQL selects the wrong index on the
django_comment_client_role_users table, leading to performance issues.
This commit replaces that join with individual requests for permissions
for each role (of which there may be several for any given user).
It's dumber SQL, but Aurora will do the right thing.
Doing modulestore lookups is expensive, so commit 695b036 created a
course_publish listener that would materialize the discussion ID to
XBlock usage key mapping into the CourseDiscussionSettings model.
However, the signal wasn't hooked up to the Studio process, so that
async task was never called. When hooking it up, I also discovered that
bok choy tests related to partitioning were failing because of a race
condition where multiple processes are overwriting the discussion
settings. To make sure this wasn't an issue, I moved the mapping to
its own table.
This is part of ARCH-111, and the overall Course Structures API
deprecation.
This specifically enables/disables the underlying comment service client
used to make calls to the service. When disabled, this client will now
throw an exception which can be propagated upwards so that callers can
make the right decision about how to notify users of the error, or
handle retry, etc etc.
Caches all permissions per user per course. Adds caching functionality to has_permission and replaces all instances of cached_has_permission with has_permission.
This commit updates common/djangoapps.
These keys are now objects with a limited interface, and the particular
internal representation is managed by the data storage layer (the
modulestore).
For the LMS, there should be no outward-facing changes to the system.
The keys are, for now, a change to internal representation only. For
Studio, the new serialized form of the keys is used in urls, to allow
for further migration in the future.
Co-Author: Andy Armstrong <andya@edx.org>
Co-Author: Christina Roberts <christina@edx.org>
Co-Author: David Baumgold <db@edx.org>
Co-Author: Diana Huang <dkh@edx.org>
Co-Author: Don Mitchell <dmitchell@edx.org>
Co-Author: Julia Hansbrough <julia@edx.org>
Co-Author: Nimisha Asthagiri <nasthagiri@edx.org>
Co-Author: Sarina Canelake <sarina@edx.org>
[LMS-2370]
This applies to global staff (is_staff=True), not course staff.
Previously, staff were granted the Moderator role but not the Student
role upon enrolling in a course. If the Moderator role were later
revoked, then the user would have no role and be unable to post in the
forums, which is confusing for the user. edX staff indicated they would
prefer to not automatically receive the Moderator role, so the Student
role is granted instead. Note that staff will still be able to grant
themselves Moderator privileges through the instructor dashboard if
they wish.
JIRA: FOR-338
Features coming down the pipe will want to be able to:
* Refer to enrollments before they are actually activated (approval step).
* See what courses a user used to be enrolled in for when they re-enroll in
the same course, or a different run of that course.
* Have different "modes" of enrolling in a course, representing things like
honor certificate enrollment, auditing (no certs), etc.
This change adds an is_active flag and mode (with default being "honor").
The commit is only as large as it is because many parts of the codebase were
manipulating enrollments by adding and removing CourseEnrollment objects
directly. It was necessary to create classmethods on CourseEnrollment to
encapsulate this functionality and then port everything over to using them.
The migration to add columns has been tested on a prod replica, and seems to be
fine for running on a live system with single digit millions of rows of
enrollments.
