Moodle
  1. Moodle
  2. MDL-26647

Ability to consistently display idnumber, other fields in user lists

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.0.2
    • Fix Version/s: 2.2
    • Component/s: General
    • Labels:
      None
    • Testing Instructions:
      Hide

      Testing instructions (EASY, but long)

      You will need a course with some enroled members (one of whom must be a teacher) and a group; a forum, a quiz, a SCORM activity, and an assignment. The last three must all have at least one submission. You must have enabled activity completion and course completion for the course. At least one activity must have been configured with completion settings (eg manual completion).

      There must be at least one user who is not in the group, and at least one user in the system who is not enroled in the course.

      At least one of the users should have all the following profile fields set to different values: ID number, email address, phone, mobile phone, institution, and department.

      PART ONE - SETTINGS

      1. As admin user, go to Admin / Users / Permissions / User policies
      Verify that 'Show user identity' option is present and has options ID number, email address, phone, mobile phone, institution, and department.
      Verify that 'email address' option, and nothing else, is selected.

      PART TWO - PAGES

      NOTE: It will save time if you open each of these numbered pages into a new browser tab so that you can reload them later instead of having to navigate again.

      NOTE: In this section, 'As before' means that behaviour is intended to be identical to previous Moodle behaviour. 'New' indicates that there is intended to be a change as part of all these reports becoming more consistent - usually that the email field now appears and didn't before.

      2a. Open 'Assign system roles' (just an example of a user selector) and click any role.
      Verify that the names under potential/existing users show with the email address in brackets. (As before.)

      2b. In the search box, begin typing some characters from the start of a user's first or last name.
      Verify that the user comes up in search result. (As before.)

      3. Open site administration / users / accounts / browse list of users.
      Verify that the list shows users including email address. (As before.)

      4a. Open any course. Open the Groups screen (settings / course administration / users / groups). Select an existing group or create one if necessary. Click to add/remove users.
      Verify that the names under potential and group members show with the email address in brackets. (New. This user selector was previously inconsistent with all others in that it didn't show email.)

      4b. Begin typing the start of one of the email addresses.
      Verify that search result includes that user.

      5. Open any forum. Click to settings / forum administration / show/edit current subscribers (another example of user selector, needed slight code tweak to work) and click 'Turn editing on'.
      Verify that the names under potential/existing subscribers show with the email address in brackets. (As before.)

      6a. Open the Participants page (in navigation menu).
      Verify that the list of names displays and includes email address. (As before.)

      6b. Using the user list dropdown, change from 'Brief' to 'User details'.
      Verify that the list of users displays and includes email address. (As before.)

      7. Under 'Reports' in the navigation, open up 'Course completion'.
      Verify that the list of users displays and includes email address. (New.)

      8. Under 'Reports' in the navigation, open up 'Activity completion'.
      Verify that the list of users displays and includes email address. (New.)

      9. Open the gradebook (course administration / grades).
      Verify that list of users displays and includes email address. (New.)

      10. Open the quiz and click 'Results' in the Navigation menu (easy to miss). If no users are shown, choose 'All participants who have or have not attempted the quiz' option from first dropdown.
      Verify that list of users displays and includes email address. (New.)

      11. Open the SCORM activity and click 'Reports' tab.
      Verify that list of users displays and contains email address. (New.)

      12. Open the assignment and click 'View N submitted assignments' link.
      Verify that list of users displays and contains email address. (New.)

      13a. Open course administration / users / enrolled users.
      Verify that list of users contains email address.

      13b. Click 'Enrol users' button
      Verify that list of users to select from contains email address.

      PART THREE - ALL OFF

      14. Go back to the settings and turn all the checkboxes off, then save settings.

      15. Now repeat the tests in tabs 2 to 13 inclusive, above. In each case check that none of the fields are displayed, except see the following extra notes:
      note 4b - searching for email address should NOT display the user this time
      note 6 - the 'user details' mode always displays email (for those with permissions)

      PART FOUR - FULL ON

      16. Go back to the settings screen and turn all the checkboxes on, then save settings.

      17. Now repeat the tests in tabs 2 to 13 inclusive, above. In each case check that all the fields are now displayed. Use the following extra notes for some cases:

      note 2, 4, 5 - Display will probably not fit in box - this is ok, nobody should turn on all options anyhow. It looks a bit weird if any of the fields are blank (you get a comma for the blank field) but this is OK as users shouldn't turn on these options unless they are reliably set (and the comma makes it unambiguous anyhow)

      note 3 - on most Moodle themes the report will probably not fit in browser width and may get cut off rather than using scrollbars, this is a separate pre-existing bug in most moodle themes and not related to this issue (also doesn't so much apply in realistic cases where you only tick one or two boxes)

      note 4b, 13b - on this screen, try searching for the start of a different field such as idnumber or phone number. (In the 'Enrol Users' screen you have to press Return after typing in your search text, which may be confusing; MDL-30139)

      note 3, 6, 9, 10, 11, 12, 13 - on these screens, additionally try sorting by one of the new columns (click it); behaviour should be same as if you sort by an existing column.

      note 13 - this screen looks pretty stupid when you have all the options ticked, but it's not too awful; and provided you only tick one or two, they fit in nicely.

      PART FIVE - CAPABILITY

      18. On the course, go to the overrides screen (course administration / users / permissions). Next to the permission moodle/site:viewuseridentity, click the X beside Teacher so that your example teacher does not have the permission.

      19. Log in as the example teacher.

      20. Repeat the tests in tabs 4 to 12 inclusive, above. In each case check that none of the fields are displayed (as per PART THREE above).

      PART SIX - POSSIBLE GRADEBOOK SUCKAGE

      21. Log back in as admin. Go back to the settings screen and turn on the 'idnumber' and 'department' checkboxes (just so we have a more realistic situation / less horrible table) and save settings.

      22. Return to the grades screen. Reload.

      • Verify that it's working with those two fields.

      23. Turn editing on.

      • Verify it's still working - meaning that the table columns/rows remain in synch with the headers.

      24. Open site administration / grades / report settings / grader report. Flip the values of all the tickboxes so the opposite options are selected, then save settings.

      25. Return to grades screen. Reload.

      • Verify it's still working.

      26. Toggle editing. Reload.

      • Verify it's still working.

      27. Open course administration / users / permissions. Turn off gradereport/user:view for the Teacher role. Log in as your sample teacher. View the grade report. (This should have caused the little grade icon next to user's name to disappears.)

      • Verify it's still working.

      NOTE: At this point you might want to flip back the grade settings to default so they don't affect future tests. You can either do this manually or in database, DELETE FROM prefix_config WHERE name LIKE 'grade_report_%'; , then visit admin page and save settings.

      Show
      Testing instructions (EASY, but long) You will need a course with some enroled members (one of whom must be a teacher) and a group; a forum, a quiz, a SCORM activity, and an assignment. The last three must all have at least one submission. You must have enabled activity completion and course completion for the course. At least one activity must have been configured with completion settings (eg manual completion). There must be at least one user who is not in the group, and at least one user in the system who is not enroled in the course. At least one of the users should have all the following profile fields set to different values: ID number, email address, phone, mobile phone, institution, and department. PART ONE - SETTINGS 1. As admin user, go to Admin / Users / Permissions / User policies Verify that 'Show user identity' option is present and has options ID number, email address, phone, mobile phone, institution, and department. Verify that 'email address' option, and nothing else, is selected. PART TWO - PAGES NOTE: It will save time if you open each of these numbered pages into a new browser tab so that you can reload them later instead of having to navigate again. NOTE: In this section, 'As before' means that behaviour is intended to be identical to previous Moodle behaviour. 'New' indicates that there is intended to be a change as part of all these reports becoming more consistent - usually that the email field now appears and didn't before. 2a. Open 'Assign system roles' (just an example of a user selector) and click any role. Verify that the names under potential/existing users show with the email address in brackets. (As before.) 2b. In the search box, begin typing some characters from the start of a user's first or last name. Verify that the user comes up in search result. (As before.) 3. Open site administration / users / accounts / browse list of users. Verify that the list shows users including email address. (As before.) 4a. Open any course. Open the Groups screen (settings / course administration / users / groups). Select an existing group or create one if necessary. Click to add/remove users. Verify that the names under potential and group members show with the email address in brackets. (New. This user selector was previously inconsistent with all others in that it didn't show email.) 4b. Begin typing the start of one of the email addresses. Verify that search result includes that user. 5. Open any forum. Click to settings / forum administration / show/edit current subscribers (another example of user selector, needed slight code tweak to work) and click 'Turn editing on'. Verify that the names under potential/existing subscribers show with the email address in brackets. (As before.) 6a. Open the Participants page (in navigation menu). Verify that the list of names displays and includes email address. (As before.) 6b. Using the user list dropdown, change from 'Brief' to 'User details'. Verify that the list of users displays and includes email address. (As before.) 7. Under 'Reports' in the navigation, open up 'Course completion'. Verify that the list of users displays and includes email address. (New.) 8. Under 'Reports' in the navigation, open up 'Activity completion'. Verify that the list of users displays and includes email address. (New.) 9. Open the gradebook (course administration / grades). Verify that list of users displays and includes email address. (New.) 10. Open the quiz and click 'Results' in the Navigation menu (easy to miss). If no users are shown, choose 'All participants who have or have not attempted the quiz' option from first dropdown. Verify that list of users displays and includes email address. (New.) 11. Open the SCORM activity and click 'Reports' tab. Verify that list of users displays and contains email address. (New.) 12. Open the assignment and click 'View N submitted assignments' link. Verify that list of users displays and contains email address. (New.) 13a. Open course administration / users / enrolled users. Verify that list of users contains email address. 13b. Click 'Enrol users' button Verify that list of users to select from contains email address. PART THREE - ALL OFF 14. Go back to the settings and turn all the checkboxes off, then save settings. 15. Now repeat the tests in tabs 2 to 13 inclusive, above. In each case check that none of the fields are displayed, except see the following extra notes: note 4b - searching for email address should NOT display the user this time note 6 - the 'user details' mode always displays email (for those with permissions) PART FOUR - FULL ON 16. Go back to the settings screen and turn all the checkboxes on, then save settings. 17. Now repeat the tests in tabs 2 to 13 inclusive, above. In each case check that all the fields are now displayed. Use the following extra notes for some cases: note 2, 4, 5 - Display will probably not fit in box - this is ok, nobody should turn on all options anyhow. It looks a bit weird if any of the fields are blank (you get a comma for the blank field) but this is OK as users shouldn't turn on these options unless they are reliably set (and the comma makes it unambiguous anyhow) note 3 - on most Moodle themes the report will probably not fit in browser width and may get cut off rather than using scrollbars, this is a separate pre-existing bug in most moodle themes and not related to this issue (also doesn't so much apply in realistic cases where you only tick one or two boxes) note 4b, 13b - on this screen, try searching for the start of a different field such as idnumber or phone number. (In the 'Enrol Users' screen you have to press Return after typing in your search text, which may be confusing; MDL-30139 ) note 3, 6, 9, 10, 11, 12, 13 - on these screens, additionally try sorting by one of the new columns (click it); behaviour should be same as if you sort by an existing column. note 13 - this screen looks pretty stupid when you have all the options ticked, but it's not too awful; and provided you only tick one or two, they fit in nicely. PART FIVE - CAPABILITY 18. On the course, go to the overrides screen (course administration / users / permissions). Next to the permission moodle/site:viewuseridentity, click the X beside Teacher so that your example teacher does not have the permission. 19. Log in as the example teacher. 20. Repeat the tests in tabs 4 to 12 inclusive, above. In each case check that none of the fields are displayed (as per PART THREE above). PART SIX - POSSIBLE GRADEBOOK SUCKAGE 21. Log back in as admin. Go back to the settings screen and turn on the 'idnumber' and 'department' checkboxes (just so we have a more realistic situation / less horrible table) and save settings. 22. Return to the grades screen. Reload. Verify that it's working with those two fields. 23. Turn editing on. Verify it's still working - meaning that the table columns/rows remain in synch with the headers. 24. Open site administration / grades / report settings / grader report. Flip the values of all the tickboxes so the opposite options are selected, then save settings. 25. Return to grades screen. Reload. Verify it's still working. 26. Toggle editing. Reload. Verify it's still working. 27. Open course administration / users / permissions. Turn off gradereport/user:view for the Teacher role. Log in as your sample teacher. View the grade report. (This should have caused the little grade icon next to user's name to disappears.) Verify it's still working. NOTE: At this point you might want to flip back the grade settings to default so they don't affect future tests. You can either do this manually or in database, DELETE FROM prefix_config WHERE name LIKE 'grade_report_%'; , then visit admin page and save settings.
    • Affected Branches:
      MOODLE_20_STABLE
    • Fixed Branches:
      MOODLE_22_STABLE
    • Pull Master Branch:
      MDL-26647-master
    • Rank:
      16225

      Description

      (NOTE: I have changed this description since the original one because the goal of this enhancement has changed and I felt leaving the original description was misleading. The main change is that it no longer offers an option to display username.)

      At large institutions, staff require reliable and convenient ways to identify users when adding users (to groups/etc) and when looking at lists of users.

      In Moodle, users are generally identified by their name (first name and last name). This works well for small systems where a teacher knows all their students, but is not a reliable way to identify users in large systems where administrative/course staff are typically not familiar with the names of students. Apart from anything else, for most names, we have more than one user with the same name. For example there are 10 users in our Moodle system called Sam Marshall, only one of whom is me! It is also frequently the case in our system that users have two OU [not just Moodle] accounts (one staff account, one student account) which will obviously have the same name.

      In addition to first name and last name, Moodle already offers other ways to identify users in certain locations:

      • In user selectors, the email address is displayed by default. There is also an option to display idnumber and username in this selector.
      • In the gradebook, quiz report, SCORM report, and activity/course completion reports, the idnumber can be optionally displayed. (The setting for this is inside gradebook settings, which doesn't make too much sense.)

      This causes the following problems:

      1) Behaviour is inconsistent; some reports optionally show idnumber, others don't, and user selectors show email addresses.
      2) There is an admin option to display usernames in user selector, which is considered by Moodle HQ to be a security risk.
      3) There is no security check on this display. For example, at some institutions (including ours) the student number [idnumber] is a privileged piece of information that is only supposed to be available to people to certain roles. Similarly it would be nice to configure for specific roles in specific courses or forums etc.
      4) It is not possible to enable consistent display of user fields that may be vital for administrative staff to work efficiently (such as idnumber, department, or other value, depending on institution).

      My proposed solution to these problems is as follows:

      1) Add new options that replace the existing options in user settings (where you used to be able to select username, idnumber, and email for user selectors) and in grade settings (where you used to be able to select idnumber for grade and, undocumented, other reports). The options will offer the following fields:

      • ID number
      • Email address
      • Phone number
      • Mobile phone
      • Department
      • Institution

      I chose this list after examining the user table and considering which fields were likely to be useful to administrators. For example, you can imagine somebody emailing to request an administrator makes a change, in which case email would be useful identifier; similar with the phone number. Institution and department are clearly potentially useful ('since this is a Science course, we probably want the John Smith from Science').

      Users would be expected to select zero, one, or two options from this list which correspond to profile settings that are mandatory at their institution. It does works if you select all of them, but that leads to some stupidly wide tables.

      Default is currently just email, which preserves existing behaviour in user selectors.

      2) Add a new capability to control access to this information

      moodle/site:viewuseridentity

      By default teachers, editing teachers, managers would have this, but students would not.

      This ensures that if any private fields (such as idnumber, in our case) are included in this information, we will not reveal that information to anyone who shouldn't see it.

      3) Add some API functions to make it easier to implement these changes

      I have a function that gets the list of fields (ie blank if you don't have the capability) and one that gets SQL suitable for including in a SELECT so you can make sure that database queries include required fields.

      4) Implement these options across most reports and other relevant locations in the system

      • User selectors (role assign in some places, groups, forum subscribers)
      • Browse users
      • Course participants
      • Grader report
      • Quiz report, SCORM report, assignment report
      • Course/activity completion reports
      • Enrol users
      1. enrol.png
        45 kB
      2. grades.png
        24 kB
      3. groups.png
        40 kB
      4. participants.png
        53 kB
      5. settings.png
        26 kB

        Issue Links

          Activity

          Hide
          Sam Marshall added a comment -

          On further investigation I found that there is already the following option:

          extrauserselectorfields

          It is on the 'User policies' page.

          This lets you choose fields that display in user selector only and does not apply to other lists. It is a comma-selected list of options like 'username,idnumber,email'. There also doesn't appear to be a capability restriction.

          This has somewhat complicated my plan. My revised proposal is:

          • Rename the existing setting to 'showuseridentity', preserving the existing values (if we're using it elsewhere it makes sense to have a more general name)
          • Add new (modified) field description and delete old language strings
          • Add new capability 'viewuseridentity' as above (default teacher, editing teacher, manager)
          • Change existing code that uses 'extrauserselectorfields' to use the new setting and to apply it only if the current user has that capability, via new function(s)
          • Add support for this to the other areas (apart from user selectors) mentioned above.

          Note that this would have the following impact by default:

          • In cases where students or guests or anyone else 'less than' teacher gets to see a user selector, if a site had previously selected to display username or idnumber or (default) email, this would not now be displayed (only the standard name would show) to those users.

          It is my belief that in general, users 'less than' teacher do not have access to pages that use the user selector, so this is not a problem - however if I am wrong about this, somebody please tell me.

          Show
          Sam Marshall added a comment - On further investigation I found that there is already the following option: extrauserselectorfields It is on the 'User policies' page. This lets you choose fields that display in user selector only and does not apply to other lists. It is a comma-selected list of options like 'username,idnumber,email'. There also doesn't appear to be a capability restriction. This has somewhat complicated my plan. My revised proposal is: Rename the existing setting to 'showuseridentity', preserving the existing values (if we're using it elsewhere it makes sense to have a more general name) Add new (modified) field description and delete old language strings Add new capability 'viewuseridentity' as above (default teacher, editing teacher, manager) Change existing code that uses 'extrauserselectorfields' to use the new setting and to apply it only if the current user has that capability, via new function(s) Add support for this to the other areas (apart from user selectors) mentioned above. Note that this would have the following impact by default: In cases where students or guests or anyone else 'less than' teacher gets to see a user selector, if a site had previously selected to display username or idnumber or (default) email, this would not now be displayed (only the standard name would show) to those users. It is my belief that in general, users 'less than' teacher do not have access to pages that use the user selector, so this is not a problem - however if I am wrong about this, somebody please tell me.
          Hide
          Sam Marshall added a comment -

          I've coded the first stage of this as one commit. This changes the setting name and description, and adds and implements the capability to existing user selector support. (No added support on the other lists yet - that's the next step.)

          Anyone who wants to follow along at home, feel free to look at it it on my github...

          https://github.com/sammarshallou/moodle/commit/06f7d167289870f045dfc867f7218c78ae21e88d

          MDL-26647 (1) 'extrauserselectorfields' -> 'showuseridentity', add capability

          This change:

          • Renames the existing setting 'extrauserselectorfields' to 'showuseridentity'
            in preparation for using it in more places. (Upgrade change, new version.)
          • Adds a new capability moodle/site:viewuseridentity, now required in order
            to see the extra fields; if you don't have the capability, you don't see them
          • Slightly improves the display of extra fields in user selector list; it used
            to be like 'sam marshall, sm449, 01234567, email@address' and is now
            'sam marshall [sm449, 01234567, email@address]' ie the fields are in square
            brackets (hopefully nobody really enables all three..)
          • Turns feature on for the group selector - the feature was enabled for other
            user selectors but not for the group selector. Tim did the disable code, he
            thinks this may be to do with more people having access to group selector -
            probably not a problem now it is controlled by capability.
          Show
          Sam Marshall added a comment - I've coded the first stage of this as one commit. This changes the setting name and description, and adds and implements the capability to existing user selector support. (No added support on the other lists yet - that's the next step.) Anyone who wants to follow along at home, feel free to look at it it on my github... https://github.com/sammarshallou/moodle/commit/06f7d167289870f045dfc867f7218c78ae21e88d MDL-26647 (1) 'extrauserselectorfields' -> 'showuseridentity', add capability This change: Renames the existing setting 'extrauserselectorfields' to 'showuseridentity' in preparation for using it in more places. (Upgrade change, new version.) Adds a new capability moodle/site:viewuseridentity, now required in order to see the extra fields; if you don't have the capability, you don't see them Slightly improves the display of extra fields in user selector list; it used to be like 'sam marshall, sm449, 01234567, email@address' and is now 'sam marshall [sm449, 01234567, email@address] ' ie the fields are in square brackets (hopefully nobody really enables all three..) Turns feature on for the group selector - the feature was enabled for other user selectors but not for the group selector. Tim did the disable code, he thinks this may be to do with more people having access to group selector - probably not a problem now it is controlled by capability.
          Hide
          Sam Marshall added a comment -

          Rest of this is now coded in another 4 commits.
          https://github.com/sammarshallou/moodle/compare/master...MDL-26647-useridentity

          NOTE
          I didn't touch the grader report because it was more complex than I realised; there are per-user settings as well as the report settings... I wasn't quite sure what to do, so decided 'nothing' was an option given that the grader report already has an option at least for idnumber.

          So altogether, these changes affect:

          • Browse users
          • Participants (brief and detail view)
          • Activity completion and course completion reports
          • Group members (where it was turned off before)
          • Other user selectors (the feature already existed there, but if you turned on these options, it displayed to everyone, there wasn't a capability).

          A POTENTIAL ISSUE

          By default this option is set to show email. That means there are some places which now display email (to teachers and up) that didn't before. For example, on the participants page, email previously only displayed if (a) you have the moodle/user:viewhiddendetails permission, or (b) the profile is set to show email. Now in addition to these possible ways of showing email, it also displays if you have the moodle/site:viewuseridentity capability. So if somebody overrode the moodle/user:viewhiddendetails permission, to prevent teachers seeing people's email, this will sort of undo that override.

          I wonder if the initial value of this capability should be set to the value of that one... or even if moodle/user:viewhiddendetails could be used INSTEAD of the new capability I created? Or is what I've done the best option...

          I am going to do a manual testing script for this and submit a PULL request (for 2.1 master branch) tomorrow hopefully.

          Show
          Sam Marshall added a comment - Rest of this is now coded in another 4 commits. https://github.com/sammarshallou/moodle/compare/master...MDL-26647-useridentity NOTE I didn't touch the grader report because it was more complex than I realised; there are per-user settings as well as the report settings... I wasn't quite sure what to do, so decided 'nothing' was an option given that the grader report already has an option at least for idnumber. So altogether, these changes affect: Browse users Participants (brief and detail view) Activity completion and course completion reports Group members (where it was turned off before) Other user selectors (the feature already existed there, but if you turned on these options, it displayed to everyone, there wasn't a capability). A POTENTIAL ISSUE By default this option is set to show email. That means there are some places which now display email (to teachers and up) that didn't before. For example, on the participants page, email previously only displayed if (a) you have the moodle/user:viewhiddendetails permission, or (b) the profile is set to show email. Now in addition to these possible ways of showing email, it also displays if you have the moodle/site:viewuseridentity capability. So if somebody overrode the moodle/user:viewhiddendetails permission, to prevent teachers seeing people's email, this will sort of undo that override. I wonder if the initial value of this capability should be set to the value of that one... or even if moodle/user:viewhiddendetails could be used INSTEAD of the new capability I created? Or is what I've done the best option... I am going to do a manual testing script for this and submit a PULL request (for 2.1 master branch) tomorrow hopefully.
          Hide
          Sam Marshall added a comment -

          Pull request PULL-665 now filed; includes full test script.

          Show
          Sam Marshall added a comment - Pull request PULL-665 now filed; includes full test script.
          Hide
          Martin Dougiamas added a comment -

          Hmm, I agree with the comments in the PULL that allowing usernames to be displayed anywhere is a bad idea for security. We've done pretty well enforcing it everywhere before now.

          Otherwise the rest looks OK.

          Show
          Martin Dougiamas added a comment - Hmm, I agree with the comments in the PULL that allowing usernames to be displayed anywhere is a bad idea for security. We've done pretty well enforcing it everywhere before now. Otherwise the rest looks OK.
          Hide
          Sam Marshall added a comment -

          Thanks Martin, Petr, Eloy.

          The situation here at the OU is that we need to be able to display BOTH the current idnumber (which is used for the official 'student number') AND the username (which is the user's official 'computer user name'). Admin/teaching staff need one identifier for some systems and another one for other systems. By the way, this same system ('student number' with totally separate 'computer username') was also in effect in both of the universities I attended as a student, so I think it's probably common.

          I know there is a potential security issue regarding username but this is a site decision. For example, at this institution we have the same security policy that students should not be able to find out the username of another student - but staff ('teacher' role and up) should be able to see this easily.

          Including admin settings, which default to not showing username, allow sites to make this decision.

          This said - as Petr and Eloy suggest it would be entirely possible to achieve this as part of our institutional dataload by by moving this data into the idnumber. This would require a change to our dataload and also changes to other systems that handle grade import/export and certain types of message sending, but is possible. (If it's not exactly clear what I'm saying... the 'update' part of this is basically 'UPDATE mdl_user SET idnumber = username || ' ' || idnumber'. And the changes are to make other university systems that previously used idnumber, capable of stripping out the bit before the space or adding it in etc.)

          Other institutions could potentially do the same thing with email addresses (provided that they never change - or I suppose you could make a local plugin that synchronizes them every day or something).

          So maybe this is a more coherent change (especially if there is really any intention to remove username from the user table). If that is the correct approach then we will work with it here. (Even though Tim doesn't like it.)

          Here are two proposals which I could code. Can I have opinions please, or any hints toward a third option? If any other institutions that want this feature have an opinion (i.e. say it could only show idnumber and not username, would that be sufficient for you?) then I imagine that would also be very helpful. I'll post in the forum thread mentioned.

          PROPOSAL 1 (Tim's suggestion)
          ----------

          Go ahead with my change but:

          a) Change the logic so that it lets you include ANY field from the user table as comma-separated list. (I think it's already a comma-separated list, but I mean, make the implementation that actually displays these columns generic; this will require a change to the new API I defined.)

          b) Change the UI so that the option for username is removed.

          c) Any site like ours that wants to play it dangerous can then edit config manually to add the username option back in. They can also potentially display other fields from the user table e.g. if they want to include department. Obviously this will not help us if username is ever removed from the user table.

          PROPOSAL 2 (based on Petr and Eloy's comments)
          ----------

          a) The three existing settings checkboxes are replaced with one checkbox 'Show idnumber in lists of users', default off, which also uses the new capability I already created (maybe changed). [The reason for default to off is that by default sites don't use idnumber so this avoids creating an unnecessary always-blank column in tables.]

          => This means that in Moodle 2.1 it will no longer be possible to display username and email in the user selector, only idnumber.

          b) Modify my existing changes so that the api is specific to idnumber and the code never includes username, email columns in the lists that were modified above, only idnumber. Except...

          c) In participants, browse users, where it previously displayed email as a special case, I should probably put this back so it remains as a special case (with its own logic about when to display).

          Show
          Sam Marshall added a comment - Thanks Martin, Petr, Eloy. The situation here at the OU is that we need to be able to display BOTH the current idnumber (which is used for the official 'student number') AND the username (which is the user's official 'computer user name'). Admin/teaching staff need one identifier for some systems and another one for other systems. By the way, this same system ('student number' with totally separate 'computer username') was also in effect in both of the universities I attended as a student, so I think it's probably common. I know there is a potential security issue regarding username but this is a site decision. For example, at this institution we have the same security policy that students should not be able to find out the username of another student - but staff ('teacher' role and up) should be able to see this easily. Including admin settings, which default to not showing username, allow sites to make this decision. This said - as Petr and Eloy suggest it would be entirely possible to achieve this as part of our institutional dataload by by moving this data into the idnumber. This would require a change to our dataload and also changes to other systems that handle grade import/export and certain types of message sending, but is possible. (If it's not exactly clear what I'm saying... the 'update' part of this is basically 'UPDATE mdl_user SET idnumber = username || ' ' || idnumber'. And the changes are to make other university systems that previously used idnumber, capable of stripping out the bit before the space or adding it in etc.) Other institutions could potentially do the same thing with email addresses (provided that they never change - or I suppose you could make a local plugin that synchronizes them every day or something). So maybe this is a more coherent change (especially if there is really any intention to remove username from the user table). If that is the correct approach then we will work with it here. (Even though Tim doesn't like it.) Here are two proposals which I could code. Can I have opinions please, or any hints toward a third option? If any other institutions that want this feature have an opinion (i.e. say it could only show idnumber and not username, would that be sufficient for you?) then I imagine that would also be very helpful. I'll post in the forum thread mentioned. PROPOSAL 1 (Tim's suggestion) ---------- Go ahead with my change but: a) Change the logic so that it lets you include ANY field from the user table as comma-separated list. (I think it's already a comma-separated list, but I mean, make the implementation that actually displays these columns generic; this will require a change to the new API I defined.) b) Change the UI so that the option for username is removed. c) Any site like ours that wants to play it dangerous can then edit config manually to add the username option back in. They can also potentially display other fields from the user table e.g. if they want to include department. Obviously this will not help us if username is ever removed from the user table. PROPOSAL 2 (based on Petr and Eloy's comments) ---------- a) The three existing settings checkboxes are replaced with one checkbox 'Show idnumber in lists of users', default off, which also uses the new capability I already created (maybe changed). [The reason for default to off is that by default sites don't use idnumber so this avoids creating an unnecessary always-blank column in tables.] => This means that in Moodle 2.1 it will no longer be possible to display username and email in the user selector, only idnumber. b) Modify my existing changes so that the api is specific to idnumber and the code never includes username, email columns in the lists that were modified above, only idnumber. Except... c) In participants, browse users, where it previously displayed email as a special case, I should probably put this back so it remains as a special case (with its own logic about when to display).
          Hide
          Tim Hunt added a comment -

          Just saw this again.

          After a couple of months' reflection, PROPOSAL 1 still seems like the right approach to me. I just thought I would note that here.

          Show
          Tim Hunt added a comment - Just saw this again. After a couple of months' reflection, PROPOSAL 1 still seems like the right approach to me. I just thought I would note that here.
          Hide
          Sam Marshall added a comment -

          I've got over my grumpiness about disagreements and am now trying to take this feature forward constructively. (May be a first for me! This feature is currently our top priority so I'm hoping to make progress.

          The new code is based on what I did before, but has been changed significantly. It is now fairly similar to Tim's proposal; it removes the option to display usernames while also being more generic. I have also implemented it in more locations that weren't finished before.

          I think this is pretty slick in a 'just works' kind of way. Also, at certain institutions, the option to select e.g. the 'Department' field may really be pretty useful.

          As a first step I'm going to ask Tim to review this. I think there may be a few loose ends still left in the code, and I still need to write test instructions as well...

          Show
          Sam Marshall added a comment - I've got over my grumpiness about disagreements and am now trying to take this feature forward constructively. (May be a first for me! This feature is currently our top priority so I'm hoping to make progress. The new code is based on what I did before, but has been changed significantly. It is now fairly similar to Tim's proposal; it removes the option to display usernames while also being more generic. I have also implemented it in more locations that weren't finished before. I think this is pretty slick in a 'just works' kind of way. Also, at certain institutions, the option to select e.g. the 'Department' field may really be pretty useful. As a first step I'm going to ask Tim to review this. I think there may be a few loose ends still left in the code, and I still need to write test instructions as well...
          Hide
          Tim Hunt added a comment -

          Generally very good. Does not seem to add much complexity, and it will make a lot of admins very happy

          Review comments:

          1. https://github.com/sammarshallou/moodle/commit/33db917e72ac0bf379869db66399c34c4bd19738#L1R137 is not laid out according to the Moodle coding guidelines.

          2. There is no way to add custom user profile fields there. I guess that would be hard, and so is out of scope for this bug.

          3. https://github.com/sammarshallou/moodle/commit/33db917e72ac0bf379869db66399c34c4bd19738#L5R388 You should add a comment above the capability definition explaining what it does (A bit like a PHPdoc comment for a function, but starting //.)

          4. https://github.com/sammarshallou/moodle/commit/33db917e72ac0bf379869db66399c34c4bd19738#L8R348 should have a , at the end of the line.

          5. I hate code that does concatenation like https://github.com/sammarshallou/moodle/commit/33db917e72ac0bf379869db66399c34c4bd19738#L8R348. I think it always comes out neater if you build an array then implode it.

          6. In https://github.com/sammarshallou/moodle/commit/1203e716c847f6e1f452a99ae87f6cda878facb6#L0R3374, should be space around the => thingy.

          7. https://github.com/sammarshallou/moodle/commit/1203e716c847f6e1f452a99ae87f6cda878facb6#L0R3403 I would use ', ' to join, to match the coding style.

          8. https://github.com/sammarshallou/moodle/commit/1203e716c847f6e1f452a99ae87f6cda878facb6#L0R3411 add_extra_user_fields_to_headers and add_extra_user_fields_to_data are a horrible bit of API.

          9. https://github.com/sammarshallou/moodle/commit/8deda7cd9eef08576fc17b2405207d5841e5b90b#L0R121 I hate unnecessary local variables like $extracolumns. If you are changing this line, you should change it to since quotes.

          10. https://github.com/sammarshallou/moodle/commit/8deda7cd9eef08576fc17b2405207d5841e5b90b#L0R218 I note that you are not using the API I criticised in 8.

          11. https://github.com/sammarshallou/moodle/commit/cdea3a15e2ba02b6d000bc7d2b4cff1a7ee20ec9#L0R323 I don't really know this bit of the UI, but "if brief, add lots more columns" seems like perverse logic.

          12. https://github.com/sammarshallou/moodle/commit/cdea3a15e2ba02b6d000bc7d2b4cff1a7ee20ec9#L0R390 It is hard to know whether it would be nicer to have a space before $extrasql or not. Note that the SQL here confirms 7.

          13. https://github.com/sammarshallou/moodle/commit/52e02f500113d3566c04c3fda6affe53e4f6309c#L0R225 should be a , at the end of the line.

          14. Throughout this file it uses print. The Moodle coding style is echo. I guess that is a separate bug.

          15. The get_string($field == 'phone1' ? 'phone' : $field) everywhere is ugly. Is it worth a user_field_name($field) function? Yes.

          16. I still have not seen any use of the crappy API from 8.

          17. https://github.com/sammarshallou/moodle/commit/958ea2f6f168a460d76961c6437687aac070d4de this sort of thing is highly dangerous, because of the weird option to have a fixed left column in the gradebook. We often get bugs where the two halves of the table do not line up. You need to test:
          a. With and without fixed user name columns.
          b. With and without showing various extra rows like the grade ranges, or average columns, and with different levels of nesting of grade categories.
          c. For users who can see the grader report, but who cannot see the (ou)user report.

          18. If $sortidnumberlink is not used, delete it. https://github.com/sammarshallou/moodle/commit/958ea2f6f168a460d76961c6437687aac070d4de#L0L604

          19. https://github.com/sammarshallou/moodle/commit/958ea2f6f168a460d76961c6437687aac070d4de#L6R245 Delete this comment. The extra fields are included in the download because they are useful, and because there is no issue with limited screen-space in a CSV file.

          20. To round it off. Delete the functions mentioned in 8.

          Show
          Tim Hunt added a comment - Generally very good. Does not seem to add much complexity, and it will make a lot of admins very happy Review comments: 1. https://github.com/sammarshallou/moodle/commit/33db917e72ac0bf379869db66399c34c4bd19738#L1R137 is not laid out according to the Moodle coding guidelines. 2. There is no way to add custom user profile fields there. I guess that would be hard, and so is out of scope for this bug. 3. https://github.com/sammarshallou/moodle/commit/33db917e72ac0bf379869db66399c34c4bd19738#L5R388 You should add a comment above the capability definition explaining what it does (A bit like a PHPdoc comment for a function, but starting //.) 4. https://github.com/sammarshallou/moodle/commit/33db917e72ac0bf379869db66399c34c4bd19738#L8R348 should have a , at the end of the line. 5. I hate code that does concatenation like https://github.com/sammarshallou/moodle/commit/33db917e72ac0bf379869db66399c34c4bd19738#L8R348 . I think it always comes out neater if you build an array then implode it. 6. In https://github.com/sammarshallou/moodle/commit/1203e716c847f6e1f452a99ae87f6cda878facb6#L0R3374 , should be space around the => thingy. 7. https://github.com/sammarshallou/moodle/commit/1203e716c847f6e1f452a99ae87f6cda878facb6#L0R3403 I would use ', ' to join, to match the coding style. 8. https://github.com/sammarshallou/moodle/commit/1203e716c847f6e1f452a99ae87f6cda878facb6#L0R3411 add_extra_user_fields_to_headers and add_extra_user_fields_to_data are a horrible bit of API. 9. https://github.com/sammarshallou/moodle/commit/8deda7cd9eef08576fc17b2405207d5841e5b90b#L0R121 I hate unnecessary local variables like $extracolumns. If you are changing this line, you should change it to since quotes. 10. https://github.com/sammarshallou/moodle/commit/8deda7cd9eef08576fc17b2405207d5841e5b90b#L0R218 I note that you are not using the API I criticised in 8. 11. https://github.com/sammarshallou/moodle/commit/cdea3a15e2ba02b6d000bc7d2b4cff1a7ee20ec9#L0R323 I don't really know this bit of the UI, but "if brief, add lots more columns" seems like perverse logic. 12. https://github.com/sammarshallou/moodle/commit/cdea3a15e2ba02b6d000bc7d2b4cff1a7ee20ec9#L0R390 It is hard to know whether it would be nicer to have a space before $extrasql or not. Note that the SQL here confirms 7. 13. https://github.com/sammarshallou/moodle/commit/52e02f500113d3566c04c3fda6affe53e4f6309c#L0R225 should be a , at the end of the line. 14. Throughout this file it uses print. The Moodle coding style is echo. I guess that is a separate bug. 15. The get_string($field == 'phone1' ? 'phone' : $field) everywhere is ugly. Is it worth a user_field_name($field) function? Yes. 16. I still have not seen any use of the crappy API from 8. 17. https://github.com/sammarshallou/moodle/commit/958ea2f6f168a460d76961c6437687aac070d4de this sort of thing is highly dangerous, because of the weird option to have a fixed left column in the gradebook. We often get bugs where the two halves of the table do not line up. You need to test: a. With and without fixed user name columns. b. With and without showing various extra rows like the grade ranges, or average columns, and with different levels of nesting of grade categories. c. For users who can see the grader report, but who cannot see the (ou)user report. 18. If $sortidnumberlink is not used, delete it. https://github.com/sammarshallou/moodle/commit/958ea2f6f168a460d76961c6437687aac070d4de#L0L604 19. https://github.com/sammarshallou/moodle/commit/958ea2f6f168a460d76961c6437687aac070d4de#L6R245 Delete this comment. The extra fields are included in the download because they are useful, and because there is no issue with limited screen-space in a CSV file. 20. To round it off. Delete the functions mentioned in 8.
          Hide
          Ray Lawrence added a comment -

          Sam, will this affect the display in the Assignment grading area?

          Should we be concerned that users can edit/delete ID Numbers in their profile.

          Show
          Ray Lawrence added a comment - Sam, will this affect the display in the Assignment grading area? Should we be concerned that users can edit/delete ID Numbers in their profile.
          Hide
          Dan Poltawski added a comment -

          Ray - if you were using the idnumber for this sort of thing you'd lock the idnumber field?

          Show
          Dan Poltawski added a comment - Ray - if you were using the idnumber for this sort of thing you'd lock the idnumber field?
          Hide
          Sam Marshall added a comment -

          Ray: I didn't do code for Assignment. Do I need to?

          (No change to editing or not of idnumber

          Show
          Sam Marshall added a comment - Ray: I didn't do code for Assignment. Do I need to? (No change to editing or not of idnumber
          Hide
          Sam Marshall added a comment -

          Thanks Tim for thorough review. I have now dealt with these comments and pushed a new version. However, the new code has not yet been tested; for the next step I'm going to look and see if I should add this to the Assignment report as suggested, then after that write a full test script.

          For the record I documented my actions in response to Tim's comments:

          1. Done - I have broken this as directed. (I hold to my position that horizontal alignment of any code elements, other than via standard indent, is bad in every case for every reason

          2. Yes, I decided custom user profiles are out of scope. Have revised existing comment to add a mention of that.

          3. Done

          4. Done

          5. Done

          6. Done

          7. Done

          8. Done - I deleted these functions. They were written assuming it would be good for reuse, but actually in every case this worked in a slightly different way so I wasn't able to use the functions.

          9a. Local variable is actually correct; it is used further down as well.
          9b. Done - I changed double to single quotes.

          10. As 8

          11. There are two modes, brief and non-brief; I added the data to both. Brief isn't really particularly brief.

          12. I didn't add the space, so that the SQL ends up looking 'nice' with the comma in the right place (like you said, it confirms 7...)

          13. This is a function call, not an array.

          14. I changed it to use echo for the new lines. This makes it inconsistent within the file but consistent with coding style; as people gradually change more and more lines it will gradually be fixed

          15. Done - I added function get_user_field_name($field) and used it in all cases.

          16. As 8

          17. Will include in test script (& fix if needed while I run through script)

          18. Done

          19. Done - I kept the comment but rewrote it to document this reasoning

          20. As 8

          Show
          Sam Marshall added a comment - Thanks Tim for thorough review. I have now dealt with these comments and pushed a new version. However, the new code has not yet been tested; for the next step I'm going to look and see if I should add this to the Assignment report as suggested, then after that write a full test script. For the record I documented my actions in response to Tim's comments: 1. Done - I have broken this as directed. (I hold to my position that horizontal alignment of any code elements, other than via standard indent, is bad in every case for every reason 2. Yes, I decided custom user profiles are out of scope. Have revised existing comment to add a mention of that. 3. Done 4. Done 5. Done 6. Done 7. Done 8. Done - I deleted these functions. They were written assuming it would be good for reuse, but actually in every case this worked in a slightly different way so I wasn't able to use the functions. 9a. Local variable is actually correct; it is used further down as well. 9b. Done - I changed double to single quotes. 10. As 8 11. There are two modes, brief and non-brief; I added the data to both. Brief isn't really particularly brief. 12. I didn't add the space, so that the SQL ends up looking 'nice' with the comma in the right place (like you said, it confirms 7...) 13. This is a function call, not an array. 14. I changed it to use echo for the new lines. This makes it inconsistent within the file but consistent with coding style; as people gradually change more and more lines it will gradually be fixed 15. Done - I added function get_user_field_name($field) and used it in all cases. 16. As 8 17. Will include in test script (& fix if needed while I run through script) 18. Done 19. Done - I kept the comment but rewrote it to document this reasoning 20. As 8
          Hide
          Sam Marshall added a comment -

          OK, I have now:

          • Added support for Assignment report
          • Added unit tests for the two new API functions
          • Written the test case

          New version of code has been pushed.

          I haven't actually finished going through the test case, will do that next (tomorrow hopefully).

          Show
          Sam Marshall added a comment - OK, I have now: Added support for Assignment report Added unit tests for the two new API functions Written the test case New version of code has been pushed. I haven't actually finished going through the test case, will do that next (tomorrow hopefully).
          Hide
          Sam Marshall added a comment -

          (Just fixing a 'can't count' issue in the test script.)

          Show
          Sam Marshall added a comment - (Just fixing a 'can't count' issue in the test script.)
          Hide
          Ray Lawrence added a comment -

          Dan, yes you are correct. I had the default in mind. Sam it might be worth making note of the option to alert admins to the option to lock the ID field in the instructions next to this feature.

          Show
          Ray Lawrence added a comment - Dan, yes you are correct. I had the default in mind. Sam it might be worth making note of the option to alert admins to the option to lock the ID field in the instructions next to this feature.
          Hide
          Ray Lawrence added a comment -

          Sam, apologies for not responding yesterday I had to leave the office unexpectedly at short notice. Thanks for adding to the Assignment report. Can we see this in Head?

          Show
          Ray Lawrence added a comment - Sam, apologies for not responding yesterday I had to leave the office unexpectedly at short notice. Thanks for adding to the Assignment report. Can we see this in Head?
          Hide
          Sam Marshall added a comment -

          Ray: This is not in any core Moodle branch yet. It needs to be approved by HQ before it can get in. If you want to test in your own development server, you can pull my branch from the git address given above, go to admin page and update; then you should be able to use it. Alternatively, I'm about to add some screenshots, so you could see what it looks like from that (although it's rather obvious).

          Re idnumber lock option - don't forget this feature defaults to only have 'email' set, not idnumber, so it doesn't apply unless you specifically go and tick the box. And I think if anyone's setting idnumber for people at institutional level (as we do, for instance) they have probably already locked it... Basically don't think this is really the right place to add a reminder. Can go in moodle docs, etc.

          Last night I realised that I hadn't done the enrol users page - oops. Have added that as another commit and fixed other issues (including changing from square brackets to normal brackets so that appearance in most places is cmopletely identical to previous with default settings). Also updated testcase (that I have actually succesfully completed now) including the gradebook options Tim was concerned about.

          Show
          Sam Marshall added a comment - Ray: This is not in any core Moodle branch yet. It needs to be approved by HQ before it can get in. If you want to test in your own development server, you can pull my branch from the git address given above, go to admin page and update; then you should be able to use it. Alternatively, I'm about to add some screenshots, so you could see what it looks like from that (although it's rather obvious). Re idnumber lock option - don't forget this feature defaults to only have 'email' set, not idnumber, so it doesn't apply unless you specifically go and tick the box. And I think if anyone's setting idnumber for people at institutional level (as we do, for instance) they have probably already locked it... Basically don't think this is really the right place to add a reminder. Can go in moodle docs, etc. Last night I realised that I hadn't done the enrol users page - oops. Have added that as another commit and fixed other issues (including changing from square brackets to normal brackets so that appearance in most places is cmopletely identical to previous with default settings). Also updated testcase (that I have actually succesfully completed now) including the gradebook options Tim was concerned about.
          Hide
          Sam Marshall added a comment -

          Here are some screenshots of the finished system.

          Show
          Sam Marshall added a comment - Here are some screenshots of the finished system.
          Hide
          Sam Marshall added a comment -

          I am submitting this for integration review. Comments last time seemed to suggest that the feature was generally approved of except for the issue with the ability to display username; this time I've removed that ability, improved the feature, and added detailed test script. Hopefully it is ok now.

          Show
          Sam Marshall added a comment - I am submitting this for integration review. Comments last time seemed to suggest that the feature was generally approved of except for the issue with the ability to display username; this time I've removed that ability, improved the feature, and added detailed test script. Hopefully it is ok now.
          Hide
          Martin Dougiamas added a comment -

          Those are possibly the best test instructions ever.

          Show
          Martin Dougiamas added a comment - Those are possibly the best test instructions ever.
          Hide
          Nadav Kavalerchik added a comment -

          Very useful feature. HQ, please consider it

          Show
          Nadav Kavalerchik added a comment - Very useful feature. HQ, please consider it
          Hide
          Nadav Kavalerchik added a comment -

          Funny...just looked at the dates and times of the comments...
          and saw that Martin posted a comment befor i did
          BUT has a post date which is later then my (previous to this) post.
          I wonder if Jira has "Back In Time" plugin, which i LOVE to use in Moodle too

          Show
          Nadav Kavalerchik added a comment - Funny...just looked at the dates and times of the comments... and saw that Martin posted a comment befor i did BUT has a post date which is later then my (previous to this) post. I wonder if Jira has "Back In Time" plugin, which i LOVE to use in Moodle too
          Hide
          Ray Lawrence added a comment -

          Looking good.

          Bizzare as it might seem in some cases being able to see the name of the user is an issue. Actual scenarios include students using the displayed information to repeatedly alert the police to posts that consider inappropriate and, less unusual, the requirement that those grading or reviewing work don't see the candidates name. Although it's extending this development, could this be a good time to include the ability to his the display of first an last name in these lists?

          Show
          Ray Lawrence added a comment - Looking good. Bizzare as it might seem in some cases being able to see the name of the user is an issue. Actual scenarios include students using the displayed information to repeatedly alert the police to posts that consider inappropriate and, less unusual, the requirement that those grading or reviewing work don't see the candidates name. Although it's extending this development, could this be a good time to include the ability to his the display of first an last name in these lists?
          Hide
          Sam Marshall added a comment -

          Ray: I understand where you're coming from - related requirements are actually an issue for us at the OU, where for data-protection reasons, you're not supposed to be able to see a list of everyone else who is on your course. (We have agreement that if you participate in collaborative activities your name will appear, though.)

          I don't think this is a good time to add a first/lastname option as part of this system, though. Partly because I'm lazy, of course, but there are some genuine reasons too:

          1) This functionality generally only applies to lists or tables of users. Most of these lists are not usually visible to students anyway. (The exception is Participants - I think there's a capability which you can turn off to hide that page if you don't want it; if not there should be.) I'm coming to this feature from the point of view of administrative tasks - staff being able to identify people easily, or enter necessary details into non-Moodle university systems, etc - which are hard without it.

          2) I don't really want to change all the other places that link to user profiles, like forum posts where it displays a user's name (which seems like the key one for you). There could be an argument for doing that but I'm trying to stick to the lists/tables thing; if you're dealing with a single user, it's easy enough to click to their profile (well, okay, usually two clicks now, but still not terrible) and get the information there. The annoyance is when you have a list/table of several and either you need to enter them in some non-Moodle system via a laborious process of clicking to profile on every name in the list, or else you're trying to guess which one is the right one via similar means. Or you're trying to search for somebody throughout the course/system by one of these data fields.

          3) If you really do want to hide a user's name from other students everywhere, I think there is already functionality for that! Not actually used it and not sure exactly how you set it up but there is a 'viewfullnames' capability; I think you can configure Moodle so it only shows first name (or possibly nothing...) except to people with this capability.

          Show
          Sam Marshall added a comment - Ray: I understand where you're coming from - related requirements are actually an issue for us at the OU, where for data-protection reasons, you're not supposed to be able to see a list of everyone else who is on your course. (We have agreement that if you participate in collaborative activities your name will appear, though.) I don't think this is a good time to add a first/lastname option as part of this system, though. Partly because I'm lazy, of course, but there are some genuine reasons too: 1) This functionality generally only applies to lists or tables of users. Most of these lists are not usually visible to students anyway. (The exception is Participants - I think there's a capability which you can turn off to hide that page if you don't want it; if not there should be.) I'm coming to this feature from the point of view of administrative tasks - staff being able to identify people easily, or enter necessary details into non-Moodle university systems, etc - which are hard without it. 2) I don't really want to change all the other places that link to user profiles, like forum posts where it displays a user's name (which seems like the key one for you). There could be an argument for doing that but I'm trying to stick to the lists/tables thing; if you're dealing with a single user, it's easy enough to click to their profile (well, okay, usually two clicks now, but still not terrible) and get the information there. The annoyance is when you have a list/table of several and either you need to enter them in some non-Moodle system via a laborious process of clicking to profile on every name in the list, or else you're trying to guess which one is the right one via similar means. Or you're trying to search for somebody throughout the course/system by one of these data fields. 3) If you really do want to hide a user's name from other students everywhere, I think there is already functionality for that! Not actually used it and not sure exactly how you set it up but there is a 'viewfullnames' capability; I think you can configure Moodle so it only shows first name (or possibly nothing...) except to people with this capability.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Integrated, just to cause somebody having to run the test steps. :-P

          Note there were a bunch of conflict on integrations, so pay special attention to:

          • upgrade
          • progress and completion reports, test them extensively, downloading....

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Integrated, just to cause somebody having to run the test steps. :-P Note there were a bunch of conflict on integrations, so pay special attention to: upgrade progress and completion reports, test them extensively, downloading.... Ciao
          Hide
          Rajesh Taneja added a comment -

          Great work Sam
          Works as described in detailed test instructions.

          One minor thing: If all details are not preset then extra commas are visible in combo box(,,xx@moodle.com,04490x,,,). I presume this was intentionally done, but might be nice to clean them for readability purpose.

          Show
          Rajesh Taneja added a comment - Great work Sam Works as described in detailed test instructions. One minor thing: If all details are not preset then extra commas are visible in combo box(,,xx@moodle.com,04490x,,,). I presume this was intentionally done, but might be nice to clean them for readability purpose.
          Hide
          Sam Marshall added a comment -

          Thanks both! And Rajesh, congrats on completing the monster test, apologies

          About details not present and extra commas - I agree this looks a bit rubbish but:

          a) people shouldn't tick the boxes unless these are values they expect people to always have filled in (e.g. because they are supplied automatically from the institution's systems, which I guess often happens for idnumber etc)

          b) at least this is unambiguous (e.g. if you turned on both phone numbers for some reason, then 12345, would be their landline phone and ,12345 would be their mobile phone)

          So I decided not to bother fixing it. Obviously if people don't like that it could be improved later.

          Show
          Sam Marshall added a comment - Thanks both! And Rajesh, congrats on completing the monster test, apologies About details not present and extra commas - I agree this looks a bit rubbish but: a) people shouldn't tick the boxes unless these are values they expect people to always have filled in (e.g. because they are supplied automatically from the institution's systems, which I guess often happens for idnumber etc) b) at least this is unambiguous (e.g. if you turned on both phone numbers for some reason, then 12345, would be their landline phone and ,12345 would be their mobile phone) So I decided not to bother fixing it. Obviously if people don't like that it could be improved later.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Yes, you got this finally upstream, just in time for Moodle 2.2beta. Congrats and thanks!

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Yes, you got this finally upstream, just in time for Moodle 2.2beta. Congrats and thanks! Ciao
          Hide
          Jason Hollowell added a comment -

          I'm curious as to why the ability to have the username field displayed was removed?? We create users accounts for them and their usernames are their student numbers (unique identifiers). I really need to be able to display that data in, for example, quiz report tables in order to be able to export data that can be manipulated in Excel etc.
          The functionality added thanks to this contribution is a huge step forward but without the username option we will have to step backward and edit all of our accounts to add the Student ID into the ID field (and lock it of course). That is certainly possibly but I'm just wondering why the conscious decision was made to remove username as a field that could be selected...?

          Show
          Jason Hollowell added a comment - I'm curious as to why the ability to have the username field displayed was removed?? We create users accounts for them and their usernames are their student numbers (unique identifiers). I really need to be able to display that data in, for example, quiz report tables in order to be able to export data that can be manipulated in Excel etc. The functionality added thanks to this contribution is a huge step forward but without the username option we will have to step backward and edit all of our accounts to add the Student ID into the ID field (and lock it of course). That is certainly possibly but I'm just wondering why the conscious decision was made to remove username as a field that could be selected...?
          Hide
          Tim Hunt added a comment -

          This is a security measure. If you want to hack a system (log-in as another user) you need two bits of information: their username and their password. Moodle uses the policy that to make it easy to find one of those bits of information (the username) is bad practice. (However, in some scenarios, like yours, that is excessively risk-averse, and has more disadvantages than advantages.)

          The good news is that it is possible to get the username displayed, it is just not possible using the admin UI. You need to set this setting by hard-coding it in the config.php file. You need to add something like
          $CFG->showuseridentity = 'username,idnumber,email';

          Show
          Tim Hunt added a comment - This is a security measure. If you want to hack a system (log-in as another user) you need two bits of information: their username and their password. Moodle uses the policy that to make it easy to find one of those bits of information (the username) is bad practice. (However, in some scenarios, like yours, that is excessively risk-averse, and has more disadvantages than advantages.) The good news is that it is possible to get the username displayed, it is just not possible using the admin UI. You need to set this setting by hard-coding it in the config.php file. You need to add something like $CFG->showuseridentity = 'username,idnumber,email';
          Hide
          Sam Marshall added a comment -

          I disagreed with the decision to prevent including username, because I think this is a site policy area where different sites may have different policies. (Our policy, like yours, is that staff can see all student usernames and frequently need to use them.)

          But Moodle HQ made that decision, so I designed the final version of this feature to comply with it (while it still allows a 'secret' method to access username as Tim has indicated, which you can use at own risk).

          If anyone would like the system changed to add username to the normal list of fields that can be displayed using the standard interface (without hacking random things in config file), then please file a separate bug to request it as an improvement.

          Show
          Sam Marshall added a comment - I disagreed with the decision to prevent including username, because I think this is a site policy area where different sites may have different policies. (Our policy, like yours, is that staff can see all student usernames and frequently need to use them.) But Moodle HQ made that decision, so I designed the final version of this feature to comply with it (while it still allows a 'secret' method to access username as Tim has indicated, which you can use at own risk). If anyone would like the system changed to add username to the normal list of fields that can be displayed using the standard interface (without hacking random things in config file), then please file a separate bug to request it as an improvement.
          Hide
          Ray Morris added a comment - - edited

          Though this ticket is closed, I expect the issue of displaying the user name will come up again, so I thought
          it might be useful to comment from the perspective of a security professional. (Security has been my focus for
          25 years, I also do a bit of web programming.)

          > This is a security measure. If you want to hack a system (log-in as another user) you need two bits of information:
          > their username and their password.

          Hiding the user name is generally regarded as harming, not improving security. The password is the protected secret, the user's name is not the protected secret. On this system, for example, by mousing over the links I can see that Tim's user name is "timhunt", Jason's is "kokoro", Sam's is "quen", etc. Isn't it better if the name is "kind of, sort of a little bit protected"? No! You most often get in trouble regarding security when you get confused about what is a protected secret and what's not. If you're not 100% clear on what's protected and what's not, or start thinking that it's okay to treat things as "sort of confidential" that's when leaks happen. The user's name and their password are each either strictly secret or strictly open. For names and passwords, the decision was made in the early 1970's - passwords are secret (strictly) while user names are open identifiers (strictly open, don't start thinking they are maybe secret and get confused).

          For example, because are we are 100% clear that passwords are secret, you hash them in the database (as Moodle correctly does, though weakly).
          Since user names are not secured secrets, they aren't hashed in the database. Ah, but then if you start using them as if they were secured secrets, you now have a security key which isn't stored securely! It's not stored securely, it's not treated securely in many ways, so don't start making it look like user names can be treated as secure, because they aren't.

          Show
          Ray Morris added a comment - - edited Though this ticket is closed, I expect the issue of displaying the user name will come up again, so I thought it might be useful to comment from the perspective of a security professional. (Security has been my focus for 25 years, I also do a bit of web programming.) > This is a security measure. If you want to hack a system (log-in as another user) you need two bits of information: > their username and their password. Hiding the user name is generally regarded as harming, not improving security. The password is the protected secret, the user's name is not the protected secret. On this system, for example, by mousing over the links I can see that Tim's user name is "timhunt", Jason's is "kokoro", Sam's is "quen", etc. Isn't it better if the name is "kind of, sort of a little bit protected"? No! You most often get in trouble regarding security when you get confused about what is a protected secret and what's not. If you're not 100% clear on what's protected and what's not, or start thinking that it's okay to treat things as "sort of confidential" that's when leaks happen. The user's name and their password are each either strictly secret or strictly open. For names and passwords, the decision was made in the early 1970's - passwords are secret (strictly) while user names are open identifiers (strictly open, don't start thinking they are maybe secret and get confused). For example, because are we are 100% clear that passwords are secret, you hash them in the database (as Moodle correctly does, though weakly). Since user names are not secured secrets, they aren't hashed in the database. Ah, but then if you start using them as if they were secured secrets, you now have a security key which isn't stored securely! It's not stored securely, it's not treated securely in many ways, so don't start making it look like user names can be treated as secure, because they aren't.

            People

            • Votes:
              25 Vote for this issue
              Watchers:
              19 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: