-
Improvement
-
Resolution: Fixed
-
Minor
-
2.0.2
-
None
-
MOODLE_20_STABLE
-
MOODLE_22_STABLE
-
MDL-26647-master -
(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
- caused a regression
-
MDL-31804 Grader report generates SQL error on Oracle
- Closed
-
MDL-30266 Some failures on unit tests (testcompletionlib.php)
- Closed
- has been marked as being related by
-
MDL-26882 user profile fields not shown in profile
- Closed
-
MDL-38061 idnumber field does not display in the assignment module
- Closed
- will help resolve
-
MDL-30047 $CFG->extrauserselectorfields not used in manual enrol ajax search form
- Closed
-
MDL-31776 Additional name fields, to allow Asian languages to flexibly display user names in Chinese characters, local phonetic system or Romanization
- Closed
-
MDL-20919 Again: Allow admin user to choose the fields shown in the 'Browse List of Users' page
- Closed