Page MenuHomePhabricator

Rollback gives MediaWiki:Alreadyrolled-message, when final diff between revisions is none.
Closed, ResolvedPublic


Author: bugzilla

Issue found on Dawiki -

Recently, I've experienced that I get the MediaWiki:Alreadyrolled-message, when I'm using rollback on edits that, in the end, has no diff.

To clarify: User A adds some content in edit 1, some more content in edit 2 and then removes it all in edit 3.

Thus there is no difference between the article before and after the edits.

I find that I can't just perform a rollback, with the added benefit of marking the edits patrolled, anymore.

This seems to be a regression, as that has been possible before.

I've created a little testpage on, illustrating the above mentioned scenario.


Knud Winckelmann

Version: 1.23.0
Severity: normal
See Also:



Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 2:53 AM
bzimport set Reference to bz62157.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Mar 3 2014, 7:08 PM

bugzilla wrote:

Aha, this seems to be caused by this commit: .

This is a bit unfortunate, patrolling-wise.



As the author of that change, I support WONTFIX.

On de.wp there was the same situation, but not with patrolling. We have the FlaggedRevs installed and in the situation the already rolled revision was marked as "automatically reviewed", which was anonying, because a IP user cannot review his revision. After a look at the code, I found that the 'complete' hook on rollback was fired and FlaggedRevs was storing the review. In my opinion it was the best to avoid fire of the hook to fix the problem at the rought cause, because a null edit rollback is not a succesfully rollback and no extension and core should do anything than, that includes review on FlaggedRevs and patrolling or marking as bot edit in core.

kaare wrote:

It sounds more like dewiki had the opposite problem. If I understand you correctly, dewiki *don't* want rolledback edits to automatically be marked as reviewed, while we (dawiki) *do* want rolledback edits to automatically be marked as patrolled.

The kind of edits described by Knud Winckelmann, are not marked as patrolled after the user removes them. Before the commit, we as patrollers had for years been able to simply hit "rollback" to make all edits by a user automatically be marked as patrolled. After the commit, the patrollers have to load every such edits individually and mark them as patrolled.

I consider this a regression, and ask you to please revert the commit the sooner the better, replacing it with something which supports both patrolling and FlaggedRevs.

It is possible to fix FlaggedRevs to not do that (doing a manual review and log that), but in my opinion it is not the right way, to mark edits as bot or patrol when the rollback is not from the user, which want do that action.

kaare wrote:

Again, this is a regression concerning the patrolling feature, giving patrollers more work and zero benefit. I have no idea what is proper or not for FlaggedRevs, and I don't know what bots have to do with any of this (unless it is somehow related to FlaggedRevs).

Please revert the commit as soon as possible, then figure out how to fix the FlaggedRevs problem without affecting other features.

User with the 'markbotedits' user right are able to mark edits as bot while rollback, than these edits are not shown on the default view of the Recent Changes. In my opinion it is bad, when the rollback of another user gets marked as bot (if requested by the second rollbacker).

I reverted gerrit 109706 with gerrit 117307 to restore the previous behaviour.
This kept the already rolled message on null rollbacks, but should set the patrolling flags on recent changes (also bot flags, if requested).

revert was successfully merged

Should be available with 1.23wmf18, see for the schedule

kaare wrote:

Thanks, Umherirrender.