Page MenuHomePhabricator

Provide a gadget migration script
Open, Needs TriagePublic

Description

Currently, gadgets are identified by page name. Hence, when a gadget is renamed, the user preferences to have enabled this gadget is lost.

A feature to migrate a gadget would then be welcome to perform the following tasks:

  1. Gets the list of users having gadget A enabled
  2. Enable gadget B for these users
  3. Disable gadget A for these users

Event Timeline

Bump :) Is there someone able to do it? Is the task easy or not?

You need to write a new maintenance script.

You've some example at https://github.com/wikimedia/mediawiki-extensions-WikimediaMaintenance/

If you wish to contribute, you can write and commit it directly to the Gadgets repository,
as it will be useful for other projects too, not only Wikimedia.

As the extension doesn't currently have any maintenance script, you can create a maintenance/ folder to put yours in.

Od1n added a comment.Apr 30 2018, 1:13 AM

Thank you for these explanations :)

Though, I don't plan learning a whole new topic, and which would be useful to me only for this occasion, if there is someone else already able to write the script in less than 2 minutes...

DannyS712 added a project: Core Platform Team.
DannyS712 added a subscriber: DannyS712.

So I started looking into writing this, and realized that it might make more sense to create a general script for renaming any user preference, since gadget settings are stored as user preferences.

Currently, initUserPreferences provides a method to duplicate the value of one preference into another, while cleanupPreferences provides some framework for deleting preferences. Given that the preferences should still work while being renamed (i.e. both right before and right after renaming the gadget), a workflow like

  1. initUserPreferencs for the new name, based on the old
  2. Rename the gadget on wiki
  3. Delete old preferences

would be ideal.

In its current form, cleanupPreferences does not affect any gadgets, since GadgetHooks::onDeleteUnknownPreferences adds $where[] = 'up_property NOT' . $db->buildLike( 'gadget-', $db->anyString() );

Tagging Core Platform Team, which is responsible for the database schema, as a request to review the following feature: Addition of a new maintenance script, or a new option for cleanupPreferences, to trigger removal of all rows regarding a specific preference setting (e.g. --removepreference=gadget-foo for this use case)

Restricted Application added a project: User-DannyS712. · View Herald TranscriptNov 20 2019, 2:22 AM
DannyS712 moved this task from Unsorted to Next on the User-DannyS712 board.Nov 20 2019, 10:17 AM
eprodromou added a subscriber: eprodromou.

@DannyS712 we think it makes more sense to make this a job that runs when the gadget is moved, rather than a maintenance script that has to be run by the system administrator.

Otherwise, lgtm and we'll keep an eye on things as it progresses.

@DannyS712 we think it makes more sense to make this a job that runs when the gadget is moved, rather than a maintenance script that has to be run by the system administrator.

Otherwise, lgtm and we'll keep an eye on things as it progresses.

Wouldn't that lead to the issue noted above about the preferences not working while being migrated?

Change 553443 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/core@master] Add renamePreference.php maintenance script

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

@DannyS712 we think it makes more sense to make this a job that runs when the gadget is moved, rather than a maintenance script that has to be run by the system administrator.

Otherwise, lgtm and we'll keep an eye on things as it progresses.

The patch provided adds a maintenance script that can be used for any preference, not just gadgets. Until I can figure out doing this as a job, its better than nothing.

DannyS712 moved this task from Next to In progress on the User-DannyS712 board.Jan 8 2020, 8:49 PM