Note: You are currently viewing documentation for Moodle 3.11. Up-to-date documentation for the latest stable version of Moodle may be available here: mnet phase2.

Development:mnet phase2: Difference between revisions

From MoodleDocs
mNo edit summary
mNo edit summary
 
(3 intermediate revisions by the same user not shown)
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.
* IDPA IDP Administrator
* 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.
* CPA CP Administrator
* CP-A CP Administrator


== Role Assignments ==
== 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'').
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 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 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 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 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.  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.
* '''Allow all pre-existing enrolment mechanisms to enrol users in remote courses.'''  
* 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.
** 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.

Latest revision as of 04:35, 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_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.

Retrieved from "https://docs.moodle.org/311/en/index.php?title=Development:mnet_phase2&oldid=48442"
Powered by MediaWiki