1. 23 Sep, 2016 1 commit
  2. 03 Aug, 2016 4 commits
  3. 08 Jun, 2016 2 commits
  4. 18 May, 2016 1 commit
  5. 04 May, 2016 1 commit
  6. 02 May, 2016 1 commit
  7. 28 Apr, 2016 1 commit
  8. 05 Apr, 2016 1 commit
  9. 22 Feb, 2016 1 commit
  10. 03 Dec, 2015 1 commit
  11. 22 Nov, 2015 1 commit
  12. 10 Nov, 2015 1 commit
  13. 21 Oct, 2015 1 commit
  14. 25 Aug, 2015 1 commit
  15. 07 Aug, 2015 1 commit
  16. 17 Jul, 2015 1 commit
  17. 16 Jul, 2015 1 commit
  18. 13 Jul, 2015 2 commits
  19. 02 Jul, 2015 1 commit
  20. 19 Jun, 2015 1 commit
  21. 06 Jun, 2015 1 commit
  22. 30 Apr, 2015 1 commit
  23. 17 Mar, 2015 2 commits
  24. 04 Feb, 2015 1 commit
    • 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
  25. 30 Jan, 2015 1 commit
    • Make logistration generally available if feature flag is active · a8bed5ce
      Makes logistration available at /login and /register as well as /accounts/login/ and /accounts/register/. In addition:
      
      - Adds support for redirect URLs in third party auth for combined login/registration page
      - Adds support for external auth on the combined login/registration page
      - Removes old login and registration acceptance tests
      - Adds deprecation warnings to old login and register views
      - Moves third party auth util to student_account
      - Adds exception for microsites (theming)
      Renzo Lucioni committed
  26. 14 Jan, 2015 1 commit
  27. 05 Dec, 2014 1 commit
  28. 04 Dec, 2014 1 commit
  29. 02 Dec, 2014 2 commits
  30. 01 Dec, 2014 3 commits
  31. 10 Nov, 2014 1 commit