#179 - Display names
-
By Chris Graham
- Added
- 5 views
| Identifier | #179 |
|---|---|
| Issue type | Feature request or suggestion |
| Title | Display names |
| Status | Completed |
| Tags |
Risk: Core rearchitecting (custom) |
| Handling member | Chris Graham |
| Addon | core_cns |
| Description | Extend the get_username function to have an extra parameter that says whether to show the users real name (set via custom profile field, or via stripping the appended username number) instead of their username. This parameter would default to true. It would only be passed in as false in situations where the true login name was required.
However, by default, the parameter would be ignored and thus the real username always used - a new config option turns it on. Additionally we should try and remove usernames being typed into the system, e.g. in form fields or Comcode. Favour member IDs instead. |
| Steps to reproduce | |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments
So the pragmatic thing is just to tell people to enter their real names as their usernames. However if people have the same name it gets nasty.
This is only a problem on large sites though, and not a huge one - people can just qualify it a bit, like with a birth-year or a country.
1) people want to use their unadulterated real names, without worry of conflict
2) when accounts are imported and usernames never explicitly chosen (so they may actually be horrible but required auto-generated codes, that we don't want to display in most circumstances)
3) when we really do need usernames that are more like codes (e.g. used in URLs, such as how Facebook uses them, or for email addresses) AND human display names
Commandr, chat, security/audit tools - these will continue to use usernames, as distinguishing is needed in those cases.
Most other code now uses display names.
Rather than making all get_username calls default to display names, a full review was carried out. This is safer. In a lot of cases we pass through both to language strings. For templates, we usually pass the username, but templates now make the decision whether to actually convert that to a display name.
Forum drivers of third party forums supporting display names have been extended (OTTOMH: SMF and IPB).
The display name generation is configurable, so you may bind against a single name CPF, or against multiple name CPFs (e.g. separate forename -and- surname fields).
Most form_input_username inputs are confirmed to have actions to prepopulate them. The main exceptions are admin ones (the admin is presumed competent to find usernames). Upon initial click, it will show your friends for selection.
The get_member_from_username field is programmed to accept member IDs as a parameter (although still is preferential towards usernames).
Native things that take usernames now will take member IDs.
"This issue has always been a really tricky one. Usernames get typed quite often, e.g. in a 'quote' tag, so people need to know usernames. But if human names are shown, people won't, or at least will get confused."
This isn't such a big deal, as the quote tag is usually generated by a button. The user doesn't really need to type the username. The quote tag does support member IDs now, so if they don't know about usernames and put in a member ID instead, it won't break.
The username is shown explicitly on the member profile screen (via a template) so that it can be found.
The login box shows the username rather than the display name, but that is changeable if desired. Username is shown as the primary understood context of this box is logging in and out, rather than your personal identity. It's a close call though.
Some related API cleanups happened in this commit also.