1. 22 Sep, 2017 1 commit
  2. 07 Aug, 2017 1 commit
  3. 12 Jun, 2017 1 commit
  4. 27 Apr, 2017 1 commit
  5. 11 Apr, 2017 1 commit
  6. 30 Mar, 2017 1 commit
  7. 07 Dec, 2016 1 commit
  8. 30 Nov, 2016 1 commit
  9. 07 Nov, 2016 1 commit
  10. 25 Oct, 2016 1 commit
  11. 20 Oct, 2016 1 commit
  12. 12 Oct, 2016 1 commit
  13. 06 Oct, 2016 1 commit
  14. 02 Oct, 2016 1 commit
  15. 30 Sep, 2016 3 commits
  16. 29 Sep, 2016 1 commit
  17. 12 Sep, 2016 1 commit
  18. 03 Aug, 2016 1 commit
  19. 08 Apr, 2016 1 commit
  20. 10 Mar, 2016 1 commit
  21. 22 Nov, 2015 1 commit
  22. 10 Nov, 2015 1 commit
  23. 01 Sep, 2015 1 commit
  24. 27 Aug, 2015 1 commit
    • [LTI Provider] Grade passback for non-leaf blocks. · 9e6c4491
      This change allows graded assignments to be added to a campus LMS
      regardless of the granularity at which the problem sits. Previously
      a grade could only be returned if the usage ID for the problem itself
      was specified in the LTI launch.
      
      The code assumes that courses taking advantage of this functionality
      are arranged in a hiearchy (with sections being parents to verticals,
      and verticals being parents to problems). When a grading event occurs
      it traverses the parent hiearchy to identify any previous graded LTI
      launches for which the new scoring event should generate a grade
      update. It then calculates and sends scores to each of those outcome
      services.
      
      Since grade calculation is an expensive operation, the code optimizes
      the case where a problem has been added only once as a leaf unit. In
      that case it is able to behave as before, just taking the grade from
      the signal without having to calculate grades for the whole course.
      Phil McGachey committed
  25. 26 Aug, 2015 1 commit
  26. 25 Aug, 2015 1 commit
  27. 24 Aug, 2015 1 commit
  28. 03 Aug, 2015 1 commit
  29. 29 Jun, 2015 1 commit
  30. 07 May, 2015 1 commit
  31. 17 Mar, 2015 1 commit
  32. 04 Feb, 2015 2 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
  33. 20 Jan, 2015 1 commit
  34. 02 Dec, 2014 1 commit
  35. 01 Dec, 2014 1 commit
  36. 31 Oct, 2014 1 commit
  37. 29 Sep, 2014 1 commit