Page MenuHomeMiraheze

Problem with previously-autopatrolled revisions of administrators or autopatrollers become unpatrolled upon losing that status
Closed, DeclinedPublic


Problem: This is seemingly a long-standing bug with the patrolled/unpatrolled revisions that occurs when a user with autopatrol user right (i.e., autopatrolled users and administrators) loses that status. Their previously automatically patrolled, and possibly their manually patrolled revisions prior to them gaining that status (sorry, can't remember exactly on this point), become unpatrolled.

What should happen: The previously automatically patrolled, or manually patrolled, revisions, should remain as patrolled, consistent with what occurs on the Wikimedia-owned wikis.

Reproducable? Yes, I have verified this on the revisions of User:Melan, User:Examknow, User:Covid-19, User:Artix Kreiger, et al., on Public Test Wiki (one example is at these revisions), which @RhinosF1 has now verified independently. Also reproducable on any wiki, really, including Meta, Commons, and more

System Information:
Vivaldi 3.1.1929.45 (Stable channel) (64-bit)
Revision 1eb3263017ed42270818939fbff241845938a81f
OS Windows 10 OS Version 1909 (Build 18363.959)
JavaScript V8
Flash C:\WINDOWS\system32\Macromed\Flash\pepflashplayer64_32_0_0_387.dll
User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.119 Safari/537.36
Command Line "C:\Users\Wylie\AppData\Local\Vivaldi\Application\vivaldi.exe" --flag-switches-begin --flag-switches-end --enable-audio-service-sandbox --ppapi-flash-path="C:\WINDOWS\system32\Macromed\Flash\pepflashplayer64_32_0_0_387.dll" --save-page-as-mhtml
Executable Path C:\Users\Wylie\AppData\Local\Vivaldi\Application\vivaldi.exe
Profile Path C:\Users\Wylie\AppData\Local\Vivaldi\User Data\Default

Event Timeline

Dmehus triaged this task as High priority.Jul 20 2020, 16:39
Dmehus created this task.

This is an MW bug, not an extension bug

@AmandaCath I wasn't sure whether it was a MediaWiki bug (or rather, Miraheze's deployed version of MediaWiki) or a problem with an extension (i.e., FlaggedRevs, but I think that's the extension that Wikipedia uses for Special:PendingChanges and is commonly not installed on most wikis, right?).

Reception123 lowered the priority of this task from High to Normal.Jul 22 2020, 06:06

@RhinosF1 and @Reception123, do we know this problem occurs on non-Miraheze wikis, though? English Wikipedia automatically marks all the revisions, other than new pages, of autoconfirmed users as patrolled, so we won't be able to check that there. A good place to potentially check on this might be Wikimedia's Meta Wiki, if we know any former administrators who no longer have `autopatrolled``` status.

It doesn't seem that this is happening on the WMF, example (the user was locked and was not autopatrolled at the time of that change)

Reception123 claimed this task.
Reception123 added a project: Upstream.

John has investigated this issue and hasn't found what could be causing it here, therefore we find that it is best to create an upstream task for this ( therefore declining this task as it is seemingly not something we can resolve.