discourse/discourse — pull request #1722 by vikhyat (2013-12-06 02:33:03+00:00)
Title: enable_names site setting functionality

Currently all the enable_names setting does when it is disabled is to remove the `name` field from the user serializer output.

If enable_names if false:

* Don’t disable saving user preferences if the name field is blank.
* Don’t allow changing name in preferences.
* Set every user’s name to their username in an initializer. This is the part I am not too sure about. It is needed because there are places such as the header template which assume that the name is set. One alternative would be to have a computed property like nameOrUsername that would return the correct string, but I wonder if it might be better to always return a name from the server, but if enable_names is false to return the username in place of the name everywhere. This can be done fairly easily by adding a getter to the user model. I suspect doing it server-side would be the cleanest approach (it would also fix the first issue noted below), but I figured I’d check first before implementing it?

Issues I noticed which I haven’t fixed:

* The User Action serializer includes names, e.g. http://forums.hummingbird.me/user_actions.json?offset=0&username=reaperofspades. Same problem with the preloaded currentUser object.
* Should probably hide the name field during account creation?
* (Unrelated) If the user makes changes to their preferences but doesn’t save them, the changes are still shown to the user until the page is refreshed. It would make sense to revert changes when transitioning out of the preferences route if the user doesn’t save their changes.