Alternate name fields: Difference between revisions
(First draft to get started) |
No edit summary |
||
| Line 1: | Line 1: | ||
{{Work in progress}} | |||
{{Infobox Project | |||
|name = Alternate name fields | |||
|state = Early specification | |||
|tracker = MDL-31776 | |||
|discussion = | |||
|assignee = Adrian Greeve | |||
}} | |||
This is a spec for adding support for multiple name fields to Moodle 2. | This is a spec for adding support for multiple name fields to Moodle 2. | ||
| Line 6: | Line 15: | ||
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. | 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. | |||
Revision as of 06:45, 27 February 2013
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 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
