5. Student Info and Progress Data¶

5.3.1.1. id¶

Primary key, and the value typically used in URLs that reference the user. A user has the same value for id here as they do in the MongoDB database’s users collection. Foreign keys referencing auth_user.id will often be named user_id, but are sometimes named student_id.

5.3.1.2. username¶

The unique username for a user in the edX system. It can contain alphanumerics and the special characters shown within the brackets: [ _ @ + - . ]. The username is the only user-provided information that other users can currently see. EdX has never allowed users to change usernames, but might do so in the future.

5.3.1.3. first_name¶

Not used; a user’s full name is stored in auth_userprofile.name instead.

5.3.1.4. last_name¶

Not used; a user’s full name is stored in auth_userprofile.name instead.

5.3.1.5. email¶

The user’s email address, which is the primary mechanism users use to log in. This value is optional by default in Django, but is required by edX. This value must be unique to each user and is never shown to other users.

5.3.1.6. password¶

A hashed version of the user’s password. Depending on when the password was last set, this will either be a SHA1 hash or PBKDF2 with SHA256 (Django 1.3 uses the former and 1.4 the latter).

5.3.1.7. is_staff¶

Most users have a 0 for this field. Set to 1 if the user is a staff member of edX, with corresponding elevated privileges that cut across courses. It does not indicate that the person is a member of the course team for any given course.

Generally, users with this flag set to 1 are either edX partner managers responsible for course delivery, or edX developers who need access for testing and debugging purposes. Users who have is_staff = 1 have Admin privileges on all courses and can see additional debug information on the Instructor Dashboard.

5.3.1.8. is_active¶

This value is 1 if the user has clicked on the activation link that was sent to them when they created their account, and 0 otherwise.

Users who have is_active = 0 generally cannot log into the system. However, when users first create an account, they are automatically logged in even though they have not yet activated the account. This is to let them experience the site immediately without having to check their email. A message displays on the dashboard to remind users to check their email and activate their accounts when they have time. When they log out, they cannot log back in again until activation is complete. However, because edX sessions last a long time, it is possible for someone to use the site as a student for days without being “active”.

Once is_active is set to 1, it is only set back to 0 if the user is banned (which is a very rare, manual operation).

5.3.1.9. is_superuser¶

Controls access to django_admin views. Set to 1 (true) only for site admins. 0 for almost everybody.

History: Only the earliest developers of the system have this set to 1, and it is no longer really used in the codebase.

5.3.1.10. last_login¶

A datetime of the user’s last login. Should not be used as a proxy for activity, since people can use the site all the time and go days between logging in and out.

5.3.1.11. date_joined¶

Date that the account was created.

5.3.1.12. Obsolete columns¶

All of the following columns were added by an application called Askbot, a discussion forum package that is no longer part of the system.

• status
• email_key
• avatar_typ
• country
• show_country
• date_of_birth
• interesting_tags
• ignored_tags
• email_tag_filter_strategy
• display_tag_filter_strategy
• consecutive_days_visit_count

Only users who were part of the prototype 6.002x course run in the Spring of 2012 have any information in these columns. Even for those users, most of this information was never collected. Only the columns with values that are automatically generated have any values in them, such as the tag-related columns.

These columns are unrelated to the discussion forums that edX currently uses, and will eventually be dropped from this table.

5.3.2.1. id¶

Primary key, not referenced anywhere else.

5.3.2.2. user_id¶

A foreign key that maps to auth_user.id.

5.3.2.3. name¶

String for a user’s full name. EdX makes no constraints on language or breakdown into first/last name. The names are never shown to other students. International students usually enter a romanized version of their names, but not always. Name changes are permitted, and the previous name is logged in the meta field.

History: A former edX policy required manual approval of name changes to guard the integrity of the certificates. Students would submit a name change request, and an edX team member would approve or reject the request.

5.3.2.4. language¶

No longer used.

History: User’s preferred language, asked during the sign up process for the 6.002x prototype course given in the Spring of 2012. Sometimes written in those languages. EdX stopped collecting this data after MITx transitioned to edX, but never removed the values for the first group of students.

5.3.2.5. location¶

No longer used.

History: User’s location, asked during the sign up process for the 6.002x prototype course given in the Spring of 2012. The request was not specific, so people tended to put the city they were in, though some just supplied a country and some got as specific as their street address. Again, sometimes romanized and sometimes written in their native language. Like language, edX stopped collecting this column after MITx transitioned to edX, so it is only available for the first batch of students.

