This commit adds the non-courseware lms/djangoapps and lms/lib.
These keys are now objects with a limited interface, and the particular
internal representation is managed by the data storage layer (the
modulestore).
For the LMS, there should be no outward-facing changes to the system.
The keys are, for now, a change to internal representation only. For
Studio, the new serialized form of the keys is used in urls, to allow
for further migration in the future.
Co-Author: Andy Armstrong <andya@edx.org>
Co-Author: Christina Roberts <christina@edx.org>
Co-Author: David Baumgold <db@edx.org>
Co-Author: Diana Huang <dkh@edx.org>
Co-Author: Don Mitchell <dmitchell@edx.org>
Co-Author: Julia Hansbrough <julia@edx.org>
Co-Author: Nimisha Asthagiri <nasthagiri@edx.org>
Co-Author: Sarina Canelake <sarina@edx.org>
[LMS-2370]
If this management command fails it's tough to figure out why without
seeing the text from the exception. Luckily comment service does
return useful feedback, we just have to show it. This one-line
change just add the exception text to the error message.
Before (with spurrious debug msgs removed):
sefk@util1:~$ ./manage.sh reload_forum_users Anthonyhubendurance
update user info to discussion failed for user with id: Anthonyhubendurance
After:
sefk@util1:~$ ./manage.sh reload_forum_users Anthonyhubendurance
update user info to discussion failed for user with id: Anthonyhubendurance, error=u'["Email is already taken"]'
No unit testing (sorry) added since this doesn't have coverage
already, and it's just a simple error case.
Features coming down the pipe will want to be able to:
* Refer to enrollments before they are actually activated (approval step).
* See what courses a user used to be enrolled in for when they re-enroll in
the same course, or a different run of that course.
* Have different "modes" of enrolling in a course, representing things like
honor certificate enrollment, auditing (no certs), etc.
This change adds an is_active flag and mode (with default being "honor").
The commit is only as large as it is because many parts of the codebase were
manipulating enrollments by adding and removing CourseEnrollment objects
directly. It was necessary to create classmethods on CourseEnrollment to
encapsulate this functionality and then port everything over to using them.
The migration to add columns has been tested on a prod replica, and seems to be
fine for running on a live system with single digit millions of rows of
enrollments.
loaded into the page in a data attribute instead of loaded on request via ajax.
The user profile page also does not provide facilities for adding
comments/responses, which I think would clutter the page too much.
Also removed some unused stuff from views.py.
