**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. T17936 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 (T19215). 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 (T18604) 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?
--------------------------
**See Also**:
* {T49415}
* {T27799}