5.3.2.6. meta¶

An optional, freeform text field that stores JSON data. This field allows us to associate arbitrary metadata with a user. An example of the JSON that can be stored in this field follows, using pretty print for an easier-to-read display format.

{
 "old_names": [
   [
     "Mike Smith",
     "Mike's too informal for a certificate.",
     "2012-11-15T17:28:12.658126"
   ],
   [
     "Michael Smith",
     "I want to add a middle name as well.",
     "2013-02-07T11:15:46.524331"
   ]
 ],
 "old_emails": [
   [
     "mr_mike@email.com",
     "2012-10-18T15:21:41.916389"
   ]
 ],
 "6002x_exit_response": {
   "rating": [
     "6"
   ],
   "teach_ee": [
     "I do not teach EE."
   ],
   "improvement_textbook": [
     "I'd like to get the full PDF."
   ],
   "future_offerings": [
     "true"
   ],
   "university_comparison": [
     "This course was <strong>on the same level<\/strong> as the university class."
   ],
   "improvement_lectures": [
     "More PowerPoint!"
   ],
   "highest_degree": [
     "Bachelor's degree."
   ],
   "future_classes": [
     "true"
   ],
   "future_updates": [
     "true"
   ],
   "favorite_parts": [
     "Releases, bug fixes, and askbot."
   ]
 }
}

Details about this metadata follow. Please note that the “fields” described here are found as JSON attributes inside a given meta field, and are not separate database columns of their own.

old_names

A list of the previous names this user had, and the timestamps at which they submitted a request to change those names. These name change request submissions used to require a staff member to approve it before the name change took effect. This is no longer the case, though their previous names are still recorded.

Note that the value stored for each entry is the name they had, not the name they requested to get changed to. People often changed their names as the time for certificate generation approached, to replace nicknames with their actual names or correct spelling/punctuation errors.

The timestamps are UTC, like all datetimes stored in the edX database.

old_emails

A list of previous emails this user had, with timestamps of when they changed them, in a format similar to old_names. There was never an approval process for this.

The timestamps are UTC, like all datetimes stored in the edX database.

6002x_exit_response

Answers to a survey that was sent to students after the prototype 6.002x course in the Spring of 2012. The questions and number of questions were randomly selected to measure how much survey length affected response rate. Only students from this course have this field.

5.3.2.7. courseware¶

No longer used.

History: At one point, it was part of a way to do A/B tests, but it has not been used for anything meaningful since the conclusion of the prototype course in the spring of 2012.

5.3.2.8. gender¶

Collected during student signup from a drop-down list control.

Value	Description
f	Female
m	Male
o	Other/Prefer Not to Say
(blank)	User did not specify a gender.
NULL	This student signed up before this information was collected.

History: This information began to be collected after the transition from MITx to edX; prototype course students have NULL for this field.

5.3.2.9. mailing_address¶

Collected during student registration from a text field control. A blank string for students who elect not to enter anything.

This column can contain multiple lines, which are separated by ‘\r\n‘.

History: This information began to be collected after the transition from MITx to edX; prototype course students have NULL for this field.

5.3.2.10. year_of_birth¶

Collected during student registration from a drop-down list control. NULL for students who decide not to fill this in.

History: This information began to be collected after the transition from MITx to edX; prototype course students have NULL for this field.

5.3.2.11. level_of_education¶

Collected during student registration from a drop-down list control.

Value	Description
p	Doctorate.
m	Master’s or professional degree.
b	Bachelor’s degree.
a	Associate degree.
hs	Secondary/high school.
jhs	Junior secondary/junior high/middle school.
el	Elementary/primary school.
none	No Formal Education.
other	Other Education.
(blank)	User did not specify level of education.
p_se	Doctorate in science or engineering (no longer used).
p_oth	Doctorate in another field (no longer used).
NULL	This student signed up before this information was collected.

History: Data began to be collected in this column after the transition from MITx to edX; prototype course students have NULL for this field.

5.3.2.12. goals¶

Collected during student registration from a text field control with the label “Goals in signing up for edX”. A blank string for students who elect not to enter anything.

This column can contain multiple lines, which are separated by ‘\r\n‘.

History: This information began to be collected after the transition from MITx to edX; prototype course students have NULL for this field.

5.3.2.13. allow_certificate¶

Set to 1 (true).

