Caches all permissions per user per course. Adds caching functionality to has_permission and replaces all instances of cached_has_permission with has_permission.
Implement the use of CCX opaque keys throughout the ccx code base
include the new custom ccx id package in the github checkouts list
update the coach dashboard wrapper to get CCX information from the incoming course_id, if possible
update function signatures for all view functions to expect CCX as passed by the dashboard wrapper (default to None), remove calls to get_ccx_for_coach as the ccx is passed in.
update reverse calls in python view code to use a CCXLocator for the URL instead of a CourseLocator
use CCXLocator where necessary
use course id to find ccx, instead of thread local
remove unused method and related tests
use course id for getting ccx
provide course id to the get_current_ccx method
ensure the course id passed in is a CourseKey instance of some type whether it starts out as a string or not
use the provided block to figure out what the course_id should be, then get the ccx for that
redirect to ccx dashboard using coach ccx if no ccx is passed in
update student dashboard listing for ccx to build an appropriate url from a CCXLocator, not from the course locator.
refactor building the ccx locator so we don't have to do it repeatedly
begin test refactoring after ccx_keys introduction
Ensure that when access checking happens, the course_locator form of a ccx locator is used. This ensures that the access check happens against the course and it is not necesarry to duplicate the entire access control structure for the course.
pick up api change in ccx-keys
create and conditionally use a wrapper for the mixed modulestore returned by xmodule.modulestore.django.modulestore
the wrapper will strip and restore ccx values from CourseKey and UsageKey objects
fix return values on a few methods
remove unused symbol
pull updated ccx-keys package
set course_id on the caching descriptor system to avoid api incompatibilities in some subsystems
use ccx.course instead of self.course
fix get method to find course keys from blocks that are not themselves keys but have a location attribute (which will be a key)
if an item coming out of the db has children, restore the ccx to them as well
if the block passed in has a CCX key, unwrap that before we try to look up the override, otherwise it will never be found.
pick up a change in the ccx keys package that allows for stripping CCX identity from a usage key
begin writing tests to cover this modulestore wrapper
remove the switch_pocs view, the url pattern for it, and the tests that covered it
remove the ccx context and the middleware responsible for setting the current CCX. These are no longer needed
all dashboard views should raise 404 if a ccx is not provided by the coach_dashboard decorator
code quality
prevent errors resulting from trying to `get` a ccx based on non-unique criteria.
remove obsolete usage of ACTIVE_CCX_KEY
fix setUp method for grading tests to properly create grades for the ccx rather than for the course.
clean up reverse calls
code quality
adding docstrings to clarify purpose of this patch
fix bug in getting ccx for coach
fix grading views to properly fetch a ccx-ified course so that grades for that version will be calculated
fix small errors in modulestore implementation
fix errant merge marker
update call to get_current_ccx after key refactoring merged with tab changes
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
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]
