Sets the Enrollment API free of the modulestore by replacing modulestore queries with calls to the CourseOverview model. Course deletion invalidates the corresponding CourseOverview. XCOM-462.
Will allow Otto to revoke fulfillment of course seat products. Only server-to-server calls are currently allowed to deactivate or otherwise modify existing enrollments.
Credit modes are hidden by default, since the user
isn't allowed to select them on the track selection page.
This commit exposes credit modes through the enrollment
API so that consumers can see that a course has a credit
track.
The Enrollment API now returns the complete URL in the user_message_url field. Returning just the path can result in 404s if the consuming code simply redirects to the value of this field without first checking to see if the hostname is included. Using the full URL solves this problem for all clients.
This issue was not found sooner because the test helper used only tested for GeoIP embargoes, and neglected the user profile. An additional test has been added to test for embargoes against the country assigned to the user's profile. Additionally, variable names have been cleaned up--user replaced with username--to avoid confusion in the future.
When configured, set an additional cookie with the CSRF
token for use by subdomains.
The cookie can have a different name than the default
CSRF cookie, preventing conflicts between cookies
from different domains (e.g. ".edx.org", "courses.edx.org",
and "edge.edx.org").
The new cookie is included only on the enrollment API
views so that the scope of this change is limited
to the end-points that require cross-domain POST requests.
The new "country access" implementation replaces the old
implementation. Middleware and tests have been updated
accordingly, but deprecated models are preserved
for backwards compatibility.
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.
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]