Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

mnet phase2

From MoodleDocs
Revision as of 04:35, 23 December 2008 by Peter Bulmer (talk | contribs)

Jargon

  • IDP (Identity Provider): An application (Moodle) fulfiling the functionality of tying a user to a profile.
  • IDP-A IDP Administrator
  • CP (Content provider): An application (Moodle) fulfiling the functionality of course material host.
  • CP-A CP Administrator

Role Assignments

In existing mnet (Moodle < v2.0) IDP-A selected a course published by a CP, then they identified local users that they wanted to be enrolled in that course. The CP would then assign a role to the selected users in the context of the course specified. The role assigned was "default role for users in a course" (usually student).

Problems

The current setup has a number of problems:

  • No support for allocating more than one role
  • No support for any form of automated enrolment/role assignment
  • Dedicated tables for storing information about mnet courses, and enrolments
  • No allowance made to align grades output by the CP with the enrolment of the student in the course.

Proposal

Proposal I'd like to put to a client addresses all these points in the following ways:

  • Allow CP-A to specify that they trust the IDP-A to allocate more than just the student role. This information would be set per mnet peer, and should probably default to allowing students, denying everything else (the setting which matches most pre-existing configurations). This information would be stored in a new table mdl_mnet_authorised_roles, CP-A would tick all roles they trust the IDP-A to allocate.
  • Allow IDP-A to map their system roles to permitted CP roles on a per-mnet-peer basis. Most commonly the IDP-A would map 'teacher' to 'CP_teacher', 'student' to 'CP_student' and 'non-editing teacher' to 'CP_non-editing teacher' (the 'CP_' recognising that the roles are not necessarily exactly the same). This information would be stored in a new table mdl_mnet_role_mapping
  • Allow all pre-existing enrolment mechanisms to enrol users in remote courses.
    • Remove the use of tables dedicated to tracking remote courses, and remote course enrollments,
    • Store remote course information in mdl_course (like local courses) with an additional field ('mnetlinkid' or similar)
    • New table mdl_mnet_course_link: IDP-A would specify which remote course they want a local course to link to, in effect converting the local course to a shell for the remote course. All enrolment plugins would continue to assign/unassign roles roles to the course context, with the hook being that they would spawn a request to the remote moodle, adding the user to the remote course. Users attempting to view the shell would be told where to jump (on the remote peer)
    • Add additional capability 'can see shell course' - allocated by default to at least the administrator role, allowing them to see the contents of the local course without being redirected to jump.php to see the real thing (this allows them to manually add/remove students from the course (among other things))

Storing information about the remote course in the same place as local courses has the additional benefit that grading information for a student which is returned from the CP can be linked against the appropriate course enrolment for that student.