History: Prior to 10 Feb 2014, this field was set to 0 (false) if log analysis revealed that the student was accessing the edX site from a country that the U.S. had embargoed. This restriction is no longer in effect, and on 10 Feb 2014 this value was changed to 1 for all users.

5.3.2.14. country¶

Stores a two digit country code based on the selection made by the student during registration. Set to an empty string for students who do not select a country.

History: Added in Jan 2014, but not implemented until 18 Sep 2014. Null for all user profiles created before 18 Sep 2014.

5.3.2.15. city¶

Not currently used. Set to null for all user profiles.

History: Added in Jan 2014, not yet implemented.

5.3.2.16. bio¶

Stores one or more paragraphs of biographical information that the learner enters. The maximum number of characters is 3000.

History: Added 22 April 2015.

5.3.2.17. profile_image_uploaded_at¶

Stores the date and time when a learner uploaded a profile image.

History: Added 22 April 2015.

5.3.3.1. id¶

Primary key.

5.3.3.2. user_id¶

Student’s ID in auth_user.id.

5.3.3.3. course_id¶

The ID of the course run that the user is enrolling in, in the format {key type}:{org}+{course}+{run}. For example, course-v1:edX+DemoX+Demo_2014. When you view the course content in your browser, the course_id appears as part of the URL. For example, http://www.edx.org/courses/course-v1:edX+DemoX+Demo_2014/info.

History: In October 2014, identifiers for some new courses began to use the format shown above. Other new courses, and all courses created prior to October 2014, use the format {org}/{course}/{run}, for example, MITx/6.002x/2012_Fall. The URL format for a course with a course_id in this format was https://www.edx.org/courses/MITx/6.002x/2012_Fall/info.

5.3.3.4. created¶

Stores the date and time that this row was created, in UTC format.

5.3.3.5. is_active¶

Boolean indicating whether this enrollment is active. If an enrollment is not active, a student is not enrolled in that course. For example, if a student decides to unenroll from the course, is_active is set to 0 (false). The student’s state in courseware_studentmodule is untouched, so courseware state is not lost if a student unenrolls and then re-enrolls.

is_active can also be set to 0 if a student begins the process of enrolling in a course by purchasing a verified certificate, but then abandons the shopping cart before completing the purchase (and the enrollment).

History: This column was introduced in the 20 Aug 2013 release. Before this release, unenrolling a student simply deleted the row in student_courseenrollment.

5.3.3.6. mode¶

String indicating what kind of enrollment this is: audit, honor, professional, verified, or blank.

History:

• On 1 Dec 2015, the “audit” value was reintroduced. This value now identifies learners who choose an enrollment option that is not certificate eligible.
• On 23 Oct 2014, the “audit” value was deprecated.
• On 29 Sep 2014, the “professional” and “no-id-professional” values were added for courses on edx.org.
• On 20 Aug 2013, the “audit” and “verified” values were added.
• All enrollments prior to 20 Aug 2013 were “honor”.

5.3.4.1. user_id¶

The student’s ID in auth_user.id.

5.3.4.2. course_id¶

The course identifier, in the format {key type}:{org}+{course}+{run}. For example, course-v1:edX+DemoX+Demo_2014.

History: In October 2014, identifiers for some new courses began to use the format shown above. Other new courses, and all courses created prior to October 2014, use the format {org}/{course}/{run}, for example, MITx/6.002x/2012_Fall.

5.3.4.3. key¶

Identifies an attribute of the course.

For example, for a course that includes modules that are set up to perform content experiments, the value in this column identifies a partition, or type of experiment. The key for the partition is in the format xblock.partition_service.partition_ID, where ID is an integer.

5.3.4.4. value¶

The content for the key that is set for a student.

For example, for a course that includes modules that are set up to perform content experiments, this column stores the group ID of the particular group the student is assigned to within the partition.

5.3.5.1. hash_id¶

The user ID generated to obfuscate the student’s identity.

5.3.5.2. id¶

The student’s ID in auth_user.id.

5.3.5.3. username¶

The student’s username in auth_user.username.

5.3.6.1. id¶

A database auto-increment field that uniquely identifies the learner, and acts as the primary key.

5.3.6.2. user_id¶

The learner’s ID in auth_user.id.

5.3.6.3. anonymous_user_id¶

The anonymous ID assigned to the learner.

5.3.6.4. course_id¶

The course identifier, in the format {key type}:{org}+{course}+{run}. For example, course-v1:edX+DemoX+Demo_2014.

5.3.7.1. id¶

A database auto-increment field that uniquely identifies the language. This field is not exposed through the API.

5.3.7.2. user_profile_id¶

Specifies the ID in the authuser_profile table that is associated with a particular language proficiency.

5.3.7.3. code¶

The language code. Most codes are ISO 639-1 codes, with the addition of codes for simplified and traditional Chinese.

5.3.8.1. id¶

The primary key, a database auto-increment field that uniquely identifies the team.

5.3.8.2. team_id¶

The unique identifier for this team.

5.3.8.3. name¶

The display name for this team. A name is required when a team is created.

5.3.8.4. course_id¶

The course identifier, in the format {key type}:{org}+{course}+{run}. For example, course-v1:edX+DemoX+Demo_2014.

History: In October 2014, identifiers for some new courses began to use the format shown above. Other new courses, and all courses created prior to October 2014, use the format {org}/{course}/{run}, for example, MITx/6.002x/2012_Fall.

5.3.8.5. topic_id¶

The unique identifier for the teams topic associated with the team. Topics, including an ID for each topic, are defined by course team members in Advanced Settings in Studio.

5.3.8.6. date_created¶

The date and time that this team was created, in the format YYYY-MM-DD HH:MM:SS.

5.3.8.7. description¶

The description for the team. A team description is required when a team is created.

5.3.8.8. country¶

An optional field in a team’s details. The person who creates a team can specify a country that the team’s members primarily identify with. Country codes are ISO 3166-1 codes.

5.3.8.9. language¶

An optional field in a team’s details. A team can specify a language that the team’s members primarily communicate using. Most language codes are ISO 639-1 codes, with the addition of codes for simplified and traditional Chinese.

5.3.8.10. discussion_topic_id¶

The identifier for all discussion topics within this team’s discussions.

5.3.8.11. last_activity_at¶

The date and time that the most recent activity on the team was recorded, in the format YYYY-MM-DD HH:MM:SS. The current definition of activity for this field includes team creation, and the creation of posts, comments, and responses in the team’s discussions.

5.3.8.12. team_size¶

The current count of the number of members in the team.

5.3.9.1. id¶

The primary key, a database auto-increment field that uniquely identifies the membership of a user on a team.

5.3.9.2. user_id¶

The ID of a user who is currently a member of the team, from auth_user.id.

5.3.9.3. team_id¶

The ID of the team, from teams_courseteam.id.

5.3.9.4. date_joined¶

The timestamp of the time that the user joined the team, in the format YYYY-MM-DD HH:MM:SS.

5.3.9.5. last_activity_at¶

The date/time of the most recent activity performed by this user on this team, in the format YYYY-MM-DD HH:MM:SS. The current definition of activity for this field is limited to discussions-related actions by this user: adding or deleting posts, adding comments or responses, and voting on posts. If the user has not yet participated in the team’s discussion, the last_activity_at date/time reflects the timestamp when the user joined the team.

5.3.10.1. timestamp¶

The date and time at which the user’s verification status changed, in UTC.

5.3.10.2. status¶

This column can have one of the following values.

• submitted: The user has submitted photos for re-verification.
• approved: The verification service successfully verified the user’s identity.
• denied: The verification service determined that the user’s re- verification photo does not match the photo on the ID that the user submitted at the start of the course.
• error: An error occurred during the verification process.

5.3.10.3. course_id¶

The ID of the course run that the user is re-verifying for.

5.3.10.4. checkpoint_location¶

The point in the course at which the user was prompted to re-verify his or her identity. As of August 2015, course authors can define these checkpoints when they create the course. Because these checkpoints typically occur before exams, examples of expected values are final and midterm.

5.3.10.5. user_id¶

Student’s ID in auth_user.id. Identifies the student who is re-verifying his or her identity.

5.4.2.1. id¶

Primary key. Rarely used though, since most lookups on this table are searches on the three tuple of (course_id, student_id, module_id).

5.4.2.2. module_type¶

