2. Add site configuration overrides to theming/helpers.py
3. Move microsite.get_value from theming/helpers to site_configuration/helpers
4. Move microsite_configuration.microsite.get_value usages to site_configuration.helpers.values
A named outer is suitable when dealing with IntegrityErrors. It only
checks that it is not nested under an atomic only if it is nested
under enable_outer_atomic(name=<name>). This way only the view which
is causing IntegrityErrors needs to have its automatic transaction
management disabled and other callers are not effected.
* Initial commit of Sailthru lms changes
* Field mapping changes for Sailthru integration
* Merge fix
* Add users to Sailthru list on registration
* FIx minor code format issues
* Several updates based on code review feedback
* Updates based on recomendations from Sailthru
* Clean up unit tests
* Fix last login
* Updates based on code review feedback
* Updates based on code review feedback
* Fix comment
* Cleanup
TNL-4356
Allows multiple bulk email targets to be specified at once.
-The previous "All" option has been split into "Staff" and "Learners"
-The backend changes made here lay the groundwork for cohort emailing
-The data migration, 0005, is somewhat large and requires deploy attention
-Tests have been updated
-Numerous safe-commit-linter fixes are included
The TestCase API doesn't accept arguments, so passing arguments for some
TestCase subclasses makes adding new inheritance/mixins tricky. Instead,
prefer configuration via class attributes for TestCases.
-Updated method "course_key_from_string_or_404" to raise message too.
-Wrote tests for "course_key_from_string_or_404" when exception message is given.
-Modified existing methods to use "ddt.data".
-Used Splunk logs to find exectly where we were getting "Invalid Key Error"
-Updated Views where we were getting "Invalid Key Error" in splunk logs.
-Wrote tests for those View End points where we were getting "Invalid Key Error"
By default, migrations are applied as they always have been. Exporting DISABLE_MIGRATIONS=1 or passing --disable-migrations to Paver commands will create tables directly from apps' models.
Cached values were leaking across tests, causing difficult to debug errors,
particularly when using Config Models. As part of this work, certain tests
that had query counts that relied on those values being cached needed to
be adjusted up.
This hardcoded the db_alias fetched from schema_editor and forces django
to try and migrate any second database you use, rather than routing to
the default database. In testing a build from scratch, these do not
appear needed.
Using using() prevents us from using multiple databases behind edxapp.
Additionally - add back a removed backwards migration from certificates
0003. I have no idea why this was dropped in the 1.8 upgrade.
