diff --git a/common/djangoapps/mitxmako/middleware.py b/common/djangoapps/mitxmako/middleware.py
index 50f2840a05..64cb2e5415 100644
--- a/common/djangoapps/mitxmako/middleware.py
+++ b/common/djangoapps/mitxmako/middleware.py
@@ -46,4 +46,4 @@ class MakoMiddleware(object):
global requestcontext
requestcontext = RequestContext(request)
requestcontext['is_secure'] = request.is_secure()
- requestcontext['site'] = settings.SITE_NAME
+ requestcontext['site'] = request.get_host()
diff --git a/common/djangoapps/student/models.py b/common/djangoapps/student/models.py
index 55204f19f6..9cde878d21 100644
--- a/common/djangoapps/student/models.py
+++ b/common/djangoapps/student/models.py
@@ -273,7 +273,7 @@ def add_user_to_default_group(user, group):
utg.users.add(User.objects.get(username=user))
utg.save()
-# @receiver(post_save, sender=User)
+@receiver(post_save, sender=User)
def update_user_information(sender, instance, created, **kwargs):
try:
cc_user = cc.User.from_django_user(instance)
diff --git a/common/djangoapps/student/views.py b/common/djangoapps/student/views.py
index e7864337b3..ce15a2a003 100644
--- a/common/djangoapps/student/views.py
+++ b/common/djangoapps/student/views.py
@@ -511,7 +511,7 @@ def password_reset(request):
form.save(use_https = request.is_secure(),
from_email = settings.DEFAULT_FROM_EMAIL,
request = request,
- domain_override = settings.SITE_NAME)
+ domain_override = request.get_host())
return HttpResponse(json.dumps({'success':True,
'value': render_to_string('registration/password_reset_done.html', {})}))
else:
diff --git a/common/lib/capa/capa/correctmap.py b/common/lib/capa/capa/correctmap.py
index c727626a33..eb6ef2d00c 100644
--- a/common/lib/capa/capa/correctmap.py
+++ b/common/lib/capa/capa/correctmap.py
@@ -73,10 +73,12 @@ class CorrectMap(object):
return answer_id in self.cmap and self.cmap[answer_id]['queuekey'] == test_key
def get_npoints(self, answer_id):
- if self.is_correct(answer_id):
- npoints = self.cmap[answer_id].get('npoints', 1) # default to 1 point if correct
- return npoints or 1
- return 0 # if not correct, return 0
+ npoints = self.get_property(answer_id, 'npoints')
+ if npoints is not None:
+ return npoints
+ elif self.is_correct(answer_id):
+ return 1
+ return 0 # if not correct and no points have been assigned, return 0
def set_property(self, answer_id, property, value):
if answer_id in self.cmap: self.cmap[answer_id][property] = value
diff --git a/common/lib/xmodule/xmodule/css/sequence/display.scss b/common/lib/xmodule/xmodule/css/sequence/display.scss
index 05002e881d..7b8dc5f57c 100644
--- a/common/lib/xmodule/xmodule/css/sequence/display.scss
+++ b/common/lib/xmodule/xmodule/css/sequence/display.scss
@@ -61,13 +61,12 @@ nav.sequence-nav {
min-width: 20px;
a {
- width: 34px;
- height: 34px;
- margin: 4px auto;
- background-position: center 10px;
+ width: 100%;
+ height: 42px;
+ margin: 0;
+ background-position: center 14px;
background-repeat: no-repeat;
border: 1px solid transparent;
- @include border-radius(35px);
cursor: pointer;
display: block;
padding: 0;
@@ -82,7 +81,7 @@ nav.sequence-nav {
&:hover {
background-color: #fff;
background-repeat: no-repeat;
- background-position: center 10px;
+ background-position: center 14px;
}
&.active {
@@ -103,7 +102,7 @@ nav.sequence-nav {
&:hover {
background-color: #fff;
background-repeat: no-repeat;
- background-position: center 10px;
+ background-position: center 14px;
}
}
@@ -298,14 +297,16 @@ nav.sequence-bottom {
ul {
@extend .clearfix;
- border: 1px solid $border-color;
- @include border-radius(3px);
@include inline-block();
- width: 100px;
+ width: 103px;
li {
float: left;
- width: 50%;
+ width: 50px;
+ height: 44px;
+ border: 1px solid #ccc;
+ @include linear-gradient(top, #eee, #ddd);
+ @include box-shadow(0 1px 0 rgba(255, 255, 255, .7) inset);
&.prev, &.next {
margin-bottom: 0;
@@ -318,38 +319,39 @@ nav.sequence-bottom {
padding: lh(.5) 4px;
text-indent: -9999px;
@include transition(all, .2s, $ease-in-out-quad);
+ outline: 0;
&:hover {
- background-color: #ddd;
- color: #000;
opacity: .5;
- text-decoration: none;
+ background-position: center 15px;
}
&.disabled {
opacity: .4;
}
+
+ &:focus {
+ outline: 0;
+ }
}
}
&.prev {
+ border-radius: 35px 0 0 35px;
+
a {
background-image: url('../images/sequence-nav/previous-icon.png');
- border-right: 1px solid lighten(#c6c6c6, 10%);
-
- &:hover {
- background-color: none;
- }
+ background-position: center 15px;
}
}
&.next {
+ border-radius: 0 35px 35px 0;
+ border-left: none;
+
a {
background-image: url('../images/sequence-nav/next-icon.png');
-
- &:hover {
- background-color: none;
- }
+ background-position: center 15px;
}
}
}
@@ -360,5 +362,12 @@ div.course-wrapper section.course-content ol.vert-mod > li ul.sequence-nav-butto
list-style: none !important;
}
+.xmodule_SequenceModule nav.sequence-bottom ul li.next a,
+.xmodule_SequenceModule nav.sequence-bottom ul li.prev a {
+ outline: 0;
+ &:focus {
+ outline: 0;
+ }
+}
diff --git a/common/lib/xmodule/xmodule/js/src/sequence/display.coffee b/common/lib/xmodule/xmodule/js/src/sequence/display.coffee
index 38291be2ef..35a33a9ea1 100644
--- a/common/lib/xmodule/xmodule/js/src/sequence/display.coffee
+++ b/common/lib/xmodule/xmodule/js/src/sequence/display.coffee
@@ -55,6 +55,7 @@ class @Sequence
element.removeClass('progress-none')
.removeClass('progress-some')
.removeClass('progress-done')
+
switch progress
when 'none' then element.addClass('progress-none')
when 'in_progress' then element.addClass('progress-some')
diff --git a/doc/xml-format.md b/doc/xml-format.md
index 2a9e379ccc..55bcda4480 100644
--- a/doc/xml-format.md
+++ b/doc/xml-format.md
@@ -1,147 +1,305 @@
-This doc is a rough spec of our xml format
+# edX xml format tutorial
-Every content element (within a course) should have a unique id. This id is formed as {category}/{url_name}. Categories are the different tag types ('chapter', 'problem', 'html', 'sequential', etc). Url_name is a string containing a-z, A-Z, dot (.) and _. This is what appears in urls that point to this object.
+## Goals of this document
-File layout:
+* This was written assuming the reader has no prior programming/CS knowledge and has jumped cold turkey into the edX platform.
+* To educate the reader on how to build and maintain the back end structure of the course content. This is important for debugging and standardization.
+* After reading this, you should be able to add content to a course and make sure it shows up in the courseware and does not break the code.
+* __Prerequisites:__ it would be helpful to know a little bit about xml. Here is a [simple example](http://www.ultraslavonic.info/intro-to-xml/) if you've never seen it before.
-- Xml files have content
-- "policy", which is also called metadata in various places, should live in a policy file.
+## Outline
-- each module (except customtag and course, which are special, see below) should live in a file, located at {category}/{url_name].xml
-To include this module in another one (e.g. to put a problem in a vertical), put in a "pointer tag": <{category} url_name="{url_name}"/>. When we read that, we'll load the actual contents.
+* First, we will show a sample course structure as a case study/model of how xml and files in a course are organized to introductory understanding.
-Customtag is already a pointer, you can just use it in place:
+* More technical details are below, including discussion of some special cases.
-Course tags:
- - the top level course pointer tag lives in course.xml
- - have 2 extra required attributes: "org" and "course" -- organization name, and course name. Note that the course name is referring to the platonic ideal of this course, not to any particular run of this course. The url_name should be particular run of this course. E.g.
-If course.xml contains:
-
+## Introduction
-we would load the actual course definition from course/2012.xml
+* The course is organized hierarchically. We start by describing course-wide parameters, then break the course into chapters, and then go deeper and deeper until we reach a specific pset, video, etc.
-To support multiple different runs of the course, you could have a different course.xml, containing
+* You could make an analogy to finding a green shirt in your house - front door -> bedroom -> closet -> drawer -> shirts -> green shirt
-
-which would load the Harvard-internal version from course/2012H.xml
+## Case Study
-If there is only one run of the course for now, just have a single course.xml with the right url_name.
+Let's jump right in by looking at the directory structure of a very simple toy course:
-If there is more than one run of the course, the different course root pointer files should live in
-roots/url_name.xml, and course.xml should be a symbolic link to the one you want to run in your dev instance.
+ toy/
+ course
+ course.xml
+ problem
+ policies
+ roots
-If you want to run both versions, you need to checkout the repo twice, and have course.xml point to different root/{url_name}.xml files.
+The only top level file is `course.xml`, which should contain one line, looking something like this:
-Policies:
- - the policy for a course url_name lives in policies/{url_name}.json
+
-The format is called "json", and is best shown by example (though also feel free to google :)
+This gives all the information to uniquely identify a particular run of any course--which organization is producing the course, what the course name is, and what "run" this is, specified via the `url_name` attribute.
-the file is a dictionary (mapping from keys to values, syntax "{ key : value, key2 : value2, etc}"
+Obviously, this doesn't actually specify any of the course content, so we need to find that next. To know where to look, you need to know the standard organizational structure of our system: _course elements are uniquely identified by the combination `(category, url_name)`_. In this case, we are looking for a `course` element with the `url_name` "2012_Fall". The definition of this element will be in `course/2012_Fall.xml`. Let's look there next:
-Keys are in the form "{category}/{url_name}", which should uniquely id a content element.
-Values are dictionaries of the form {"metadata-key" : "metadata-value"}.
+`course/2012_Fall.xml`
-metadata can also live in the xml files, but anything defined in the policy file overrides anything in the xml. This is primarily for backwards compatibility, and you should probably not use both. If you do leave some metadata tags in the xml, please be consistent (e.g. if display_names stay in xml, they should all stay in xml).
- - note, some xml attributes are not metadata. e.g. in , the youtube attribute specifies what video this is, and is logically part of the content, not the policy, so it should stay in video/{url_name}.xml.
+
+
+
+
+
+
+
+
+
-Example policy file:
-{
- "course/2012": {
- "graceperiod": "1 day",
- "start": "2012-10-15T12:00",
- "display_name": "Introduction to Computer Science I",
- "xqa_key": "z1y4vdYcy0izkoPeihtPClDxmbY1ogDK"
- },
- "chapter/Week_0": {
- "display_name": "Week 0"
- },
- "sequential/Pre-Course_Survey": {
- "display_name": "Pre-Course Survey",
- "format": "Survey"
+Aha. Now we found some content. We can see that the course is organized hierarchically, in this case with only one chapter, with `url_name` "Overview". The chapter contains a `videosequence` and a `video`, with the sequence containing a problem and another video. When viewed in the courseware, chapters are shown at the top level of the navigation accordion on the left, with any elements directly included in the chapter below.
+
+Looking at this file, we can see the course structure, and the youtube urls for the videos, but what about the "warmup" problem? There is no problem content here! Where should we look? This is a good time to pause and try to answer that question based on our organizational structure above.
+
+As you hopefully guessed, the problem would be in `problem/warmup.xml`. (Note: This tutorial doesn't discuss the xml format for problems--there are chapters of edx4edx that describe it.) This is an instance of a _pointer tag:_ any xml tag with only the category and a url_name attribute will point to the file `{category}/{url_name}.xml`. For example, this means that our toy `course.xml` could have also been written as
+
+`course/2012_Fall.xml`
+
+
+
+
+
+with `chapter/Overview.xml` containing
+
+
+
+
+
+
+
+
+
+In fact, this is the recommended structure for real courses--putting each chapter into its own file makes it easy to have different people work on each without conflicting or having to merge. Similarly, as sequences get large, it can be handy to split them out as well (in `sequence/{url_name}.xml`, of course).
+
+Note that the `url_name` is only specified once per element--either the inline definition, or in the pointer tag.
+
+## Policy files
+
+We still haven't looked at two of the directoies in the top-level listing above: `policies` and `roots`. Let's look at policies next. The policy directory contains one file:
+
+ policies:
+ 2012_Fall.json
+
+and that file is named {course-url_name}.json. As you might expect, this file contains a policy for the course. In our example, it looks like this:
+
+ 2012_Fall.json:
+ {
+ "course/2012_Fall": {
+ "graceperiod": "2 days 5 hours 59 minutes 59 seconds",
+ "start": "2015-07-17T12:00",
+ "display_name": "Toy Course"
+ },
+ "chapter/Overview": {
+ "display_name": "Overview"
+ },
+ "videosequence/Toy_Videos": {
+ "display_name": "Toy Videos",
+ "format": "Lecture Sequence"
+ },
+ "problem/warmup": {
+ "display_name": "Getting ready for the semester"
+ },
+ "video/Video_Resources": {
+ "display_name": "Video Resources"
+ },
+ "video/Welcome": {
+ "display_name": "Welcome"
+ }
}
-}
-NOTE: json is picky about commas. If you have trailing commas before closing braces, it will complain and refuse to parse the file. This is irritating.
+The policy specifies metadata about the content elements--things which are not inherent to the definition of the content, but which describe how the content is presented to the user and used in the course. See below for a full list of metadata attributes; as the example shows, they include `display_name`, which is what is shown when this piece of content is referenced or shown in the courseware, and various dates and times, like `start`, which specifies when the content becomes visible to students, and various problem-specific parameters like the allowed number of attempts. One important point is that some metadata is inherited: for example, specifying the start date on the course makes it the default for every element in the course. See below for more details.
+
+It is possible to put metadata directly in the xml, as attributes of the appropriate tag, but using a policy file has two benefits: it puts all the policy in one place, making it easier to check that things like due dates are set properly, and it allows the content definitions to be easily used in another run of the same course, with the same or similar content, but different policy.
+
+## Roots
+
+The last directory in the top level listing is `roots`. In our toy course, it contains a single file:
+
+ roots/
+ 2012_Fall.xml
+
+This file is identical to the top-level `course.xml`, containing
+
+
+
+In fact, the top level `course.xml` is a symbolic link to this file. When there is only one run of a course, the roots directory is not really necessary, and the top-level course.xml file can just specify the `url_name` of the course. However, if we wanted to make a second run of our toy course, we could add another file called, e.g., `roots/2013_Spring.xml`, containing
+
+
+
+After creating `course/2013_Spring.xml` with the course structure (possibly as a symbolic link or copy of `course/2012_Fall.xml` if no content was changing), and `policies/2013_Spring.json`, we would have two different runs of the toy course in the course repository. Our build system understands this roots structure, and will build a course package for each root. (Dev note: if you're using a local development environment, make the top level `course.xml` point to the desired root, and check out the repo multiple times if you need multiple runs simultaneously).
+
+That's basically all there is to the organizational structure. Read the next section for details on the tags we support, including some special case tags like `customtag` and `html` invariants, and look at the end for some tips that will make the editing process easier.
+
+----------
+
+# Tag types
+
+* `abtest` -- Support for A/B testing. TODO: add details..
+* `chapter` -- top level organization unit of a course. The courseware display code currently expects the top level `course` element to contain only chapters, though there is no philosophical reason why this is required, so we may change it to properly display non-chapters at the top level.
+* `course` -- top level tag. Contains everything else.
+* `customtag` -- render an html template, filling in some parameters, and return the resulting html. See below for details.
+* `html` -- a reference to an html file.
+* `error` -- don't put these in by hand :) The internal representation of content that has an error, such as malformed xml or some broken invariant. You may see this in the xml once the CMS is in use...
+* `problem` -- a problem. See elsewhere in edx4edx for documentation on the format.
+* `problemset` -- logically, a series of related problems. Currently displayed vertically. May contain explanatory html, videos, etc.
+* `sequential` -- a sequence of content, currently displayed with a horizontal list of tabs. If possible, use a more semantically meaningful tag (currently, we only have `videosequence`).
+* `vertical` -- a sequence of content, displayed vertically. If possible, use a more semantically meaningful tag (currently, we only have `problemset`).
+* `video` -- a link to a video, currently expected to be hosted on youtube.
+* `videosequence` -- a sequence of videos. This can contain various non-video content; it just signals to the system that this is logically part of an explanatory sequence of content, as opposed to say an exam sequence.
+
+## Tag details
+
+### Container tags
+
+Container tags include `chapter`, `sequential`, `videosequence`, `vertical`, and `problemset`. They are all specified in the same way in the xml, as shown in the tutorial above.
+
+### `course`
+
+`course` is also a container, and is similar, with one extra wrinkle: the top level pointer tag _must_ have `org` and `course` attributes specified--the organization name, and course name. Note that `course` is referring to the platonic ideal of this course (e.g. "6.002x"), not to any particular run of this course. The `url_name` should be the particular run of this course.
+
+### `customtag`
+
+When we see ``, we will:
+
+* look for a file called `custom_tags/special` in your course dir.
+* render it as a mako template, passing parameters {'animal':'unicorn', 'hat':'blue'}, generating html. (Google `mako` for template syntax, or look at existing examples).
+
+Since `customtag` is already a pointer, there is generally no need to put it into a separate file--just use it in place:
-Valid tag categories:
+### `html`
-abtest
-chapter
-course
-customtag
-html
-error -- don't put these in by hand :)
-problem
-problemset
-sequential
-vertical
-video
-videosequence
+Most of our content is in xml, but some html content may not be proper xml (all tags matched, single top-level tag, etc), since browsers are fairly lenient in what they'll display. So, there are two ways to include html content:
-Obsolete tags:
-Use customtag instead:
- videodev
- book
- slides
- image
- discuss
+* If your html content is in a proper xml format, just put it in `html/{url_name}.xml`.
+* If your html content is not in proper xml format, you can put it in `html/{filename}.html`, and put `` in `html/{filename}.xml`. This allows another level of indirection, and makes sure that we can read the xml file and then just return the actual html content without trying to parse it.
-Ex: instead of