When the list is empty in discussion blackout
on studio side it causes the exception on lms
side when we try to access the discussion. We
were expecting the values and try to parse it
in two values start and end date whereas parsing
empty values to two values causing the exception.
Now values will be parse when value exists. Empty
value will be ignored.
TNL-1390
Since we began monkey-patching `django.utils.translation` [1], we no
longer need to check for empty strings before translating them.
Previously, the empty string would be translated into translation
metadata. Now, translating the empty string intuitively yields the empty
string.
[1] 86633df3db
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]
Context: We have witnessed multiple, seemingly random "CSRF verification
failed" errors while signing in (with valid ID) to the Studio.
Explanation: The login form does not initially include a CSRF field.
The CSRF header of the request is appended to the studio login request
headers by intercepting the form validation. This intercept is performed
by the login.js script. Unfortunately, the login.js script is loaded
pretty late (at the end of the template). So if the login form is
validated sufficiently fast, the login.js script has no time to load and
append the X-CSRFToken header to the request.
Proposed solution: the CSRF token is already passed to the template via
the login view, so we just add a hidden field to the login form to
include the csrf token.
