1. 02 Jul, 2015 1 commit
  2. 30 Jun, 2015 1 commit
  3. 25 Jun, 2015 1 commit
  4. 23 Jun, 2015 2 commits
  5. 22 Jun, 2015 3 commits
  6. 10 Jun, 2015 1 commit
  7. 08 Jun, 2015 1 commit
  8. 01 Jun, 2015 1 commit
  9. 27 May, 2015 1 commit
  10. 12 May, 2015 1 commit
  11. 07 May, 2015 2 commits
  12. 05 May, 2015 2 commits
  13. 02 May, 2015 1 commit
  14. 30 Apr, 2015 1 commit
  15. 29 Apr, 2015 2 commits
  16. 27 Apr, 2015 1 commit
  17. 22 Apr, 2015 1 commit
  18. 10 Apr, 2015 1 commit
  19. 02 Apr, 2015 1 commit
  20. 20 Mar, 2015 1 commit
  21. 17 Mar, 2015 1 commit
  22. 14 Mar, 2015 1 commit
  23. 13 Mar, 2015 1 commit
  24. 12 Mar, 2015 1 commit
  25. 09 Mar, 2015 1 commit
  26. 06 Mar, 2015 1 commit
  27. 05 Mar, 2015 1 commit
  28. 02 Mar, 2015 1 commit
  29. 23 Feb, 2015 1 commit
  30. 10 Feb, 2015 1 commit
    • Country Access: block enrollment · e609f982
      Block users from enrolling in a course if the user
      is blocked by country access rules.
      
      1) Enrollment via the login/registration page.
      2) Enrollment from the marketing iframe (via student.views.change_enrollment)
      3) Enrollment using 100% redeem codes.
      4) Enrollment via upgrade.
      
      This does NOT cover enrollment through third party authentication,
      which is sufficiently complex to deserve its own commit.
      Will Daly committed
  31. 08 Feb, 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. 29 Jan, 2015 1 commit