This reverts commit d58bd06928.
This commit caused performance issues due to increased API load from checking the
enterprise association on each page load
* User-facing links are gated; internal services are not.
* Adds view decorator data_sharing_consent_required
* Renames `get_course_specific_consent_url` to `get_enterprise_consent_url`,
which now checks `consent_needed_for_course` before returning a consent URL.
2. Update COMPREHNSIVE_THEME_DIR to COMPREHENSIVE_THEME_DIRS
3. Update paver commands to support multi theme dirs
4. Updating template loaders
5. Add ENABLE_COMPREHENSIVE_THEMING flag to enable or disable theming via settings
6. Update tests
7. Add backward compatibility for COMPREHEHNSIVE_THEME_DIR
* mattdrayer: Add helpers.get_value test
* mattdrayer: Change to simpler implementation, per @douglashall
* mattdrayer: Address quality violations and test failures
The test TestComprehensiveTheming.test_themed_footer in lms/djangoapps/course_wiki/tests/test_comprehensive_theming.py
fails when run immediately after lms.djangoapps.course_wiki.tests.test_middleware:TestWikiAccessMiddleware.test_url_tranform.
Until we have a chance to fix it, we're going to skip it to expedite merging
concurrent testing.
To reproduce the failure, remove the @skip decorator, and run:
paver test_system -s lms --disable-migrations --test_id='lms.djangoapps.course_wiki.tests.test_middleware lms.djangoapps.course_wiki.tests.test_comprehensive_theming' --no-randomize -v --processes=0
Comprehensive theming did not work with django templates (used by course wiki).
The reason it didn't work was that in order for the theme to work, theme template folder
has to be added to django template dirs setting *before* django startup.
After django startup, modifying `settings.DEFAULT_TEMPLATE_ENGINE['DIRS']` has no effect,
because at that point the template engine is already initialized with a copy of the
template dirs list.
Instead of running the theme startup code as an autostartup hook, we manually run it
*before* `django.setup()`. This is fine because theme startup code doesn't have to do
anything else besides modifying some settings and doesn't actually need django to be
initialized.
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
