Commit 31ab28ee by Mark Hoeber

Merge pull request #1993 from edx/markhoeber/documentation/analytics-sprint-12

Markhoeber/documentation/analytics sprint 12
parents 7547c540 4b1431bf
......@@ -28,4 +28,7 @@ copyright = u'2013, edX Documentation Team'
# The short X.Y version.
version = ''
# The full version, including alpha/beta/rc tags.
release = ''
\ No newline at end of file
release = ''
#Added to turn off smart quotes so users can copy JSON values without problems.
html_use_smartypants = False
\ No newline at end of file
......@@ -129,9 +129,13 @@ and that file is named `{course-url_name}.json`. As you might expect, this file
}
}
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.
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.
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
=====
......@@ -346,7 +350,7 @@ Supported fields at the course level
* - `tabs`
- have custom tabs in the courseware. See below for details on config.
* - `discussion_blackouts`
- An array of time intervals during which you want to disable a student's ability to create or edit posts in the forum. Moderators, Community TAs, and Admins are unaffected. You might use this during exam periods, but please be aware that the forum is often a very good place to catch mistakes and clarify points to students. The better long term solution would be to have better flagging/moderation mechanisms, but this is the hammer we have today. Format by example: `[["2012-10-29T04:00", "2012-11-03T04:00"], ["2012-12-30T04:00", "2013-01-02T04:00"]]`
- An array of time intervals during which you want to disable a student's ability to create or edit posts in the forum. Moderators, Community TAs, and Admins are unaffected. You might use this during exam periods, but please be aware that the forum is often a very good place to catch mistakes and clarify points to students. The better long term solution would be to have better flagging/moderation mechanisms, but this is the hammer we have today. Format by example: `[[""2012-10-29T04:00", "2012-11-03T04:00"], ["2012-12-30T04:00", "2013-01-02T04:00"]]`
* - `show_calculator`
- (value "Yes" if desired)
* - `days_early_for_beta`
......
......@@ -378,21 +378,40 @@ A row in this table represents a student's enrollment for a particular course ru
==========================
A row in this table maps a student's real user ID to an anonymous ID generated to obfuscate the student's identity.
`id`
.. list-table::
:widths: 15 15 15 15
:header-rows: 1
* - Field
- Type
- Null
- Key
* - hashid
- int(11)
- NO
- PRI
* - id
- int(11)
- NO
-
* - username
- varchar(30)
- NO
-
`hash_id`
----
Primary key.
The user ID generated to obfuscate the student's identity.
`user_id`
---------
Student's ID in `auth_user.id`
The student's ID in `auth_user.id`.
`anonymous_user_id`
-----------
The user ID generated to obfuscate the student's identity.
`course_id`
`username`
-----------
The ID of the course run the student is enrolled in.
The student's username in `auth_user.id`.
......
......@@ -2,133 +2,243 @@
Wiki Data
##############################
The following sections detail how edX stores Wiki data internally, and is useful for developers and researchers who are examining database exports. This information includes demographic information collected at signup, course enrollment, course progress, and certificate status.
The following sections detail how edX stores Wiki data internally, and is useful for developers and researchers who are examining database exports.
Conventions to keep in mind:
* edX currently uses an external application called Django Wiki for Wiki functionality within courses.
EdX currently uses an external application called Django Wiki for Wiki functionality within courses.
****************
Notification Type
wiki_article
****************
The `notifications` table stores . It has the following fields::
.. list-table::
:widths: 15 15 15 15
:header-rows: 1
* - Field
- Type
- Null
- Key
* - id
- int(11)
- NO
- PRI
* - current_revision_id
- int(11)
- NO
- UNI
* - created
- datetime
- NO
-
* - modified
- datetime
- NO
-
* - owner_id
- int(11)
- YES
- MUL
* - group_id
- int(11)
- YES
- MUL
* - group_read
- tinyint(1)
- NO
-
* - group_write
- tinyint(1)
- NO
-
* - other_read
- tinyint(1)
- NO
-
* - other_write
- tinyint(1)
- NO
-
`id`
----
The primary key.
+------------------------------+--------------+------+-----+
| Field | Type | Null | Key |
+------------------------------+--------------+------+-----+
| key | varchar(128) | NO | PRI |
| label | varchar(128) | YES | |
| content_type | ForeignKey | YES | |
+------------------------------+--------------+------+-----+
`current_revision_id`
------------------------------
The ID of the revision that is displayed for this article.
`key`
----
Primary key . . .
`label`
----------
The label for the notification . . .
`created`
------------
The date the article was created.
`content_type`
`modified`
------------
The date the article properties were last modified.
`owner_id`
------------
The owner of the article, usually the creator. The owner always has both read and write access.
`group_id`
------------
As in a UNIX file system, permissions can be given to a user according to group membership.
Groups are handled through the Django auth system.
`group_read`
------------
A foreign key . . .
Whether the group has read access to the article.
`group_write`
--------------
Whether the group has write access to the article.
`other_read`
------------
Whether others have read access to the article.
`other_write`
----------------------
Whether others have read access to the article.
**********************
wiki_articlerevision
**********************
.. list-table::
:widths: 15 15 15 15
:header-rows: 1
* - Field
- Type
- Null
- Key
* - id
- int(11)
- NO
- PRI
* - revision_number
- int(11)
- NO
-
* - user_message
- longtext
- NO
-
* - automatic_log
- longtext
- NO
-
* - ip_address
- char(15)
- YES
-
* - user_id
- int(11)
- YES
- MUL
* - modified
- datetime
- NO
-
* - created
- datetime
- NO
-
* - previous_revision_id
- int(11)
- YES
- MUL
* - deleted
- tinyint(1)
- NO
-
* - locked
- tinyint(1)
- NO
-
* - article_id
- int(11)
- NO
- MUL
* - content
- longtext
- NO
-
* - title
- varchar(512)
- NO
-
`id`
----
The primary key.
****************
Settings
****************
The `Settings` table stores . It has the following fields::
`revision_number`
--------------------
The ID of the revision.
+------------------------------+--------------+------+-----+
| Field | Type | Null | Key |
+------------------------------+--------------+------+-----+
| user | ForeignKey | NO | PRI |
| interval | smallint(6) | NO | |
+------------------------------+--------------+------+-----+
`user`
----
Primary key . . .
`user_message`
----------------------
The message the user added when saving the revision.
`interval`
----------
The . . .
`automatic_log`
----------------------
****************
Subscriptions
****************
`user_id`
------------
The ID of the user who made the revision.
The `Subscriptions` table stores . It has the following fields::
+------------------------------+--------------+------+-----+
| Field | Type | Null | Key |
+------------------------------+--------------+------+-----+
| settings | ForeignKey | NO | PRI |
| notification_type | ForeignKey | NO | |
| object_id | varchar(64) | YES | |
| send_emails | boolean | NO | |
+------------------------------+--------------+------+-----+
`modified`
------------
The date the article was last modified.
`settings`
----
Primary key . . .
`created`
------------
The date the article was created.
`notification type`
----------
The . . .
`object_id`
----
Primary key . . .
`send_emails`
----------
The . . .
****************
Notification
****************
`previous_revision_id`
----------------------
The ID of the revision previous to this one.
The `Notification` table stores . It has the following fields::
`deleted`
------------
Whether or not the revision was deleted.
+------------------------------+--------------+------+-----+
| Field | Type | Null | Key |
+------------------------------+--------------+------+-----+
| subscription | ForeignKey | NO | PRI |
| message | text | NO | |
| url | URLField | YES | |
| is_viewed | boolean | NO | |
| is_emailed | boolean | NO | |
| created | datetime | NO | |
+------------------------------+--------------+------+-----+
`subscription`
----
Primary key . . .
`locked`
------------
Whether or not the revision is locked.
`article_id`
--------------------
The ID of the revision that is displayed for this article.
`message`
----------
The . . .
`url`
----
Primary key . . .
`is_viewed`
`content`
------------
The content of the article revision.
`title`
----------
The . . .
The title of the article revision.
`is_emailed`
----------
The . . .
`created`
----------
The . . .
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment