![\"\"](\"http:\/\/blogs.sussex.ac.uk\/elearningteam\/files\/2011\/02\/course_data_in_to_syd.jpg\" "\\"course")
<\/a><\/p>\nSussex course data is passed to Moodle and a site is automatically created for that site. \u00a0Before 2008 this was at the request of the tutor, however since 2008 a policy decision was made and all courses now have a Moodle site.<\/p>\n
The data we pass includes course name, study level, academic year, department, learning objectives and the start date. These become non-editable fields in the Moodle site settings. \u00a0We decided early on to that a Moodle site should exist for the duration of a student’s study. For more information about this decision see blogs post on “maintaining sites for the students programme duration”<\/a>. As a result the identifier passed to Moodle was the course code appended with the term and academic year.<\/p>\n Before 2008 Moodle sites were made available to the students through an interface in the MLE (Sussex Direct). This was so the central DB was updated with the Moodle course site state and links were established\u00a0from other systems. Now this\u00a0process\u00a0is\u00a0reversed\u00a0and we make Moodle sites available to students in Moodle and concurrently update the central DB.<\/p>\n We currently do not pass the timetable or assessment data although we may do in future projects.<\/p>\n Sussex staff, students and associates who have a computer service account can log in to our Moodle installation through the LDAP authentication service, however this service passes limited user data to Moodle. \u00a0We therefore decided to pass all user data through our nightly sync. Data such as their name, username, person code, and email updates the user table. \u00a0Within the edit profile screen these fields become non-editable. \u00a0However, we have also created a local Sussex roles table into which we pass a person roles and the departments and schools for which they serve this role. For the student role we pass study levels, programmes, programme years and candidate number. The user searches have been\u00a0customized\u00a0to use the local Sussex roles table. It is also very useful when extracting data for Moodle use analysis.<\/p>\n A development for the Spring term will be to pass card photos to Moodle. \u00a0We will still allow staff and students to add a Moodle picture, but where one does not exist and they have allowed use of their card photo we will pass it. We will run a script every month to look for new Sussex account card photos. For more information see blog post on importing user profiles into Moodle<\/a>.<\/p>\n We currently do not pass user assessment data back to the central server, but we may do in the future. Furthermore we would like to link closer with user assessment records held on the central server.<\/p>\n The nightly sync manages course site roles and enrolments. \u00a0We decided not to use IMS-Enrolment standards to manage unenrolment, which specified that an unenrolled user would be of a specified status. It was easier to use a “snapshot unenrol” method which looked at all current members of site and compare that with the incoming membership.<\/p>\n Within the membership possibilities we have added a Colleague role to Moodle. This role permits read only access to a user. \u00a0Some departments have selected to give all faculty members a Colleague role on each others’ Moodle sites.<\/p>\n A development for the Spring term is to make it possible to sync a course’s teaching groups with a Moodle site. This will be a manual process. \u00a0For more information, see the Teaching groups imported into Moodle<\/a> blog post.<\/p>\nAll Sussex users have a Moodle account<\/h2>\n
<\/a><\/p>\nCourse roles are synced with Moodle course site roles<\/h2>\n
<\/a><\/p>\n