Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-16021

mnet users unable to view their own grades.

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.8, 1.8.1, 1.8.2, 1.8.3, 1.8.4, 1.8.5, 1.8.6, 1.9, 1.9.1, 1.9.2
    • Fix Version/s: 1.8.7, 1.9.3, 2.0
    • Component/s: General
    • Labels:
      None
    • Affected Branches:
      MOODLE_18_STABLE, MOODLE_19_STABLE
    • Fixed Branches:
      MOODLE_18_STABLE, MOODLE_19_STABLE, MOODLE_20_STABLE

      Description

      Initially reported to me as "mnet users cannot view grades in remote courses".

      To replicate: Set up 2 moodles, called "Local" (can be any version), and "Remote" (must be 1.9.x)
      Create user "Student" on Local, and give them all necessary rights on moodles Local & Remote so that they can sso from Local to Remote.
      Create a course called "Course" on Remote, and enrol Student in it.
      Log in as Student on Local, and roam to Remote. View Course, and click "View Grades" in the course admin block.
      Observe that the error "Incorrect Userid" is displayed.

      The expected behaviour is that a page is displayed showing Student's grades for activities in Course.

      URL in bar at time of error is <wwwroot>/grade/report/user/index.php?id=<courseid>

        Gliffy Diagrams

        1. MOODLE_19_STABLE.diff
          1 kB
          Peter Bulmer
        1. 000-gradebook-error.jpg
          79 kB
        2. 001-gradebook-working.png
          244 kB

          Activity

          Hide
          peterbulmer Peter Bulmer added a comment -

          Attached is 2 screencaps, 1 where the functionality is not working (mnet user), the other where it is working (local user).

          I believe I have traced the problem to an overly restrictive function in lib/moodlelib.php: get_complete_user_data(...)

          This function takes two mandatory arguments 'field' and 'value', it then forms some sql to select a user whose $field column has the value $value.

          I believe the intent of this function was to provider a convenient way for programmers to load all user data based on any unique user information. With the advent of mnet, some information that was previously unique to a user no-longer was, (eg 1 local user named 'bob', and 7 mnetted users from 7 different peers each with the name 'bob'). To account for this, the function was changed to take another parameter 'mnethostid', and restrict the search for users to those from a particular mnet host. Where no mnethostid is specified, the function restricts the search to the local host.

          The patch I am about to attach, amends the function to not apply the default mnethost restriction where the original assumption about field uniqueness is known to still hold true. If the programmer is getting complete user data, and is supplying the id number of the user wanted, we don't need to force any mnethost restriction.

          Show
          peterbulmer Peter Bulmer added a comment - Attached is 2 screencaps, 1 where the functionality is not working (mnet user), the other where it is working (local user). I believe I have traced the problem to an overly restrictive function in lib/moodlelib.php: get_complete_user_data(...) This function takes two mandatory arguments 'field' and 'value', it then forms some sql to select a user whose $field column has the value $value. I believe the intent of this function was to provider a convenient way for programmers to load all user data based on any unique user information. With the advent of mnet, some information that was previously unique to a user no-longer was, (eg 1 local user named 'bob', and 7 mnetted users from 7 different peers each with the name 'bob'). To account for this, the function was changed to take another parameter 'mnethostid', and restrict the search for users to those from a particular mnet host. Where no mnethostid is specified, the function restricts the search to the local host. The patch I am about to attach, amends the function to not apply the default mnethost restriction where the original assumption about field uniqueness is known to still hold true. If the programmer is getting complete user data, and is supplying the id number of the user wanted, we don't need to force any mnethost restriction.
          Hide
          peterbulmer Peter Bulmer added a comment -

          proposed patch for MOODLE_19_STABLE

          will be slightly different for cvshead.

          Show
          peterbulmer Peter Bulmer added a comment - proposed patch for MOODLE_19_STABLE will be slightly different for cvshead.
          Hide
          skodak Petr Skoda added a comment -

          +1 for commit

          Show
          skodak Petr Skoda added a comment - +1 for commit
          Hide
          peterbulmer Peter Bulmer added a comment -

          Fix committed

          Show
          peterbulmer Peter Bulmer added a comment - Fix committed
          Hide
          jerome Jérôme Mouneyrac added a comment -

          tested on 1.9, it works. I'll test on 1.8 soon.

          Show
          jerome Jérôme Mouneyrac added a comment - tested on 1.9, it works. I'll test on 1.8 soon.
          Hide
          jerome Jérôme Mouneyrac added a comment -

          tested on 1.8. It works as well.
          Thanks Peter and Petr.

          Show
          jerome Jérôme Mouneyrac added a comment - tested on 1.8. It works as well. Thanks Peter and Petr.

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Fix Release Date:
                15/Oct/08