Page MenuHomePhabricator

action=options API should allow resetting of chosen preferences (instead of the all-or-nothing approach)
Closed, ResolvedPublic

Description

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.


Version: 1.21.x
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=43960

Details

Reference
bz43959

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:14 AM
bzimport set Reference to bz43959.

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.