I recently came back to this and I'm no longer sure if I can implement it that easily. The problem is T259103: Run reverted tag update job only after the edit is approved – there is now a complex mechanism for approving the reverted tag which depends on the patrolling subsystem, user's rights and possibly extensions. To properly emulate all that behavior in a script would be... a very significant challenge, if not impossible, given that there's no detailed record of patrol actions.

In T231355#5600294, Anomie wrote:

There's no way for us to easily find "the revisions that got reverted", as that's not recorded anywhere. If that's what's wanted, we'll need to push back on it.

Oh, I've just noticed T234299: Links like "[[:/y/]]" and "[[/y̫/]]" displayed incorrectly in preview... The above comment should have been posted there.

I think this is related to this task: links like [[:/dev/zero]] should point to a page called /dev/zero in the main namespace, not to a subpage of the current page. This is not respected by Parsoid, though, and links like these show up as linking to a subpage.

In T265312#6572551, @Quiddity wrote:

For the user-notice entry in Tech News, is this accurate? If not, a rewritten or simpler/clearer draft would be appreciated :)

In T265312#6568298, @DannyS712 wrote:

Should a maintenance script be added for removing the tag from old null revisions?

Hmmm, haven't thought of that.

In T154637#6513557, @Orlodrim wrote:

Up to you. I think this specific case case could be resolved without text diffing with the following algorithm: among the revisions newly marked as "manually reverted" (excluding those that already have the tag), in case several ones have the same sha1, only notify the user who did the oldest one.

Huh, that's actually pretty smart, haven't thought of that. I think I'll have a go at implementing it, after some experimentation with pencil and paper. :)

In T154637#6510822, @Orlodrim wrote:

End result: Edit 4 is marked as a manual revert, while edits 1, 2 and 3 are marked as reverted. It is good to notify BadUser about that, but GoodUser will be confused if they get a notification that their edit was reverted by GoodAndMoreCarefulUser.

Right, so I've thought about it a bit and something like a should_notify parameter would be rather hard to implement. We would have to modify the appropriate API module and then somehow push that information through the really ugly MediaWiki editing pipeline (EditPage and PageUpdater especially) for the extension to even have a chance of noticing the parameter. That seems like a lot of work. Alternatively I can think of a few very, very ugly hacks that would not pass code review.

Just a heads-up that there is an extension that kind of solves this issue – AdvancedBacklinks. It is however a bit messy and requires two custom hooks in the parser that will never be merged into core (see T232305). It also means that it won't simply port to Parsoid (though I'll later investigate whether that can be done).

In T154637#6496030, @Proc wrote:

I think one idea may be a way to mark a particular edit with something like should_notify: true (for bots only), creating an opt-in system (by default, bot edits would not notify). I don't know how practical that is, in terms of developer effort, however.

Hmm.

Making the notification depend on the status would at least be consistent with 1 and 2, whereas using the bot flag for the edit would introduce yet another special way of treating bots.

In T154637#6490416, @kostajh wrote:

Maybe we shouldn't apply the manual revert tag at all for bot edits, then?

In T154637#6489777, @Orlodrim wrote:

I noticed some cases where I don't think the manual edit tag should be applied, and in particular where triggering a notification will probably annoy users. I wrote the details in T256001#6489764, although I'm not sure which bug is the most appropriate to discuss this.

In T248775#6486051, @srishakatux wrote:

Google-Summer-of-Code (2020) is over! I believe you have already documented your project here https://www.mediawiki.org/wiki/Google_Summer_of_Code/Past_projects#2020. If not, I would encourage you to do so.

Haven't done that yet. I'll do it soon. :)

I'm marking this as resolved, as the rough goals outlined here have been met.

• The PageSaveComplete hook passes the EditResult object to extensions that indicates whether the edit was reverted and what kind of revert it was.
• Manual reverts are detected automatically and marked appropriately.
• Reverted revisions can be either obtained from the EditResult object of a revert or by looking at change tags in the database. mw-reverted tag indicates that a revision was reverted.

FlaggedRevs implements this, but I would like to at least implement this in Approved Revs too before closing this task.

Should we port it back to older wmf branches? Or is there no need to?

Oh gee, my fault… will look into this ASAP.

In T162005#6444698, @matmarex wrote:

I don't remember how upload campaigns work any more, it's possible that these can still be used by the campaign definitions on Commons?

In T162005#6442675, @Ostrzyciel wrote:

Uhhh… are these wm-* messages still used somewhere? I can't find any code referencing them. I also had a look at Commons and they are not using these variants of CC licenses anymore, including campaigns (I think) so… can we just remove them?

I was wrong that the country variants are not used, sorry, temporary blindness :) These licenses are still used, but they use different messages now, since… 2011: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/UploadWizard/+/90e54f3abffc9c060e0740fac37f61267ed53249%5E%21/

Uhhh… are these wm-* messages still used somewhere? I can't find any code referencing them. I also had a look at Commons and they are not using these variants of CC licenses anymore, including campaigns (I think) so… can we just remove them?

Not sure if making this feature into a separate action is a good idea. There are three types of reverts out there (undo, rollback, manual) and this would just support one of these, which is rather incomplete. I'd rather propose for AbuseFilter to somehow receive the EditResult object related to the edit, so that all kinds of reverts are treated properly. Then the revert type could be made into an AbuseFilter variable, along with other information about the revert. This would require some kind of overhaul on the core side of things, though, see T159725.

I posted part of the manual, the rest has to wait for the relevant changes to be merged.

Status update: I have a draft of the manual page with most of the content I wanted to include: https://www.mediawiki.org/wiki/User:Ostrzyciel/GSoC_2020/manual
It mostly just needs some polishing now.

In T259014#6391152, @Mathglot wrote:

Is the tag meant to remember the fact that someone clicked a particular button, or that the content changed in a particular way? It seems to me it does the former, when possibly it should do the latter, and the disconnect between the two opens the gate for vandalism and/or misunderstanding.

In T259014#6375617, @Johan wrote:

@Ostrzyciel I added a draft to https://meta.wikimedia.org/wiki/Tech/News/2020/34 based on your text but with somewhat simplified language. Looks OK? I'm correct in understanding it's part of this week's train?

Thanks :)

In T259014#6350405, @Quiddity wrote:

If I understand correctly, this is not yet ready for announcement. For once it is ready, please could you provide an explanatory entry for TechNews. Just 1-2 sentences explaining what the change is. Thanks!

In T252518#6350596, @Catrope wrote:

Do you have a particular extension in mind that would use this hook?

In T259103#6347304, @Catrope wrote:

How would this work on wikis where $wgUseRCPatrol = false;? On e.g. enwiki, edit patrolling isn't used, and FlaggedRevs is only used on some pages, so most edits are never patrolled/reviewed (and can't be)

Oooh, okay, nvm, I didn't see that. My bad. :)

In T259014#6342360, @DannyS712 wrote:

Per commit message, THIS CHANGES THE BEHAVIOR OF EditPage IN A NOTICABLE MANNER.

In T259014#6340195, @DannyS712 wrote:

...also, could allow the tag to be removed manually (and perhaps added manually in case it was accidentally removed incorrectly)? Would require custom handling in the ChangeTags class to allow for this with a system tag