Last modified: 2014-09-13 17:14:20 UTC
I'm trying to build an ajax preferences form. When I try to edit name action:options format:json optionname:realname optionvalue:Jon R I get the following response: {"warnings":{"options":{"*":"Validation error for 'realname': cannot be set by this module"}},"options":"success"} As a result I can't finish this enhancement.
"realname" is considered to be a special preference (see User::getOptionKinds() and Preferences::getSaveBlacklist()( and can't be set via the API.
Historically why is this the case?
I'm guessing because it's not a real preference and actually stored in the user table.
Because 'realname' and 'emailaddress' are not actual user preferences stored in the (confusingly named) user_properties table, but properties of the user itself (like user name or password) stored in the user table (user_real_name and user_email fields). I don't know why they were implemented this way. 'emailaddress' is luckily not a problem here (it's not shown on Preferences; actually I don't know why it's in the blacklist), but 'realname' is. Perhaps it should get its own special page for changing it, like email and password? Or perhaps it should be converted into actual user pref?
When we want bug 63354 than we should not move the real name to the properties table. 'emailaddress' seems to be forgotten to remove, when the Special:ChangeEmail special page was created (r92924).
As far as the API goes, this is WONTFIX. We could change the error message for 'special' to the same as 'unused' ("not a valid preference") to avoid confusing people, but it wouldn't help Jon's use case. But if someone wants to reopen this and reassign it to "User preferences" for moving realname off of Special:Preferences somehow, go ahead.
(In reply to Bartosz Dziewoński from comment #4) > Because 'realname' and 'emailaddress' are not actual user preferences stored > in the (confusingly named) user_properties table, but properties of the user > itself (like user name or password) stored in the user table (user_real_name > and user_email fields). I don't know why they were implemented this way. > Because those fields predate the user_properties table. Remember, prefs used to be stored as a blob in user.user_options. > 'emailaddress' is luckily not a problem here (it's not shown on Preferences; > actually I don't know why it's in the blacklist), but 'realname' is. Perhaps > it should get its own special page for changing it, like email and password? > Or perhaps it should be converted into actual user pref? Let's do the last one! Move it to a real pref.
