Page MenuHomePhabricator

Mentee overview(vue): Empty string in "Maximum"/"Minimum" filter options is not persisted
Closed, ResolvedPublicBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

  • As a mentor, open Special:MentorDashboard
  • Click "Filters" and in the dialog, put an empty string in place of the "Maximum" or "Minimum" field (like at F35566354)
  • Click "Update"
  • Reload the page
  • Click "Filters" and examine the state of the filters

What happens?:

The filters were reset to 1/500 (minimum/maximum), aka the default state.

What should have happened instead?:

The empty string (=filter is not used) should be persisted for next load, using the presets preference.

Other information (browser name/version, screenshots, etc.):
Tested in enwiki with the Vue deployment patch applied.

Event Timeline

Change 842751 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/GrowthExperiments@master] Mentee filters: always use mw.user.options values to initialise the mentees store

https://gerrit.wikimedia.org/r/842751

@Urbanecm_WMF Thanks for filing this. I have pushed a patch that should fix the issue. I have one question, see below:

Right now, in the Vue dashboard, the user preferences save call ( user-preferences.js#saveOption ) is not setting the mw.user.options when doing the Api request as opposed of the prior (MenteeOverviewPresets.js#setPreset). Should we do the same here for consistency? I'm more on the side the setting should happen just if the request is successful.

Since the Vuex stores are for reactive data but we're manually setting mw.user.options I wonder if we should strip this out of stores/modules and have them somewhere else just as convenience methods. (ie: MenteeOverviewApi.js).

Thanks for the quick fix @Sgs! Merged.

Ad calling mw.user.options.set, good question. That call was added in d665b46cb by @kostajh, with "call mw.user.options.set so the setPreset change takes immediate effect" as the comment. I'm not sure why would that be needed, AFAICS, mw.user.options.get is only called when the non-Vue mentee overview module is inicialized, and then it keeps its state internally. I don't think calling or not calling mw.user.options.set would make any difference.

Change 842751 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Mentee filters: always use mw.user.options values to initialise the mentees store

https://gerrit.wikimedia.org/r/842751

Change 842897 had a related patch set uploaded (by Urbanecm; author: Sergio Gimeno):

[mediawiki/extensions/GrowthExperiments@wmf/1.40.0-wmf.5] Mentee filters: always use mw.user.options values to initialise the mentees store

https://gerrit.wikimedia.org/r/842897

I think the fix should be backported next week (followed with enabling Vue everywhere). That way, we should be able to fix any additional potential regressions, should they be noticed only after rolling Vue out. Uploaded a patch suggesting that.

Change 842897 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@wmf/1.40.0-wmf.5] Mentee filters: always use mw.user.options values to initialise the mentees store

https://gerrit.wikimedia.org/r/842897

Mentioned in SAL (#wikimedia-operations) [2022-10-17T07:50:22Z] <urbanecm@deploy1002> Started scap: Backport for [[gerrit:842897|Mentee filters: always use mw.user.options values to initialise the mentees store (T320728)]]

Mentioned in SAL (#wikimedia-operations) [2022-10-17T07:50:48Z] <urbanecm@deploy1002> urbanecm and urbanecm: Backport for [[gerrit:842897|Mentee filters: always use mw.user.options values to initialise the mentees store (T320728)]] synced to the testservers: mwdebug2001.codfw.wmnet, mwdebug1002.eqiad.wmnet, mwdebug2002.codfw.wmnet, mwdebug1001.eqiad.wmnet

Mentioned in SAL (#wikimedia-operations) [2022-10-17T07:57:44Z] <urbanecm@deploy1002> Finished scap: Backport for [[gerrit:842897|Mentee filters: always use mw.user.options values to initialise the mentees store (T320728)]] (duration: 07m 22s)

Thanks for the quick fix @Sgs! Merged.

Ad calling mw.user.options.set, good question. That call was added in d665b46cb by @kostajh, with "call mw.user.options.set so the setPreset change takes immediate effect" as the comment. I'm not sure why would that be needed, AFAICS, mw.user.options.get is only called when the non-Vue mentee overview module is inicialized, and then it keeps its state internally. I don't think calling or not calling mw.user.options.set would make any difference.

I can't remember now, but I think it may have been needed for the QUnit test.

Etonkovidova subscribed.

Checked in testwiki wmf.7- works as expected.