Last modified: 2014-01-17 01:32:01 UTC
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?
I agree, let's put the patrol flag (and the bot flag too, for that matter) in the revisions table as well.
(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.
(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).
Created attachment 5768 [details] 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.
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
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.
