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.
Version: 1.24rc
Severity: normal
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T72670 Move things that are not preferences out of the preferences page | |||
| Open | None | T306248 Consider storing a users real name in user properties |
"realname" is considered to be a special preference (see User::getOptionKinds() and Preferences::getSaveBlacklist()( and can't be set via the API.
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.