SchoolTool Integration

The SchoolTool SIS project recently released version 1.0, and lots of people could benefit from a solid integration between Moodle and SchoolTool. This page is a work-in-progress specification for the first version of this integration.

Goal: Moodle-SchoolTool integration modeled on Moodle-Mahara integration.

• SchoolTool-Mahara integration should require very little extra effort when this project is complete.
• SchoolTool+Moodle+Mahara will provide a complete, integrated school administration/learning/portfolio suite that will be easily installable and supportable by time-crunched education systems administrators.

Requirements

• SSO between SchoolTool and Moodle
• Auto-enrolment in Moodle tracking enrolments in SchoolTool
• Automatic grade transfer from Moodle to SchoolTool
• Completely web-based integration configuration (similar to Moodle-Mahara configuration)

Supported versions

• SchoolTool 1.0
• Moodle 1.9.5+

Background info and references

• Moodle 1.9+ gradebook
• Moodle external DB enrolment plugin

Implementation notes/ideas

• The PHP mnet library will be ported to python.
  • SchoolTool will need to use this library. Discussion about plugin architectures (auth, enrolment, grades) underway in #schooltool on freenode...
• Moodle will need some awareness of SchoolTool in the mnet auth plugin. Not sure yet what this entails. (i.e., Mahara shows up in the list. We need SchoolTool in there, too.)
• Moodle will need an enrolment plugin that gets data from mnet but is otherwise modeled on the external DB enrolment plugin.
• Moodle will need a gradebook plugin (does this even exist? or something...) that can pass grades to SchoolTool via mnet.

Schedule

• mnet library porting ASAP (Brett)
• mnet interface and data content examples drawn from Moodle as input to SchoolTool design ASAP (Matt)
• SchoolTool-side planning/spec meeting TBA

Data Samples

Auth/Profile

• idnumber,lastname,firstname,username,email,<other profile fields TBD>

Enrolment

• userid, courseid, role?, course name?, status?, credits?, other?

Grade

• userid, courseid, item name, points earned, points possible?, other?

Planning meeting prep/notes (to be integrated above after meeting)

• When: Friday, June 5 at 10am EST
• Where: #schooltool-moodle on freenode

• Write down some use cases about ST+Moodle integration
  • Drop SchoolTool into existing Moodle site, leave Moodle as authoritative user directory, enrollment management system.
    • This is what ECHS wants.
    • If Moodle drives auth, then no accounts manually created in SchoolTool can become integrated with Moodle.
    • If Moodle drives enrollment, then all course creation and enrollment updates must happen first in Moodle and be transferred from there to SchoolTool.
    • ECHS wants student-driven enrollment.
    • An interactive enrollment in Moodle kicks off an immediate transaction to record the enrollment in schooltool.
  • Drop SchoolTool into existing Moodle site, after bulk data transfer from Moodle->SchoolTool, flip configuration and use SchoolTool as the authoritative user directory and/or enrollment management system.
    • Could this be used to migrate to SchoolTool from another SIS (integrated somehow with Moodle) by way of Moodle?
  • Start fresh with both.
  • Drop Moodle into SchoolTool site.
    • maybe not important for v1.0, might basically come for free
  • Drop SchoolTool into Mahara site (and vice-versa, out of scope at present)

• Design decision: Grades will only go from Moodle to SchoolTool.
• Design decision: For auth/enrollment/grades, only one side is ever authoritative. We are not going to synchronize both ways simultaneously.
• Design decision: Regardless of which system is driving auth/enrollment, SchoolTool must be the authoritative reporting system.

• What user data will go between SchoolTool & Moodle?
  • Moodle & SchoolTool will share an idnumber(UUID) for each object they share.
  • Which user profile fields do SchoolTool & Moodle have in common?
  • SchoolTool only cares about enough to create a login account.
  • SchoolTool does not care about student-editable profile fields.
  • Perhaps leave it up to Moodle admin whether to leave profile fields that can come from SchoolTool editable or locked.
  • Each system must be able to send enough data to the other for a login account to be created.
  • The integration will have a mechanism to prevent student logins even when their accounts exist (and SSO is configured). (This will be some sort of flag, that applies to groups so nobody needs to set it for each user. Ugh.)

• What enrollment data will go between SchoolTool & Moodle?
  • What are SchoolTool's course status concepts, and how will these interact with Moodle? (e.g., is enrollment simply binary, or are there other status options?) -- Status will be added soon (see SchoolTool TODO list). Enrollment in SchoolTool consists of a group of students and a group of teachers associated with a course section. Moodle will simply treat all of these teachers as editing teachers and all of these students as students (as opposed to other roles).
• What grade data will go between Moodle & ST?
  • One grade/student/course, or one grade/assessment/student/course? (Eventually want to provide admin(?) with option.)
• Identify MNET interfaces published by Moodle & ST for this integration.
• Produce mock-ups of the SSO, enrollment, & grading data. (XML)
• Where will the python mnet library live?
• Can we allow the admin to choose whether auth directory goes from SchoolTool to Moodle or vice-versa?
  • Definitely want bulk update via cron available for the chosen transfer direction.
  • Optionally allow on-demand update per user if used before bulk update via cron. (Moodle works this way now.)
• Can we allow the admin to choose whether enrollment authority is in SchoolTool or Moodle?
  • Definitely want bulk update via cron available for the chosen transfer direction.
  • Optionally allow on-demand update per user if used before bulk update via cron. (Moodle works this way now.)
• What will the code between SchoolTool and the python MNET library look like? (This is probably where zope-related considerations come into play.)
  • What, in summary, does MNET provide?
    • MNET is an XMLRPC implementation that dispatches messages to applications on either side (with a convention for function naming).
    • MNET has a security layer that enforces that every message is encrypted and signed (with regular key rotation).
    • MNET provides a core set of modules to provide common functionality such as SSO, key discovery, ping, and course enrollment.

• SchoolTool TODO list
  • Add enumerated status field to enrollment (e.g., Active, Withdrawn No Grade, Withdrawn Failing, Passed) This will not initially include a workflow, but simply a current state and a history of states.