Alternate name fields
Note: This page is a work-in-progress. Feedback and suggested improvements are welcome. Please join the discussion on moodle.org or use the page comments.
| Alternate name fields | |
|---|---|
| Project state | Early specification |
| Tracker issue | MDL-31776 |
| Discussion | |
| Assignee | Adrian Greeve |
This is a spec for adding support for multiple name fields to Moodle 2.
Background
Names of users are accessed and displayed across Moodle in a hundreds of locations, and many more in add-on modules.
In most places this is done we use the fullname() function to do it, but there are also many places that process the 'firstname' and 'lastname' fields directly from the user table.
This approach does not cover a whole lot of cases when we want to show other things in place of the actual name of the user.
Use cases and requirements
In Japanese Moodle sites users are displayed using original and romanised versions of names.
In Chinese and other languages users names are displayed with phonetic versions (eg Pinyin) alongside original versions.
In Spanish and Arabic countries they routinely have three or more names that they want to display.
In some activities and courses users can appear under chosen aliases in order that their true identity is protected from other users (sensitive discussions etc)
In some activities and courses users can appear under chosen aliases in order to support role playing and simulation games.
Some users may be more widely known by nicknames/handles rather than their official names, and would like both displayed to aid identification.
Rejected solutions
The most flexible and perhaps "proper" solution relies on extending the custom user profile fields with a new type that the administrator can configure to their needs. In general we have a policy in place of moving user fields to this system. Unfortunately this solution has the downsides of being more complicated to implement in the hundreds of places that the information may be used, and may affect performance in terms of too many extra SQL queries.
Another idea was a complete refactoring of user information by the building of new user classes to seamlessly access and update fields spread across multiple tables. This was also rejected as being a very large job with limited usefulness and a high chance of regressions in all Moodle code.
Solution overview
This solution was chosen on the basis that it is easier to implement and will still support all the required use cases with a almost no impact on performance and existing add-on code.
- User table
- Add new fields for alternate names to the user table. We believe that of all the things that could be added to such an important and core table, the names of users ranks the highest and so this is justified.
- fullname() function
- Add support for these new fields, as well as new arguments for the current context and possibly a hardcoded name format.
- fullname() will now call a new function fullname_format() to calculate the final format of the name to return based on language strings, admin settings, course settings, activity settings and context.
- (backward compatibility) When new fields are not passed by parameter, fullname() can retrieve data from database, using MUC for caching
- Settings (used by fullname_format())
- Admin settings allow the admin to decide an override site format for name display, otherwise lang packs will be used (similar to now, but add manual typing of the token string)
- Admin setting to decide the format that is used when displayfullname capability is enabled (designed for admins etc to see more information than most people)
- Course settings allow the teacher to decide an override format for name display, otherwise site setting is used
- Activity settings allow the teacher to decide an override format for name display, otherwise course setting is used
- Upgrades around Moodle
- All calls to fullname() should be upgraded to add the new parameters and user fields in the most efficient way possible. For the case of long lists, this may mean adding new fields to the SQL extracting bulk data from user table.
- Check places where u.firstname and u.lastname are used directly (eg reports), and update these accordingly to use the new name fields where possible
- Backup
- Add support for backup/restore of the new fields, including backward compatibility where possible.
- Documentation
- Update documentation for user table and API
Details
User table
The user table will be altered to add in additional fields. The current proposal is to add the following fields:
- lastnamephonetic
- firstnamephonetic
- alternatename (This could also be useful for three-name countries)
- aliasname (For handles and anonymity)
Changes will nee to be made to editlib.php to include mform elements for each of the new fields.
Fullname function
To be altered.
Returns a persons fullname (including additional names) ready for display.
current parameters
param - object $user A $USER object, used to get all name details.
param - bool $override If true then the name will be first name followed by last name rather than adhering to fullnamedisplay setting. (optional setting)
Additional parameters
param - object $context The current context. (optional setting)
param - string $nameformat Default name format to use if no other format can be found. (optional setting)
Backwards compatibility
With the new fields being introduced into the 'user' table in some instances we will already have all the information passed through the variable $user. Alterations can be made to core code to make this happen. A check will be done to see if this information is present and if not it will be retrieved from the database. This is particularly important for plugins. The Moodle Universal Cache will be used to decrease calls made to the database.
fullname_format function
To be created.
Return a format for the full name to follow.
Depending on what settings have been set we try each different level getting more general until we arrive to a setting that has been defined or the default fullname format.
Start with the context and we go down the list until a setting is found.
- check for activity setting.
- check for course setting.
- check for site setting.
- fall back to language string.
parameters
param object $context The current context (optional setting).
return string The fullname format string.
Capabilities
Currenlty we only have one capability for viewing names: moodle/site:viewfullnames.
The inclusion of moodle/site:canoverridenameformat might be useful for administrators to control exactly how the alternate name fields are presented.
Settings
Admin settings
- Set an override site format for name displays. Defaults back to language packs.
- Full name format when fullnamedisplay setting is set or viewfullnames.
Course settings
- The teacher has the ability to override the format. Defaults to site setting.
Activity settings
- The teacher has the ability to override the format. Defaults to course setting.
Main areas that require these settings
- Site admin page
- Course edit page
- Each activity edit page.
Settings to be stored in the config table.
format configuration
For each of the different settings mentioned above a row of select boxes with the full list of available name information would be presented in order of left to right (consideration also needs to be made for RTL languages).
These settings could be displayed as an mform type for easy inclusion in multiple edit files.
Not in the scope of this project
Sorting additional name fields.
