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]