Last modified: 2013-04-22 16:16:39 UTC
action=options API should allow resetting of chosen preferences, instead of the all-or-nothing approach it currently has. This would be particularly useful for the newly implemented semi-arbitrary userjs- prefs (see bug 40124), as it's not possible to entirely remove them without killing them all, along with "real" preferences.
Seems fine to me. Except we can't use the "reset" parameter for this, do you have a suggestion for a parameter name?
We could use 'resetkeys' (which would accept pipe-separated keys), and possibly also implement 'resetkinds' (which would accept pipe-separated options kinds, as returned by User::getOptionsKinds). API versioning would help, so I'm adding Yuri to CC list ;)
If we wait for APIv2, we'll probably be waiting a while. ;) 'resetkeys' sounds fine to me. And 'resetkinds', if someone wants it. May as well deprecate plain 'reset' while we're at it.
'resetkeys' is unnecessary; it is already implemented. If you pass an option key without a value to ApiOptions, e.g., api.php?change=optionkey|otheroption&token=blah, ApiOptions will interpret the option value to be null, which, when passed to User::setOption, causes the option to be reset to the default value. All that is needed is 'resetkinds', so that certain groups of options can be reset, e.g., only userjs- options, rather than having to reset all options.
(In reply to comment #4) > 'resetkeys' is unnecessary; it is already implemented. If you pass an option > key without a value to ApiOptions, e.g., > api.php?change=optionkey|otheroption&token=blah, ApiOptions will interpret > the > option value to be null, which, when passed to User::setOption, causes the > option to be reset to the default value. Oh, that's interesting (and quite counterintuitive and undocumented). Thanks for the info.
I'm probably going to implement 'resetkinds' tonight, so I'll also add in a documentation note about resetting individual options.
https://gerrit.wikimedia.org/r/43987
Merged.
