1. 20 Aug, 2015 3 commits
  2. 14 Jul, 2015 1 commit
  3. 03 Jul, 2015 1 commit
  4. 25 Jun, 2015 1 commit
  5. 17 Jun, 2015 1 commit
  6. 22 May, 2015 1 commit
  7. 20 May, 2015 3 commits
  8. 14 May, 2015 1 commit
  9. 11 May, 2015 1 commit
  10. 07 May, 2015 2 commits
  11. 02 Apr, 2015 1 commit
  12. 31 Mar, 2015 1 commit
  13. 30 Mar, 2015 2 commits
  14. 20 Mar, 2015 1 commit
  15. 19 Mar, 2015 1 commit
  16. 17 Mar, 2015 6 commits
  17. 16 Feb, 2015 1 commit
    • xblock-external-ui: Add XBlock API call to render XBlock views · 2ba49579
      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
      Xavier Antoviaque committed
  18. 10 Feb, 2015 1 commit
  19. 04 Feb, 2015 3 commits
    • Better support specifying of modulestore configuration in test cases · b353ed2e
      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]
      Calen Pennington committed
  20. 29 Jan, 2015 1 commit
  21. 28 Jan, 2015 1 commit
  22. 21 Jan, 2015 1 commit
  23. 16 Jan, 2015 2 commits
  24. 12 Jan, 2015 2 commits
  25. 19 Dec, 2014 1 commit