Type	Description
chapter	The top level categories for a course. Each of these is usually labeled as a Week in the courseware, but this is just convention.
combinedopenended	A module type developed for grading open ended questions via self assessment, peer assessment, and machine learning.
conditional	Allows you to prevent access to certain parts of the courseware if other parts have not been completed first.
course	The top level course module of which all course content is descended.
crowdsource_hinter	Not used. History: This module_type was included in a single course on a test basis. It has not been used since July 2013, and was removed on 16 March 2016.
lti	Learning Tools Interoperability component that adds an external learning application to display content, or to display content and also require a student response.
peergrading	Indicates a problem that is graded by other students. An option for grading open ended questions.
poll_question	Not currently used. History: This module_type was included in a single course on a test basis and then deprecated.
problem	A problem that the user can submit solutions for. EdX offers many different varieties.
problemset	A collection of problems and supplementary materials, typically used for homeworks and rendered as a horizontal icon bar in the courseware. Use is inconsistent, and some courses use a sequential instead.
randomize	Identifies a module in which one of several possible defined alternatives is randomly selected for display to each student.
selfassessment	Self assessment problems. Used in a single course in Fall 2012 as an early test of the open ended grading system. Deprecated in favor of combinedopenended.
sequential	A collection of videos, problems, and other materials, rendered as a horizontal icon bar in the courseware.
timelimit	Not currently used. History: This module_type was included in a single course on a test basis and then deprecated.
video	A component that makes a video file available for students to play.
videoalpha	Not currently used. History: During the implementation of a change to the video module_type, both video and videoalpha were stored. The videoalpha type was then deprecated.
videosequence	A collection of videos, exercise problems, and other materials, rendered as a horizontal icon bar in the courseware. History: This module_type is no longer in use, courses now use sequential instead.
word_cloud	A specialized problem that produces a graphic from the words that students enter.

5.4.2.3. module_id¶

Unique ID for a distinct piece of content in a course. Each module_id is recorded as a URL with the format {key type}:{org}+{course}+{run}@{module type}+block@{module name or hash code}. Having URLs of this form gives content a canonical representation even during a transition between back-end data stores.

As an example, this example module_id contains the following parts.

block-v1:edX+DemoX+Demo_2014+type@problem+block@303034da25524878a2e66fb57c91cf85

Part	Example Value	Definition
{key type}	block-v1	The type of namespace identifier, including the implementation version.
{org}	edX	The organization part of the ID, indicating what organization created this piece of content.
{course}	DemoX	The course that this content was created for.
{run}	Demo_2014	The term or specific iteration of the course.
type@{module type}	type@problem	The module type. The same value is stored in the courseware_studentmodule.module_type column.
block@{module name or hash code}	block@303034da25524878a2e66fb57c91cf85	The name that the content creators supplied for this module. If the module does not have a name, the system generates a hash code as its identifier.

History: In October 2014, identifiers for modules in some new courses began to use the format shown above. Other new courses, and all courses created prior to October 2014, use the format i4x://{org}/{course}/{module type}/{module name or hash code}. For example, i4x://MITx/3.091x/problemset/Sample_Problems. Note that this format does not include course run information, so the courseware_studentmodule.course_id column might need to be used as well.

5.4.2.4. student_id¶

A reference to auth_user.id, this is the student that this module state row belongs to.

5.4.2.5. state¶

This is a JSON text field where different module types are free to store their state however they wish.

course, chapter, problemset, sequential, videosequence

The state for all of these container modules is a JSON object indicating the user’s last known position within this container. This is 1-indexed, not 0-indexed, mostly because it was released that way and a later change would have broken saved navigation state for users.

Example: {"position" : 3}

When this user last interacted with this course/chapter/etc., she clicked on the third child element. Note that the position is a simple index and not a module_id, so if you rearranged the order of the contents, it would not be smart enough to accommodate the changes and would point users to the wrong place.

The hierarchy of these containers is course > chapter > (problemset | sequential | videosequence).

combinedopenended

The JSON document includes attributes that identify the student’s answer, a rubric_xml that includes the complete XML syntax for the rubric, the score earned and the max_score, and the grader_id (the auth_user.id) of each student who assessed the answer.

5.4.2.6. grade¶

Floating point value indicating the total unweighted grade for this problem that the student has scored. Basically how many responses they got right within the problem.

Only problem and selfassessment types use this column. All other modules set this to NULL. Due to a quirk in how rendering is done, grade can also be NULL for a tenth of a second or so the first time that a user loads a problem. The initial load triggers two writes, the first of which sets the grade to NULL, and the second of which sets it to 0.

5.4.2.7. created¶

Datetime when this row was created, which is typically when the student first accesses this piece of content.

Note

For a module that contains multiple child modules, a row is created for each of them when the student first accesses one of them.

5.4.2.8. modified¶

