Page MenuHomePhabricator

Log revisions marked as patrolled
Closed, ResolvedPublic

Description

Author: yorianb

Description:
I propose to add a function that will keep a log of all the people who clicked
on "mark as patrolled", so you get a list of who marked which change. This would
be really helpful, on nl.wikipedia sometimes changes are marked as patrolled and
not reverted while the change is incorrect. We would like to find out who do
this. It would be pretty easy to implent, though a new table has to be added (I
don't know whether that is a big obstacle or not). Apart from that there just
has to be a little script when action=markpatrolled that will write the rcid,
oldid, diffid and the title of the article (maybe there is a more efficient way)
and the name of the person that marked as patrolled.

The sooner this function is added, the better :)


Version: unspecified
Severity: enhancement

Details

Reference
bz8621

Event Timeline

bzimport raised the priority of this task from to High.Nov 21 2014, 9:34 PM
bzimport set Reference to bz8621.

venullian wrote:

I would like to support this request. On nl wikipedia we are using this "marked
as patrol" function daily to control vandalism as good as we can. We would like
to know whether recent problems are because of mistakes of regular users (then
we can point them in the right direction) or whether we have vandals walking
around marking as patrolled. So if this feature request could be done, we would
be very grateful.

Venullian (from nl and en wikipedia, amongst others)

bijbeltekst wrote:

I strongly support this proposal. The possibility to mark an edit as patrolled,
helpt a lot at Dutch Wikipedia in the fight against vandalism, but now there seems
to be a vandal, marking vandalism as patrolled all the time.

jeroenvrp wrote:

This is a high priority. There are many great things added to MediaWiki, but
they are not high priority. Because this issue is related to the Dutch language
Wikipedia and not to the English language Wikipedia, doesn't mean this isn't a
high priority. It is!

yorianb wrote:

It also can be done by just adding a new log type. It looks really easy to code.

robchur wrote:

