Following have been done
1- Change the structure of the course navigation Menu HTML
2- Add some basic styling
3- Add basic JS for html rendering
4- Update tests according to new structure
AC-76
Templates that display the image now check if courses specifies an image, if they don't the default image is displayed
Path set in both common.py and aws.py to allow for easy overriding in one place.
Addresses SOL-926
Some code provided by Davorin Sego
The string "</script>" in JSON data would end the script element we're
embedding the data in. To make sure the data doesn't disrupt the
script, we escape the slash as \/ .
xblock-external-ui: Include CSRF token in the API answer
xblock-external-ui: Include full path when building local_url
xblock-external-ui: Fix TestHandleXBlockCallback & bok_choy, add tests
xblock-external-ui: Only return `instance` in `_invoke_xblock_handler()`
xblock-external-ui: Group resources by hash tag to avoid duplicate loads
xblock-external-ui: PEP8
xblock-external-ui: Fail early if the XBlock view is called anonymously
We used to serve anonymous requests, but most XBlocks assume that the
user is logged in, which can generate a lot of errors when the user is
accessed or when an XBlock ajax callback is queried. Fail early to only
get one error per page load, and prevent displaying the XBlock
altogether when the LMS doesn't find an active user session.
xblock-external-ui: Add request params in view render context
xblock-external-ui: HTTP error status when file is too large for handler
xblock-external-ui: Fix unicode encodings in XBlock rendering
xblock-external-ui: Feature flag for API call ENABLE_XBLOCK_VIEW_ENDPOINT
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]
