Firstly, we're now explicitly instructing the comments service to not
return thread responses/comments if the request isn't AJAX. So, if you
load the URL for a single discussion thread in your browser, this would
be a non-AJAX call and we'll avoid loading the responses for the entire
thread behind-the-scenes. Big win here for large threads.
Next, we removed a redundant "get threads" call which was also happening
behind-the-scenes. This call was redundant as the front-end JS also
grabs the thread list when a topic is chosen, so we were making an
extranenous call for no benefit. Poof, gone!
Finally, we added some caching of database queries that are required to
drive a lot of the permissions/cohorts machinery around discussion.
This will have a minimal effect but introduced a cleaner way to apply
general memoization at the per-request level which will let us further
cache things as we identify them as issues.
TEST_DATA_MIXED_MODULESTORE
Remove these test mixed modulestores:
TEST_DATA_MIXED_TOY_MODULESTORE
TEST_DATA_MIXED_CLOSED_MODULESTORE
TEST_DATA_MIXED_GRADED_MODULESTORE
Adds a read-only mode to the discussion module which disables any
controls for updating the discussion (votes, follows, replies,
etc). This mode is enabled for users who are not a member of the team,
and are also not moderators, admins, or community TAs.
This reverts commit 086a2ba783, reversing
changes made to a44132ec18. Some minor
code quality issues were addressed as part of this change.
Conflicts:
lms/djangoapps/django_comment_client/base/views.py
lms/djangoapps/django_comment_client/utils.py
When two or more instances of Discussion XBlock were configured
with the same discussion target (Category/Subcategory),
only one of the blocks would be shown on the Course Discussion page.
This was the source of several bugs when trying to edit discussion threads.
This patch adds incrementing numbers to the title of each duplicate
subcategory when rendering the Course Discussion to make sure that
all of the threads are visible in Course Discussion.
The existing pattern of using `override_settings(MODULESTORE=...)` prevented
us from having more than one layer of subclassing in modulestore tests.
In a structure like:
@override_settings(MODULESTORE=store_a)
class BaseTestCase(ModuleStoreTestCase):
def setUp(self):
# use store
@override_settings(MODULESTORE=store_b)
class ChildTestCase(BaseTestCase):
def setUp(self):
# use store
In this case, the store actions performed in `BaseTestCase` on behalf of
`ChildTestCase` would still use `store_a`, even though the `ChildTestCase`
had specified to use `store_b`. This is because the `override_settings`
decorator would be the innermost wrapper around the `BaseTestCase.setUp` method,
no matter what `ChildTestCase` does.
To remedy this, we move the call to `override_settings` into the
`ModuleStoreTestCase.setUp` method, and use a cleanup to remove the override.
Subclasses can just defined the `MODULESTORE` class attribute to specify which
modulestore to use _for the entire `setUp` chain_.
[PLAT-419]
Move modulestore config for tests to an importable location
Disable pylnt warning for lms imports in common tests
Refactor all testcases that loaded all xml courses
TE-610
TE-489
This commit adds the non-courseware lms/djangoapps and lms/lib.
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 code adds the ability to add Mako template lookup directories on
the fly, allowing third party add-ons to contribute their own Mako templates.
A new API function for registering Mako templates is introduced::
from edxmako import add_lookup
add_lookup('main', '/path/to/templates')
# Or, specify a package to lookup using pkg_resources. This will
# add the 'templates' directory inside the current package:
add_lookup('main', 'templates', package=__name__)
The motivation for this change is performance. The forums UI code gets
the list of users for each role and renders the staff label based on
those lists. The list for the staff role is expensive to compute because
there is no index on the is_staff attribute, and we cannot create one
because the User model is built into django.
Users with is_staff=True are still assigned the Moderator role upon
enrolling in a course, so this change will have no practical effect
except that a user who is granted staff privileges after enrolling in a
course will have to be made a Moderator in order for their posts to be
labeled.
Additionally, the UI did not use the list of users with the Student
role, so that list has been removed as well.
Avoid recomputing course module information for every thread, which
should dramatically improve the performance of high-percentile latency
queries.
JIRA: FOR-250
The _DISCUSSIONINFO global was originally used as a cache, but has since
lost that capability and is therefore just harmful. This is a precursor
to more refactoring that will improve the performance of the forums and
may itself provide some performance improvement because it separates the
computation done by two functions that each previously computed the
entirety of _DISCUSSIONINFO.
