Development:mnet phase2

Jargon

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

Role Assignments

In existing mnet (Moodle < v2.0) IDPA 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 CPA to specify that they trust the IPA 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_authorisied_roles, CPA would tick all roles they trust the IDPA to allocate.
• Allow IPA to map their system roles to permitted CP roles on a per-mnet-peer basis. Most commonly the IDPA 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, instead storing the same information with local course information, (mdl_course) with an additional field ('mnetlinkid' or similar) which identifies that users trying to view the course should be directed to jump to the address described in the mdl_mnet_link table. IPA would specify which remote course they want this local course to link to, in effect converting the local course to a shell for the remote course. All enrolment plugins would continue to manipulate the user assignment in the 'local' course, with the hook being that they would spawn a request to the remote moodle adding the user to the remote course. Finally, using mdl_course for remote and local courses alike would provide a good location for grades to be stored when/if they are shipped back from the CP as part of (other) future mnet functionality.
• An 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.