Page MenuHomeMiraheze
Create Task
Maniphest T5940

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

Description

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 8.3.110.13
Flash 32.0.0.387 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

Related Objects

Event Timeline

Dmehus triaged this task as High priority.Jul 20 2020, 16:39
Dmehus created this task.
Herald added subscribers: Void, Reception123, NDKilla. · View Herald TranscriptJul 20 2020, 16:39
Dmehus updated the task description. (Show Details)Jul 20 2020, 16:41
Dmehus moved this task from Backlog to Deployed Extension Bugs on the Extensions board.
Sario528 subscribed.Jul 20 2020, 16:48
AmandaCath edited projects, added MediaWiki; removed Extensions.Jul 20 2020, 18:05

This is an MW bug, not an extension bug

AmandaCath moved this task from Backlog to Bugs on the MediaWiki board.Jul 20 2020, 18:05
Dmehus added a comment.EditedJul 20 2020, 19:19

@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
Reception123 added a comment.Jul 24 2020, 05:17

@RhinosF1 Should we file upstream?

RhinosF1 added a comment.Jul 24 2020, 05:17
In T5940#116400, @Reception123 wrote:

@RhinosF1 Should we file upstream?

Yes

Dmehus added a comment.Jul 24 2020, 05:49

@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.

Reception123 added a comment.EditedJul 30 2020, 08:28

It doesn't seem that this is happening on the WMF, example https://meta.wikimedia.org/w/index.php?title=Steward_requests/Username_changes&diff=prev&oldid=17154345 (the user was locked and was not autopatrolled at the time of that change)

Reception123 closed this task as Declined.Jul 30 2020, 15:57
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 (https://phabricator.wikimedia.org/T259265) therefore declining this task as it is seemingly not something we can resolve.

Dmehus mentioned this in T6392: Problem with Previously Manually Patrolled Revisions Now Unpatrolled on TestWiki.Nov 2 2020, 00:55