Better integration of patrol feature (rc_patrolled, rc_bot in revision: rv_bot, rv_patrolled)
OpenPublic

Description

Author: matthew.britton

Description:
Now that patrolling is part of MediaWiki core, it should really be better integrated than it is. However it seems the database structure does not allow it.

This creates usability issues. Unlike other actions such as editing, deleting and moving, users can only patrol a page if they follow a link to it from the new pages log. Bug 15936 asked for the links to always be visible, but was reverted.

Querying patrol status is also difficult. It was added to the user contributions API listing, but is currently producing a fatal error on en.wikipedia and will likely be removed (bug 17215). So you can't ask which of a user's contributions are un-patrolled, and other information like whether a page's last edit is patrolled requires scraping the UI instead.

The situation is even worse for external tools. A revision or page can (thanks to recent fixes) now be patrolled with reasonable ease if the client happened to catch its entry in recent-changes or the IRC recent-changes feed. However it is impossible to patrol a new page if all you know is its name, page id and/or revision id. The IRC feed now (bug 16604) shows patrol log entries, but the API's recent-changes query does not. There is an API query to retrieve rcid of a page/edit from recent-changes, but it basically scans the whole recent-changes table looking for it, which means if you happen to ask for one that's near the back (or not present at all) of en.wikipedia's recent changes, you get a query that takes several minutes to run.

To summarize, patrol status should be as easily manipulated as, say, whether a revision is marked as minor, but isn't. I don't really have a clue how these things work, but would it be better if patrol status was an attribute of revisions rather than recent-changes?


Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=47415
https://bugzilla.wikimedia.org/show_bug.cgi?id=25799

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz17237.
bzimport created this task.Via LegacyJan 29 2009, 11:00 PM
Catrope added a comment.Via ConduitJan 29 2009, 11:04 PM

I agree, let's put the patrol flag (and the bot flag too, for that matter) in the revisions table as well.

bzimport added a comment.Via ConduitJan 29 2009, 11:29 PM

matthew.britton wrote:

(In reply to comment #1)

I agree, let's put the patrol flag (and the bot flag too, for that matter) in
the revisions table as well.

Bot flag kind of makes sense where it is, given that its purpose (at least its original purpose) is to keep bulk edits out of recentchanges. (The somewhat fuzzy relationship between bot accounts and bot edits always confuses me.) Though having said that, I guess patrol flag kind of makes sense where it is too, if its purpose is to review new edits.

I just looked at bug 17215 again and there's talk of adding an index, something I have only a very vague understanding of, but I assume has the same intention of making revision/recentchanges queries easier. I guess that would be easier than a schema change.

Catrope added a comment.Via ConduitJan 30 2009, 11:37 AM

(In reply to comment #2)

I just looked at bug 17215 again and there's talk of adding an index, something
I have only a very vague understanding of, but I assume has the same intention
of making revision/recentchanges queries easier. I guess that would be easier
than a schema change.

The basic idea of that index is that it makes it possible to retrieve the recentchanges entry for a certain revision efficiently, which semi-fixes this. Adding the bot and patrol flags to the revisions table makes more sense IMO, since, as Aryeh said on that bug, recentchanges serves just to summarize other tables, and as such should not contain 'new' information (i.e. information that isn't present in any other table).

Catrope added a comment.Via ConduitFeb 2 2009, 3:26 PM

Created attachment 5768
Proposed patch

Attached patch that:

  • adds the rev_bot and rev_patrolled fields to the revision table
  • adds the populateRevBotPatrolled.php script that populates them (automatically run from update.php)
  • adds support for the fields in the Revision class
    • deprecates isUnpatrolled() which seems to be unused in core
  • sets rev_bot and rev_patrolled appropriately when creating new revision entries

This patch doesn't synchronize rev_bot and rc_bot for new moves, deletions and protections, because the interface for moving/deleting/protecting with the bot flag sucks (I intend to fix that) and doesn't sync them for old ones either because the recentchanges entry and the associated null revision aren't linked in any way (rc_this_oldid == 0 for these entries). It also doesn't use the newly added fields in any way.

I intend to address the concerns mentioned above in a new patch, but in the meantime, some review would be nice.

Attached: 17237.patch

Krinkle added a comment.Via ConduitNov 16 2010, 9:14 PM

One thing to not forget is wgRCMaxAge, the patrols expire after wgRCMaxAge. If moving this into recentchanges:

  • the rev_patrolled needs to be NULL'ed if 0 after wgRCMaxAge (or introduce a new variable wgMaxPatrolAge which by default is equal to wgRCMaxAge)
  • when patrolling an edit the markpatrolled action need to update both revision and recentchanges
Krinkle added a comment.EditedVia ConduitMay 25 2013, 1:53 PM

Progress from Amsterdam Hackathon 2013:

  • Move rc_patrolled and rc_bot from recentchanges to revision.
  • Make rev_patrolled 0/1/2 instead of 0/1. The value 2 would represent autopatrolled.
  • We no longer need logging for autopatrol because author/timestamp is the same as the author. this solves two bugs:
  • T27799: Allow Special:Log to show separate autopatrol from human patrol
  • T49415: Logging of autopatrol does not scale for Wikidata

+1 from Daniel Kinzler (@daniel), Tim Starling (@tstarling).

Ricordisamoa added a subscriber: Ricordisamoa.Via WebDec 27 2014, 5:45 AM

Progress from Amsterdam Hackathon 2013:

  • Move rc_patrolled and rc_bot from recentchanges to revision.
  • Make rev_patrolled 0/1/2 instead of 0/1. The value 2 would represent autopatrolled.
  • We no longer need logging for autopatrol because author/timestamp is the same as the author. this solves two bugs:

Bug 25799 (Allow Special:Log to show separate autopatrol from human patrol)
BUg 47415 (Logging of autopatrol does not scale for Wikidata)

+1 from Daniel Kinzler, Tim Starling and Timo Tijhof.

Any updates?

Ricordisamoa awarded a token.Via WebDec 27 2014, 5:45 AM
Krinkle added a comment.Via WebJan 9 2015, 3:08 AM
This comment was removed by Krinkle.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.