Moodle
  1. Moodle
  2. MDL-20660

Pass student ID over MNET from Moodle

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Trivial Trivial
    • Resolution: Unresolved
    • Affects Version/s: 1.9.6
    • Fix Version/s: None
    • Component/s: MNet
    • Labels:
      None
    • Affected Branches:
      MOODLE_19_STABLE
    • Rank:
      7084

      Description

      As per https://eduforge.org/tracker/?func=detail&atid=739&aid=3388&group_id=176 (Mahara bug 3388 - Student ID is not passed from Moodle (via XMLRPC))

      When roaming from Moodle 1.9.5+ (20090804) to Mahara 1.1.7testing (2009022620) (via XMLRPC) the student ID is not passed through.

      Penny commented:

      I think maybe the reason this isn't passed from Moodle, is that
      this is a potentially conflictey field.

      Local users may well have their own naming scheme that is the
      way that institution handles idnumbers and they might not want
      remote users coming in with this field, where their idnumbers
      may conflict with the local naming scheme.

      And also:

      Maybe we should file a bug about it on the Moodle tracker and
      discuss there having options to send it or not.

      So here is the bug . I'm afraid I don't know much about the student ID field, so I leave it to you Moodlers to decide whether it can be passed

        Issue Links

          Activity

          Hide
          Penny Leach added a comment -

          FWIW, I think the correct solution is to add a list of fields that are sent/received by both the IDP and the SP, and then use the intersection.

          Show
          Penny Leach added a comment - FWIW, I think the correct solution is to add a list of fields that are sent/received by both the IDP and the SP, and then use the intersection.
          Hide
          Penny Leach added a comment -

          Here's how I think this should work:

          • New setting (multi-select): profile fields to send
          • New setting (multi-select): profile fields to receive

          In the config screens, a notice that the intersection of these two will be used.

          This could either be:

          1. Global (in networking settings)
          2. Per networked host

          I don't think it belongs to either auth/mnet or enrol/mnet, because both of them create users on remote hosts.

          I'm leaning towards making this a global setting, even if it's less flexible, purely because otherwise it's a real pain to set up for sites with multiple hosts

          The question remains: what to do about custom profile fields? I think this should be an extra setting in the "profile fields to receive" page with the following options:

          • import custom fields and map them by name, discarding any non-matches
          • import custom fields and map them by name, creating any non-matches (harder?)
          • ignore custom profile fields

          The 'sending' page can just add them into the multi-select with a "Custom: " prefix.

          Or we could just refuse to send/receive custom profile fields.

          So: questions -

          1. Where do we think the new setting pages should go? Global or per host?
          2. What do we think about custom profile fields?
          3. What fields should the upgrade to 2.0 add as the default?

          Show
          Penny Leach added a comment - Here's how I think this should work: New setting (multi-select): profile fields to send New setting (multi-select): profile fields to receive In the config screens, a notice that the intersection of these two will be used. This could either be: 1. Global (in networking settings) 2. Per networked host I don't think it belongs to either auth/mnet or enrol/mnet, because both of them create users on remote hosts. I'm leaning towards making this a global setting, even if it's less flexible, purely because otherwise it's a real pain to set up for sites with multiple hosts The question remains: what to do about custom profile fields? I think this should be an extra setting in the "profile fields to receive" page with the following options: import custom fields and map them by name, discarding any non-matches import custom fields and map them by name, creating any non-matches (harder?) ignore custom profile fields The 'sending' page can just add them into the multi-select with a "Custom: " prefix. Or we could just refuse to send/receive custom profile fields. So: questions - 1. Where do we think the new setting pages should go? Global or per host? 2. What do we think about custom profile fields? 3. What fields should the upgrade to 2.0 add as the default?
          Hide
          Penny Leach added a comment -

          watcher ping - ideas please!

          Show
          Penny Leach added a comment - watcher ping - ideas please!
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Hi,

          1) About the global / per host lists of fields, which is the rationale (or use case) to have it per host? Does have sense something like some hosts being more "friendly" or "safer" in order to populate them with, say, institution, while we want to keep that info not pushed to other hosts? If the answer is yes (i.e. if there are reason to have different "field profiles" - uhm!! - then per host).

          2) About the lists themselves, I think it's ok to have two. One for user fields and another for custom fields. In any case, I'd never be creating new custom fields automatically. Just the matching intersection strategy always (note that, perhaps, you'll need to match name + type in custom fields, at least it sounds to me I had some problems with that on restore).

          3) User tags? Any other user information?

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Hi, 1) About the global / per host lists of fields, which is the rationale (or use case) to have it per host? Does have sense something like some hosts being more "friendly" or "safer" in order to populate them with, say, institution, while we want to keep that info not pushed to other hosts? If the answer is yes (i.e. if there are reason to have different "field profiles" - uhm!! - then per host). 2) About the lists themselves, I think it's ok to have two. One for user fields and another for custom fields. In any case, I'd never be creating new custom fields automatically. Just the matching intersection strategy always (note that, perhaps, you'll need to match name + type in custom fields, at least it sounds to me I had some problems with that on restore). 3) User tags? Any other user information? Ciao
          Hide
          Penny Leach added a comment -

          Thanks Eloy for commenting

          1. Yeah, different friendliness or safeness for different hosts. I think it would potentially be a pain to fill out multiple times though. The most flexible is probably to have a global list, but then have a setting PER HOST to override it from what the global settings are.

          2. Yes, I'm sure you're right about the custom profile fields. I wonder actually, if in reality there's any point actually sending them. What do we think of the use-case - can we imagine a case where we'd either want to automatically create custom fields, OR have two sites with the same custom field definitions?

          3. Argh, I hadn't thought of that

          Show
          Penny Leach added a comment - Thanks Eloy for commenting 1. Yeah, different friendliness or safeness for different hosts. I think it would potentially be a pain to fill out multiple times though. The most flexible is probably to have a global list, but then have a setting PER HOST to override it from what the global settings are. 2. Yes, I'm sure you're right about the custom profile fields. I wonder actually, if in reality there's any point actually sending them. What do we think of the use-case - can we imagine a case where we'd either want to automatically create custom fields, OR have two sites with the same custom field definitions? 3. Argh, I hadn't thought of that
          Hide
          Dan Marsden added a comment - - edited

          sorry for the late comment... just got back from leave.

          what happens if the field name is different in each host?
          eg a NZ based host with "Country" as the customfield name
          and a German based host with "land" as the customfield name
          (or a Moodle and Mahara host with differing names for the same thing)

          it would be nice if we could obtain via mnet - a list of the available fields and allow them to be mapped to an existing field?

          edit - which would require seperate config per host - with sensible default settings.

          Show
          Dan Marsden added a comment - - edited sorry for the late comment... just got back from leave. what happens if the field name is different in each host? eg a NZ based host with "Country" as the customfield name and a German based host with "land" as the customfield name (or a Moodle and Mahara host with differing names for the same thing) it would be nice if we could obtain via mnet - a list of the available fields and allow them to be mapped to an existing field? edit - which would require seperate config per host - with sensible default settings.
          Hide
          Penny Leach added a comment -

          For the meantime, I'm not doing custom fields. I agree that would need to happen.

          Show
          Penny Leach added a comment - For the meantime, I'm not doing custom fields. I agree that would need to happen.
          Hide
          Penny Leach added a comment -

          Can someone do some testing on this for me? I put it in HEAD today.

          Show
          Penny Leach added a comment - Can someone do some testing on this for me? I put it in HEAD today.
          Hide
          Andrew Nicols added a comment -

          I think that this issue can probably be closed now as it hit master 3 years ago.
          I've just had a quick play with this and it seems to be working as expected. We're not about to revert it now at any rate, and any issues will come through as new issues now.

          Show
          Andrew Nicols added a comment - I think that this issue can probably be closed now as it hit master 3 years ago. I've just had a quick play with this and it seems to be working as expected. We're not about to revert it now at any rate, and any issues will come through as new issues now.

            People

            • Votes:
              3 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated: