configure middleware
add test for session inactive timeouts
add Studio inactive session timeout test
change login method used
add create_test_account to test
make sure the expected redirect URL is right
fix indenting problem
fix doc string since we moved from minutes to seconds
use utility methods rather than calling another test to set up and activate an account
clean up code violations
respond to PR feedback
use optional params to make code cleaner
pylint fix on test files
(STUD-1201)
Revert "Specific django-toolbar version (stable released) and update the panels in dev envs"
This reverts commit a465b082da.
Revert "Updated settings for devstack django debug toolbar"
This reverts commit 30199e8a61.
Added fixtures for course and xblock creation
Added bok-choy Studio tests
Added bok-choy tests for ora self- and ai- assessment
Refactored auto-auth; added staff and course-enrollment options
Removed extra javascript properties from page objects
fix errorenous logic when running a microsite that could reside in a hosting environment with a marketing site in front of it
pep8/pylint fixes
address PR feedback, remove underscore from test hostname
more pep8/pylint cleanup. Skip test_microsites test, it works on localdev, not on Jenkins. Need to talk with QA team
manually add Ned's single-to-double quote fix
change aws.py runtimes so that the microsite_dir that is read from configuration is changed to a python path
Conflicts:
lms/templates/help_modal.html
Refactored stub services for style and DRY
Added unit tests for stub implementations
Updated acceptance tests that depend on stubs.
Updated Studio acceptance tests to use YouTube stub server; fixed failing tests in devstack.
Studio doesn't do email changes, thus has no email reset template; thus, we must disable password/email-reset related tests when running with studio settings
I suspect there are very few circumstances that an enrollment event is emitted from the CMS, but if it ever were to happen, it would bomb out because the "crum" middleware is not used in that app. We are hoping to replace this request caching hack in the near future, but for now it is the best option we could come up with.
I noticed the stack appear when I created a new course in my dev environment. Presumably the course author is automatically enrolled in the course, which, causes the tracking code to bomb out. Luckily we catch the error and just log it, but we really should be capturing this type of enrollment event.
