1. 02 May, 2017 1 commit
  2. 27 Apr, 2017 1 commit
  3. 19 Apr, 2017 1 commit
  4. 18 Apr, 2017 1 commit
  5. 13 Apr, 2017 1 commit
  6. 05 Apr, 2017 1 commit
  7. 30 Mar, 2017 1 commit
  8. 20 Mar, 2017 1 commit
  9. 13 Mar, 2017 1 commit
  10. 08 Mar, 2017 1 commit
  11. 06 Mar, 2017 1 commit
  12. 01 Mar, 2017 1 commit
  13. 23 Feb, 2017 1 commit
    • Test Speedup: Isolate Modulestore Signals · 2051c909
      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]
      David Ormsbee committed
  14. 13 Feb, 2017 1 commit
  15. 30 Jan, 2017 1 commit
    • show button new library in studio depending on flags and user staff status · d112c0b8
      add flag DISABLE_LIBRARY_CREATION
      
      add comma
      
      use CourseCreatorRole to determine if user can create a library
      
      add disable library creation feature flag
      
      Conflicts:
      	cms/djangoapps/contentstore/views/course.py
      
      ENABLE_CONTENT_LIBRARIES flag
      
      check for course creator role for library creation
      
      Conflicts:
      	cms/djangoapps/contentstore/views/course.py
      
      add unit tests
      
      make check of creation of library a true/false for forntend, add security in api call, clean tests
      
      update tests
      
      fix docstring of tests
      
      fixed quality violation
      
      fixed broken unit test and quality violations
      
      Feedback changes and unit test to assert libraries are visible to non staff users too
      
      fixed quality violation and feedback changes
      jagonzalr committed
  16. 05 Jan, 2017 2 commits
  17. 28 Nov, 2016 1 commit
  18. 23 Nov, 2016 1 commit
  19. 10 Nov, 2016 1 commit
  20. 19 Oct, 2016 1 commit
  21. 11 Oct, 2016 1 commit
  22. 27 Sep, 2016 1 commit
  23. 23 Sep, 2016 1 commit
  24. 02 Sep, 2016 2 commits
  25. 15 Aug, 2016 1 commit
  26. 10 Aug, 2016 1 commit
  27. 04 Aug, 2016 1 commit
  28. 03 Aug, 2016 2 commits
  29. 29 Jul, 2016 1 commit
  30. 21 Jul, 2016 2 commits
  31. 05 Jul, 2016 1 commit
    • [PERF-344] Add versioning of cached course assets to allow graceful cache invalidation · 4e22affb
      When releasing the versioned assets work, we stumbled on a problem with old pickled
      versions of the StaticContent objects residing in cache, which triggered a bug in the
      code. Not wanting to blow away all cached items, we ended up having to revert and add
      in some backwards-compatible helper code to ease the transition.
      
      With this, we'll now utilize the version argument that Django's caching interface
      allows, in conjunction with a constant value that can be modified when breaking changes
      are being made, to let us gracefully ignore older cached course assets.
      Toby Lawrence committed
  32. 27 Jun, 2016 1 commit
  33. 24 Jun, 2016 1 commit
  34. 23 Jun, 2016 1 commit
  35. 22 Jun, 2016 1 commit
  36. 16 Jun, 2016 1 commit
    • update_in_cache on lms worker (#12689) · fdc6d915
      This commit "undoes"a previous hotfix, and allows a cms course_publish
      signal to trigger a block_structure update_course_in_cache task, which
      is run on an lms worker queue.
      
      Changes:
          -exposes ALTERNATE_QUEUE_ENVS
          -adds routing layer in celery.py
          -moves prior dev_with_worker settings file to devstack_with_worker
          -moves course_block api functionality into openedx/core/djangoapps/content/block_structure
      Eric Fischer committed