mnet phase2: Difference between revisions
From MoodleDocs
Peter Bulmer (talk | contribs) mNo edit summary |
Peter Bulmer (talk | contribs) mNo edit summary |
||
| Line 1: | Line 1: | ||
=== Jargon === | === Jargon === | ||
* IDP (Identity Provider): An application (Moodle) fulfiling the functionality of tying a user to a profile. | * 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 (Content provider): An application (Moodle) fulfiling the functionality of course material host. | ||
* | * CP-A CP Administrator | ||
== Role Assignments == | == Role Assignments == | ||
In existing mnet (Moodle < v2.0) | 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 === | === Problems === | ||
| Line 18: | Line 18: | ||
Proposal I'd like to put to a client addresses all these points in the following ways: | Proposal I'd like to put to a client addresses all these points in the following ways: | ||
* '''Allow | * '''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_authorisied_roles, CP-A would tick all roles they trust the IDP-A to allocate. | ||
* Allow | * 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, 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. | * '''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. IDP-A 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. | * 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. | ||
Revision as of 03:57, 23 December 2008
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_authorisied_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, 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. IDP-A 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.