Datetime when this row was last updated. Set to be equal to created at first. A change in modified implies that there was a state change, usually in response to a user action like saving or submitting a problem, or clicking on a navigational element that records its state. However it can also be triggered if the module writes multiple times on its first load, like problems do (see note in grade).

5.4.2.9. max_grade¶

Floating point value indicating the total possible unweighted grade for this problem, or basically the number of responses that are in this problem. Though in practice it’s the same for every entry with the same module_id, it is technically possible for it to be anything.

Another way in which max_grade can differ between entries with the same module_id is if the problem was modified after the max_grade was written and the user never went back to the problem after it was updated. This might happen if a member of the course team puts out a problem with five parts, realizes that the last part doesn’t make sense, and decides to remove it. People who saw and answered it when it had five parts and never came back to it after the changes had been made will have a max_grade of 5, while people who saw it later will have a max_grade of 4.

Only graded module types use this column, with problem being the primary example. All other modules set this to NULL.

5.4.2.10. done¶

Not used. The value na appears in every row.

5.4.2.11. course_id¶

The course that this row applies to, in the format {key type}:{org}+{course}+{run}. For example, course-v1:edX+DemoX+Demo_2014.

Because the same course content (content with the same module_id) can be used in different courses, student state is tracked separately for each course.

History: In October 2014, identifiers for some new courses began to use the format shown above. Other new courses, and all courses created prior to October 2014, use the format {org}/{course}/{run}, for example, MITx/6.002x/2012_Fall.

5.5.1.1. id¶

The primary key.

5.5.1.2. user_id, course_id¶

The table is indexed by user and course.

5.5.1.3. download_url¶

The download_url contains the full URL to the certificate.

5.5.1.4. grade¶

The grade computed the last time certificate generation ran. If the courseware, student state, or grading policy change, the value in this column can be different than the grade shown on a student’s Progress page.

5.5.1.5. key¶

Used internally only. A random string that is used to match server requests to responses sent to the LMS.

5.5.1.6. distinction¶

Not used.

History: This was used for letters of distinction for 188.1x, but is not being used for any current courses.

5.5.1.7. status¶

After a course has been graded and certificates have been issued, the status is one of these string values.

• downloadable
• audit_passing
• notpassing
• audit_notpassing

The table that follows describes these values and the other workflow states that can apply during certificate generation process.

Value	Description
audit_notpassing	Applies to learners who did not earn a passing grade and who have a value of “audit” in student_courseenrollment.mode. No certificate is generated for these learners. History: Added 26 Jan 2016 for audit enrollments created after 1 Dec 2015.
audit_passing	Applies to learners who earned a passing grade and who have a value of “audit” in student_courseenrollment.mode. These learners completed the course succesfully, but no certificate is generated for these learners. History: Added 26 Jan 2016 for audit enrollments created after 1 Dec 2015.
deleted	The certificate has been deleted.
deleting	A request has been made to delete a certificate.
downloadable	A certificate is available for download. Applies to learners who earned a passing grade and who have a certificate-bearing value in student_courseenrollment.mode.
error	An error ocurred during certificate generation.
generating	A request has been made to generate a certificate but it has not yet been generated.
notpassing	The learner did not earn a passing grade. Applies to learners who have a certificate-bearing value in student_courseenrollment.mode. No certificate is generated for these learners.
regenerating	A request has been made to regenerate a certificate but it has not yet been generated.
restricted	No longer used. History: Specified when userprofile.allow_certificate was set to false to indicate that the learner was on the restricted embargo list.
unavailable	No entry, typically because the student has not yet been graded for certificate generation.

5.5.1.8. verify_uuid¶

A hash code that verifies the validity of a certificate. Included on the certificate itself as part of a URL.

5.5.1.9. download_uuid¶

A hash code that identifies this student’s certificate. Included as part of the download_url.

5.5.1.10. name¶

This column records the name of the student that was set at the time the student was graded and the certificate was generated.

5.5.1.11. created_date¶

Date this row in the database was created.

5.5.1.12. modified_date¶

Date this row in the database was modified.

5.5.1.13. error_reason¶

Used internally only. Logs messages that are used for debugging if the certificate generation process fails.

5.5.1.14. mode¶

Contains the value found in the student_courseenrollment.mode field for a student and course at the time the certificate was generated: audit, honor, verified, or blank. This value is not updated if the value of the student’s student_courseenrollment.mode changes after certificates are generated.