When you are on the Dashboard, or on any page in courseware, the logo
in the Header links to dashboard and the logo in the footer links
to edX home page.
LEARNER-2881
There are a number of Django Signals that are on the modulestore's
SignalHandler class, such as SignalHandler.course_published. These
signals can trigger very expensive processes to occur, such as course
overview or block structures generation. Most of the time, the test
author doesn't care about these side-effects.
This commit does a few things:
* Converts the signals on SignalHandler to be instances of a new
SwitchedSignal class, that allows signal sending to be disabled.
* Creates a SignalIsolationMixin helper similar in spirit to the
CacheIsolationMixin, and adds it to the ModuleStoreIsolationMixin
(and thus to ModuleStoreTestCase and SharedModuleStoreTestCase).
* Converts our various tests to use this new mechanism. In some cases,
this means adjusting query counts downwards because they no longer
have to account for publishing listener actions.
Modulestore generated signals are now muted by default during test runs.
Calls to send() them will result in no-ops. You can choose to enable
specific signals for a given subclass of ModuleStoreTestCase or
SharedModuleStoreTestCase by specifying an ENABLED_SIGNALS class
attribute, like the following example:
from xmodule.modulestore.tests.django_utils import ModuleStoreTestCase
class MyPublishTestCase(ModuleStoreTestCase):
ENABLED_SIGNALS = ['course_published', 'pre_publish']
You should take great care when disabling signals outside of a
ModuleStoreTestCase or SharedModuleStoreTestCase, since they can leak
out into other tests. Be sure to always clean up, and never disable
signals outside of testing. Because signals are essentially process
globals, it can have a lot of unpleasant side-effects if we start
mucking around with them during live requests.
Overall, this change has cut the total test execution time for
edx-platform by a bit over a third, though we still spend a lot in
pre-test setup during our test builds.
[PERF-413]
This adds functions to the catalog utils which munge data
collected from the program endpoint and LMS database to construct
data structures that are ready for use by view and templates
related to the Open EdX marketing pages that live in LMS.
WL-766
This commit contains back end changes necessary to load programs from the catalog in all contexts. The existing program munging utility is applied as late as possible to avoid conflating this work with changes to the front end; those will be made separately.
ECOM-4422
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
Serve branded footer JSON/HTML/CSS/JS from an API endpoint
in the branding app. Refactor OpenEdX and EdX.org footer templates
to use the Python version of the API, ensuring that the API
values are consistent with the footer included in main.html.
Detailed changes:
* Added footer API end-point to the branding app.
* Footer API allows the language to be set with querystring parameters.
* Footer API allows showing/hiding of the OpenEdX logo using querystring parameters.
* Deprecate ENABLE_FOOTER_V3 in favor of the branding API configuration flag.
* Move no referrer script into main.html from the edx footer template.
* Rename rwd_header_footer.js to rwd_header.js
* Cache API responses.
Authors:
Awais Qureshi, Aamir Khan, Will Daly
Update edx-lint to the version that checks if tearDown uses super.
Convert a number of tearDown methods into addCleanup.
Remove some unneeded tearDown methods: no need to call patch.stopall if
none of them were started with patch.start.
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]
