User display names #1246
Merged
User display names #1246
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It is not uncommon for forums to be intergrated with sites where users don't have a unique "handle" - they might just have their first name, or a full name, which is not guaranteed to be unique. This commit introduces the concept of "display names" for users. By default display names are the same as usernames, but extensions may override this and set them to something different. The important thing is that all code should use `display_name` whenever intending to output a human-readable name - `username` is reserved for cases where you want to output a unique identifier (which may or may not be human-friendly). The new "GetDisplayName" API is probably sub-optimal, but I didn't worry too much because we can come up with something better in `next-back`. ref #557
|
Note that this is not the same thing as "screen names" as suggested in #557 (comment). A screen name (or "full name" might be a better name for it) extension which just wants to add an optional profile field, and preserve the username as the primary human-readable identifier, would not need to change the display name. |
tobyzerner
added a commit
to flarum/mentions
that referenced
this pull request
Sep 19, 2017
This also improves the behaviour of mentions in the JS preview (no more broken links, mention is only picked up if corresponding user/post is found). See flarum/framework#1246 Closes flarum/framework#315
franzliedke
approved these changes
Sep 20, 2017
[ci skip] [skip ci]
Apply fixes from StyleCI
This was referenced Sep 15, 2021
askvortsov1
pushed a commit
to flarum/mentions
that referenced
this pull request
Mar 11, 2022
This also improves the behaviour of mentions in the JS preview (no more broken links, mention is only picked up if corresponding user/post is found). See flarum/framework#1246 Closes flarum/framework#315
This was referenced Jun 21, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
(I'm going into
masterhere because I need to use this imminently for a client project.)It is not uncommon for forums to be intergrated with sites where users don't have a unique "handle" - they might just have their first name, or a full name, which is not guaranteed to be unique.
This PR introduces the concept of "display names" for users. By default display names are just an alias for usernames, and they cannot be changed in core (we are not introducing a new column into the DB).
But extensions may override this and set them to something different. eg. the client integration I'm working on uses a numeric ID as the
username, and adds adisplay_namecolumn which is set to a non-unique first name.The important thing is that all code should use
display_namewhenever intending to output a human-readable name -usernameis reserved for cases where you want to output a unique identifier (which may or may not be human-friendly) - eg. @mentions, user profile URL slugs.The new "GetDisplayName" API is probably sub-optimal, but I didn't worry too much because we can come up with something better when we bring this into
next-back.Just wanting some feedback on the concept and implementation before I merge.
ref #557