Page MenuHomePhabricator

Allow sysadmins to make an empty edit to a configuration provider
Closed, ResolvedPublic3 Estimated Story Points

Description

User story & summary:

As a system administrator, I want to be able to make null edit, so that users viewing a page history are not confused by seeing unrelated changes.

Background & research:

With Special:EditGrowthConfig, additions of new form fields didn't take an effect in the underlying JSON files immediately (MediaWiki:GrowthExperimentsConfig.json and MediaWiki:NewcomerTasks.json). Instead, they were visible only after someone went to Special:EditGrowthConfig and submitted. Only then the editor realised there are new fields, and saved them to the JSON file.

This is far from ideal, as it generates confusion. An admin goes to Special:EditGrowthConfig wanting to make a certain change, but because there were fields added in the meantime, the diff would end up containing more changes than just what the admin wanted to do. This was reported to the Growth team in the past as T351008: Special:EditGrowthConfig makes unrelated edits.

We implemented a migrations system, which should help avoid certain such cases. Another action we can take to reduce chances of T351008 repeating is to make an empty edit to all providers from a system account. If what the editor would generate (with no changes made in the UI) is different than what is saved, then the empty edit would be recorded in the history using a maintenance account, rather than from the next editing admin's account.

Implementation-wise, this task would be resolved via some maintenance script. We probably do not need to create a new script for this – instead, it can be done as part of the script that will be created in T357535: Community configuration: Create a maintenance script for configuration changes.

Acceptance Criteria:
  • Sysadmins have a maintenance script that can invoke an empty edit to the configuration

Event Timeline

KStoller-WMF moved this task from Inbox to Up Next (estimated tasks) on the Growth-Team board.

Let's estimate this after the work of the parent task has started to have better understanding of the changes needed.

KStoller-WMF set the point value for this task to 3.Oct 15 2024, 4:19 PM

Change #1082094 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/extensions/CommunityConfiguration@master] feat(ChangeWikiConfig): allow saving null-edit

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

Change #1082094 merged by jenkins-bot:

[mediawiki/extensions/CommunityConfiguration@master] feat(ChangeWikiConfig): allow saving null-edit

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

QA Note: The way to try this out, is by manually deleting some of the data from .json page (not via the form, but via editing the MediaWiki:Something.json page directly), or finding a page that is already incomplete, like https://cs.wikipedia.beta.wmflabs.org/wiki/MediaWiki:GrowthExperimentsHomepage.json .

Then running the script for that extension+provider. Adding --dry-run should show the change, and without that option it should actually be written out.

@Michael - it seems that I cannot correctly supply the provider's name for the script. I thought that the field's name is a provider's name, e.g.EHomepageSuggestedEditsIntroLinks - but it's not correct.
Where the providers' names are stored? I couldn't find them in extension.json, but probably I just didn't know how to look.

@Michael - it seems that I cannot correctly supply the provider's name for the script. I thought that the field's name is a provider's name, e.g.EHomepageSuggestedEditsIntroLinks - but it's not correct.
Where the providers' names are stored? I couldn't find them in extension.json, but probably I just didn't know how to look.

In extension.json some of them are under attributes -> CommunityConfiguration -> Providers. Another way to find some of them would be to go their form and look at the URL. For example, on Special:CommunityConfiguration/GrowthSuggestedEdits the name of the provider is GrowthSuggestedEdits.

Thank you, @Michael! Checked in beta for different fields/
providers and for null edits - all changes properly saved and displayed; the diffs shows only relevant changes.