Allow applications to search RecentChanges by logaction. E.g., en.wikipedia.org/w/api.php?action=query&list=recentchanges&rcaction=delete|restore to retrieve only the page deletion and restoration recent changes.
Version: 1.22.0
Severity: enhancement
Note that as described this doesn't make a whole lot of sense. If such a parameter were added, it would be roughly equivalent to the letype and/or leaction parameters to list=logevents. If this is implemented, probably both rclogtype and rclogaction should be added with behavior the same as the corresponding logevents parameters.
Note this would probably require indexes added on the rc_log_type and rc_log_action columns, and analysis of which other parameters may not be used at the same time to prevent poor query performance.
Bug 55377 may have some of the same issues, BTW.
What I was hoping to do was make it so that applications could pull both page creations (rctype=new) and page deletions/restorations (rctype=log&rcaction=delete|restore) in one API pull rather than having to do two separate pulls (one to list=logevents and the other to list=recentchanges). The idea would be to reduce server load, since there could end up being a lot of these pulls, depending on how widely the extension that does the pulls gets used.
Specifically, this is for the rewrite of the RPED extension (to be renamed InterwikiExistence), which will use periodic API pulls to keep the local list of existent Wikipedia pages mostly in sync with Wikipedia's. That way, it will be possible to have existence detection (i.e. red/blue interwiki links) for interwiki links such as [[wikipedia:Foo]]. This is sort of like bug 11, but it would be used on wikis that, being outside of the WMF farm, can't use the WMF backend and therefore have to rely on the API. The code for the API pulling is similar to what you see in the InterwikiMap extension, except the API pulling would probably need to be more frequent to keep the data reasonably up-to-date, since page creations, deletions and restorations occur more frequently than changes to the interwiki table.
So my question would be, is it more efficient to implement this raction capability and thereby cut down on API pulls, or would it not be worth the expense in terms of database load? The other option is to have a bot get the data from the recentchanges IRC feed, but not all wikis are able to run a bot 24/7.