(In reply to comment #4)

It also can be done by just adding a new log type. It looks really easy to code.

I look forward to reviewing your patch, then.

yorianb wrote:

(In reply to comment #5)

(In reply to comment #4)

It also can be done by just adding a new log type. It looks really easy to code.

I look forward to reviewing your patch, then.

I would love to do that, unfortanely, my knowledge of PHP isn't great, I would
probably only offer rubbish.

webboy wrote:

Patch to log who marked revisions as patrolled

This patch changes Article.php and RecentChange.php to log who marked a
revision as patrolled in two new fields in the recentchanges table,
rc_patrolled_by and rc_patrolled_by_text.

This patch DOES NOT include an updater to execute:
ALTER TABLE recentchanges ADD rc_patrolled_by INT( 10 ) UNSIGNED NULL AFTER
rc_patrolled ,
ADD rc_patrolled_by_text VARCHAR( 255 ) CHARACTER SET latin1 COLLATE
latin1_bin NULL AFTER rc_patrolled_by ;

This patch does also not include an update for a special page to show the
information, since I don't know an appropriate place and don't have the time to
make a new special page. The new information can be retrieved from the
Wikimedia Toolserver when needed.

attachment bug8621.patch ignored as obsolete

robchur wrote:

I'd like to point out that logging this information makes no sense unless we
store the patrolled status alongside the revisions somehow in the future. This
is one of the reasons I'm holding off on implementing this; patrolling probably
needs to be rethought in terms of concept and implementation.

jeroenvrp wrote:

Well, I support a rethought of the patrol status, but before this will result in
a new implementation, I strongly advise to use WebBoy's patch or a similar
solution until the new implementation is ready.

robchur wrote:

Sure, we'll commit a patch that doesn't fix the problem.

yorianb wrote:

(In reply to comment #8)

patrolling probably
needs to be rethought in terms of concept and implementation.

Maybe a funny question to ask, but why should this be rethought? It works fine
as it does, except you can't see the patrollers.

wikt.3.connelm wrote:

The major problem I see with &rcid= is that it does not appear everywhere that a
diff (or edited page) does. Also, for any given page/entry/article, there needs
to be a "mark all revisions as patrolled" feature...whether or not you are
arriving from Special:Recentchanges. Well, especially when not. If I review an
entry and clean it up, I should have a button to mark all &rcid='s for it, on
that page - and not have to go back to Special:Recentchanges and dig through
thousands of edits to find the relevant ones. My Javascript
http://en.wiktionary.org/wiki/User:Connel_MacKenzie/patrolled.js whitelisting
thing only goes so far, and I have serious doubts that the anon whitelisting is
even valid! That is, an anonymous user whitelisting /should/ be for either 24
hours or 30 days, not indefinite. I also need to find time to have it work with
"enhanced" recent changes, and add things for marking all "recent" (i.e. the
ones that appear on the immediately current Special:Recentchanges page) edits of
a user or for a page as patrolled.

yorianb wrote:

(In reply to comment #12)

The major problem I see with &rcid= is that it does not appear everywhere that a
diff (or edited page) does. Also, for any given page/entry/article, there needs
to be a "mark all revisions as patrolled" feature...whether or not you are
arriving from Special:Recentchanges. Well, especially when not. If I review an
entry and clean it up, I should have a button to mark all &rcid='s for it, on
that page - and not have to go back to Special:Recentchanges and dig through
thousands of edits to find the relevant ones. My Javascript
http://en.wiktionary.org/wiki/User:Connel_MacKenzie/patrolled.js whitelisting
thing only goes so far, and I have serious doubts that the anon whitelisting is
even valid! That is, an anonymous user whitelisting /should/ be for either 24
hours or 30 days, not indefinite. I also need to find time to have it work with
"enhanced" recent changes, and add things for marking all "recent" (i.e. the
ones that appear on the immediately current Special:Recentchanges page) edits of
a user or for a page as patrolled.

That are great ideas! But I think we should focus on the short run, we -need- to
log the markers and we need it as fast as possible, and as soon as possible. We
can do other enhancements later.

yorianb wrote:

(In reply to comment #10)

Sure, we'll commit a patch that doesn't fix the problem.

And why doesn't it fix the problem?

We really need more information here on what's being requested.

Is the information of who patrolled what public or private?
Is anyone allowed to look at the log?
Is the public Special:Log interface an appropriate and desirable a place for
reviewing this data, or is something else required?
eg something like CheckUser?
Is the log meant to be permanent? (The patrol tags themselves are not; the data
expires along with recentchanges info itself.)

wikt.3.connelm wrote:

Oh, sorry - I didn't realize you have patrolled edits allowed for *all*
registered accounts. On en.wiktionary.org, we only allow sysops to patrol.

So you'll just query on the toolserver whenever you need to block an account?
Sounds...ineffective. The vandals will just create new accounts immediately.

yorianb wrote:

(In reply to comment #15)

We really need more information here on what's being requested.

Is the information of who patrolled what public or private?
Is anyone allowed to look at the log?
Is the public Special:Log interface an appropriate and desirable a place for
reviewing this data, or is something else required?
eg something like CheckUser?
Is the log meant to be permanent? (The patrol tags themselves are not; the data
expires along with recentchanges info itself.)

Everyone should be able to see it, there doesn't need to be a restriction. I
don't care what it looks like, it can be a flat textfile if that's easy to
implent ;) But a Special:Log interface would be nice (and easy to implent?). I
believe recentchanges data lasts for a month? I think that's quite enough.

You see, right now the only thing nl.wiki wants is a solution for the problem
and we believe the problem is urgent. So right now we don't care how it looks or
how it works, we just want to see who the patrollers are and fix the problem as
soon as possible. I understand that Mediawiki doesn't want to have quick fixes,
but I think a quick, easy solution for a short while is the best solution right
now. After that we can start thinking about a better solution.

webboy wrote:

Complete patch to log who marked revisions as patrolled

This time including an updater, a new special page and dutch translation.

Attached:

robchur wrote:

Use the existing logging framework so that all logs are presented in the same
location. You can avoid having to update the schema.

Your patch contains several deprecated code techniques; the SpecialPage in
particular.

webboy wrote:

(In reply to comment #19)

Use the existing logging framework so that all logs are presented in the same
location. You can avoid having to update the schema.

There is no need to keep the data for more then a month. It will just spoil the
logging table and Special:Log page since the Dutch Wikipedia has about 1200
edits per day to patrol.

Your patch contains several deprecated code techniques; the SpecialPage in
particular.

I just copied most code from ChangesList.php and SpecialRecentchangeslinked.php.
Should I wrap the wfSpecialPatrolledChanges() function in a new
SpecialPatrolledChanges class? What else is deprecated?

yorianb wrote:

(In reply to comment #21)

Fixed in r19341.

Thanks!

jeroenvrp wrote:

Great news! Thank you Rob and WebBoy!

venullian wrote:

Thank you very much! This is great news!

wikt.3.connelm wrote:

After almost 24 hours, I see about 2,900 log entries for en.wiktionary. Is it
just me, or does this seem like an excessive amount of logging?