1. 09 Dec, 2015 1 commit
  2. 04 Dec, 2015 1 commit
  3. 22 Nov, 2015 1 commit
  4. 10 Nov, 2015 1 commit
  5. 21 Oct, 2015 1 commit
  6. 14 Oct, 2015 1 commit
  7. 03 Aug, 2015 1 commit
  8. 31 Jul, 2015 1 commit
  9. 17 Jul, 2015 1 commit
  10. 16 Jul, 2015 1 commit
  11. 09 Jun, 2015 2 commits
  12. 11 May, 2015 1 commit
  13. 08 May, 2015 3 commits
  14. 07 May, 2015 1 commit
  15. 15 Apr, 2015 1 commit
  16. 08 Apr, 2015 2 commits
  17. 06 Apr, 2015 1 commit
  18. 23 Mar, 2015 1 commit
  19. 17 Mar, 2015 2 commits
  20. 14 Mar, 2015 1 commit
  21. 23 Feb, 2015 2 commits
  22. 20 Feb, 2015 2 commits
  23. 18 Feb, 2015 1 commit
  24. 10 Feb, 2015 1 commit
  25. 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
  26. 05 Jan, 2015 3 commits
  27. 11 Dec, 2014 1 commit
    • Implements keyword sub feature for bulk emails · 32bbb0e7
      This commit pulls in changes from #4487 that implements keyword
      substitution for bulk emails. With these changes, an instructor can
      include keywords in their bulk emails which will be automatically substituted
      with the corresponding value for the recepient of the email. Keywords are
      of the form %%keyword%%, and the keywords implemented in this commit include:
      
      %%USER_ID%% => anonymous_user_id
      %%USER_FULLNAME%% => user profile name
      %%COURSE_DISPLAY_NAME%% => display name of the course
      %%COURSE_END_DATE%% => end date of the course
      
      Client-side validations have also been implemented to ensure that only emails
      with well-formed keywords can be sent.
      The architecture is designed such that adding in new keywords in the future
      would be relatively straight-forward.
      njdup committed
  28. 02 Dec, 2014 1 commit
  29. 01 Dec, 2014 2 commits