Moves ENABLE_INSTRUCTOR_EMAIL and REQUIRE_COURSE_EMAIL_AUTH from settings files
to admin-accessible configuration models. This allows for the bulk email settings
to be modified without a new AMI deploy. See TNL-4504.
Also updates tests:
-python tests mock out the new configurations in place of the old settings
-lettuce test has been moved to bokchoy
(note that there was some loss of coverage here - the lettuce tests had
been doing some voodoo to allow for cross-process inspection of emails
messages being "sent" by the server, from the client! In discussion with
testeng, this seems outside the realm of a visual acceptance test. So,
the bokchoy test simply confirm the successful queueing of the message,
and leaves the validation of sending messages to the relevant unit tests.)
-bok choy fixture has been added, to replace the settings in acceptance.py
-lettuce and bok choy databases have been updated to reflect the backend changes
The new default is to have bulk_email disabled, we'll need to call this out in the
next OpenEdx release to ensure administrators enable this feature if needed.
individual students, and a reimplementation of the individual due date
feature.
This work introduces an architecture, used with the 'authored_data'
portion of LmsFieldData, which allows arbitrary field overrides to be
made for fields that are part of the course content or settings (Mongo
data). The basic architecture is extensible by means of writing and
configuring arbitrary field override providers.
One concrete implementation of a field override provider is provided
which allows for overrides to be for individual students. This provider
is then used as a basis for reimplementing the individual due date
extensions feature as a proof of concept for the design.
One can imagine writing override providers that provide overrides based
on a student's membership in a cohort or other similar idea. This work
is being done, in fact, to pave the way for the Personal Online Courses
feature being developed by MIT, which will use an override provider very
much long those lines.
The IDDE implementation relied on a StudentModule being created for a
particular block in order to set the extended due date on that block.
Since StudentModules seem to be created on demand whenever data is
written to an attribute with Scope.user_state, it meant that if a
homework problem hadn't yet been touched by a student it was possible
that the due date extension wouldn't take effect for that problem, even
if the due date extension was successfully set for the parent unit.
This patch fixes this problem by creating new StudentModules as
necessary in order to make sure extended due dates propogate properly to
all problems in a unit.
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]
Adds a feature to the edX platform which allows instructors to set
individual due dates for students on particular coursework. This code is
meant primarily for on-campus use--it is not intended that this feature
would be used for MOOCs. It adds a new tab, "Extensions", to the beta
instructor dashboard which allows changing due dates per student. This
feature is enabled by setting FEATURES['INDIVIDUAL_DUE_DATES'] = True.
Note: Alerts are pop-up boxes. Not sure if this is desireable, but I couldn't figure out
how to make a success message show up in the same place that error messages do.
