Page MenuHomePhabricator

Ensure ResourceLoader::getUserDefaults() works with conditional options defaults
Closed, ResolvedPublic


As part of T321527: Support conditional defaults for user properties, the Growth team is adding support for conditional options defaults into MediaWiki Core. Once that change is merged into core, default values of user properties might vary by user (in other words, foo-option might have a default value of 1 for User A, but a default value of 0 for User B).

ResourceLoader::getUserDefaults() serves to export default values for user options to the frontend (via the user.json pseudo-file from the mediawiki.base module). Because it is a ResourceLoader callback, it is trickier to fix (for most RL modules, current user is not available, as the modules are subject to sitewide caching). We will probably end up having to store defaults for conditional properties (ConditionalDefaultsLookup::getConditionallyDefaultOptions()) in one of the per-user modules, such as user.defaults. This change should be implemented as part of this task.

Related Objects

Event Timeline

KStoller-WMF moved this task from Backlog to Up Next on the Growth-Team board.

Based on @SD0001's comment on the Core patch, I'm now convinced that this is actually already ensured, with only a slight change in the patch I linked.

The important bit for that conclusion is that UserOptionsLookup::getOptions( $user, EXCLUDE_DEFAULTS ) returns all $user's options that do not match the current site wide defaults (disregarding any conditional defaults). Because ResourceLoader::getUserDefaults also disregards conditional defaults, the logic behind mw.user.options should treat the case the same way as if the user themselves changed the user option to the conditional default.

As far as I understand it now, with the current patch, mw.user.options would return the correct values for conditionally default options. It'd still have some limitations (mainly the inability to see conditional defaults definitions), but I think that's perfectly acceptable (and if someone ends up needing that on the frontend, we can easily add it in the future).

I verified those assumptions with the following configuration and with no manual overrides of foo-opt:

$wgDefaultUserOptions['foo-opt'] = 'before';
$wgConditionalUserOptions['foo-opt'] = [
                [ CUDCOND_AFTER, '20230624000000' ],

For a legacy user, mw.user.options.get('foo-opt') returns before (as expected) and for a freshly registered user, mw.user.options.get('foo-opt') returns after (as expected).

With this in mind, I think we can close this task as Resolved. @Tgr, @SD0001 or others, if you disagree, please feel free to re-open with your thoughts.

Urbanecm_WMF claimed this task.