Page MenuHomePhabricator

Determine if multi-reverted edits still send notifications to all non-IP users who were reverted
Closed, ResolvedPublic


I need help reproducing this. I currently cannot. It might have been fixed in the last month?

As discussed in more detail at there
An editor received a notification for a reversion, but it wasn't their edit which had directly been reverted. Instead, their edit was one of many that had been reverted. Redrose64 explains there that

I imagine that Mild Bill Hiccup used those [history page] radiobuttons to select two non-consecutive edits, then clicked Compare selected revisions, then used the "undo" link at upper right. This doesn't just undo a whole sequence of edits, it also causes a reversion notification to be sent to all non-IP users who made edits in that sequence. This is not new behaviour, but AFAIK has been normal ever since reverts were added to the notifications system.

I've tried to reproduce this at but cannot.

If it has been fixed on purpose, I'll let the editors know.

If it has been changed accidentally, and we switch it back,
or, if it is reproducible,
Then the editors there suggest sending an alternate notification message in those circumstances (which we can file a new task for).

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

When testing in betalabs I could not make 'undo' (rollback) to send revert notificaitons to intermediary editors that made edits between current revision and a revision to which an article was reverted.

(1) The revert in the original edit seems to be done by Twinkle. There might be some different behavior in dealing with notificaitons when Twinkle is involved.

Screen Shot 2016-09-23 at 4.50.38 PM.png (415×1 px, 96 KB)

(2) Repeating the steps in the possible scenario described in the ticket:
a) In 'View history' click the radio button for a revision that you'd like to restore. The revisions are not consecutive; several other revisions are between them.
b) Click on 'Compare selected revisions'
c) The diff page correctly displays the diff between the current revision and the selected revision. Click 'undo'
d) The revisions will be undone (if there are no conflicting edits). And all intermediary revisions will be undone too. The revert notificaitons are not sent.

(3) When from 'View history' page, I 'undo' an individual edit, an author of that edit receives revert notification.

@Etonkovidova , @Quiddity and I just tried reproducing this on beta labs, and we can confirm that a multi-edit revert doesn't notify anyone.

Note, I asked there:

If the behaviour has changed, do you think it should be re-introduced (with the alternate message as suggested above), or is/was this notification behaviour generally not helpful at all and should be removed/left out? Thanks. Quiddity (WMF) (talk) 21:10, 21 September 2016 (UTC)

and the reply was:

On further thought I'd go for the option to remove the new behaviour (if it is new). There are many scenarios but this sort of sequence occurs quite a lot:

           Edit by Vandal A
           Edit by Vandal B
           I revert Vandal B, not spotting what Vandal A did. Vandal B gets an alert
           Vandal B reverts me to reinstate his own vandalism. I get an alert
           Another editor steps in, checks more thoroughly than I did and reverts right back to the condition before edit (1). It seems as if with the present behaviour, vandals A and B, and I, all get alerts (so I have had 2 alerts for my 1 edit).

       For most of us any page we edit probably goes on to our watchlist, at least for a time; and of course any revert can be done "by hand" without using a rollback or undo button, so not triggering an alert at all. Let's keep it simple and say notification only for a direct revert of an immediately preceding edit: Noyster (talk), 22:47, 21 September 2016 (UTC)

Looking at EditPage::getContentObject(), it looks like multi-edit reverts don't set $this->undidRev, and so wpUndidRevision is not propagated to Echo. At first glance it appears that it should have been working this way since December 2013, but there are lots of moving parts so it's hard to be sure.

Thanks both. I will try to determine where this is (or should be) documented, and update as needed.

The given example doesn't involve undos of multiple revisions, which is being worked on in T153570.
The most likely explanation is that the user (mistakenly) undid the edit that undid the first edit, then edited the page, reinstating it in the process.

Based on all the above, and the suggestion from Noyster that "Let's keep it simple and say notification only for a direct revert of an immediately preceding edit" (i.e. the current status), I'm closing this as resolved.
If T153570 changes the situation, then that can be clarified in the docs, at