Last modified: 2012-09-16 17:39:08 UTC
Hi, I'm currently updating the block state of tens of thousands of open proxies on frwiki. I have to do it one at a time, which is time-consuming. Allowing a multi-user block/unblock or a multi-page protect/unprotect through a single API call (with the same parameters for all items) would be more efficient.
I'd like this aswell. I can imagine stuff like: http://commons.wikimedia.org/w/api.php?action=patrol&rcid=39515|39517|39519&token=123ABC This could for example be used to patrol all edits from a certain page (imagine users making 20 edits, or an edit war whatever). Previously a tool called vPopSpeed took care of this, but that tool's been dead for a long while. Being able to mass-do stuf in the API makes recreating such a tool a lot easier. - Krinkle
(In reply to comment #1) > This could for example be used to patrol all edits from a certain page (imagine > users making 20 edits, or an edit war whatever). Is such a thing really necessary in the first place? Surely it is sufficient to patrol the latest "good" revision to the page and then ignore the others.
(In reply to comment #2) > (In reply to comment #1) > > This could for example be used to patrol all edits from a certain page (imagine > > users making 20 edits, or an edit war whatever). > > Is such a thing really necessary in the first place? Surely it is sufficient to > patrol the latest "good" revision to the page and then ignore the others. Unlike FlaggedRevisions, the RCPatrol-system works different. Not better or worse, but different. Patrolling is per edit, FlaggedRevisions is per page. For two reasons I say no. 1) For example, imagine a trusted user doing a good edit to a page. That would be marked as patrolled, or maybe autopatrolled if it's a sysop. This does not mean the vandalistic edit made 5 minutes earlier is OK. 2) When filtering recent changes as for example "anonymous unpatrolled edits", then earlier edits to pages stay in the list (as they should) so only marking the latest one would not make sense and clutters up that feed all together. But anyhow, I could imagine dozens other examples where batch operations would come in handy and save some work. To loosely quote myself from IRC yesterday: " It would not only save N-times a HTTP request, N-times a loop to check and verify the results for errors and N-times a database query on the server. So it wouldn't just move the loop from the API-user to the server, I think it would erase such a loop alltogether. AFAIK a database query can SELECT and UPDATE multiple items at once." But then again, I'm not thát familiar with the wikimedia backend to know if it would save resources. -- Krinkle
> Not better or worse, but different. Patrolling is per edit, FlaggedRevisions is > per page. Total misconception. FlaggedRevs is always per revision (that's why it is called so), patrolling is page-only on most wikis (except, of course, commons and nl).
(In reply to comment #4) > > Not better or worse, but different. Patrolling is per edit, FlaggedRevisions is > > per page. > > Total misconception. FlaggedRevs is always per revision (that's why it is > called so), patrolling is page-only on most wikis (except, of course, commons > and nl). OK. I phrased it badly. But not a misconception. What I meant is that when the latest revision of page is being marked as sighted/accurate in FlaggedRevisions then, albeit earlier revisions stay marked as draft, that revision will be upfront the stable version. And, afaik, no need to worry about earlier revisions, because this one is marked stable. RCPatrol ("recent changes") is not page-only, you confused it with NPPatrol ("new page"). See also: http://noc.wikimedia.org/conf/InitialiseSettings.php.txt (ctrl-f Find: "patrol") When a page has been NPPatrol'ed it means the creation of it has been patrolled, not any edits after that. At this moment about 50 Wikis have RCPatrol enabled. And RCPatrol is about the edits themselfs, not about the revision/version of that page as a whole. But anyhow, about those batch operations :) -- Krinkle
You should split this in seperate bugs, because it makes it easy to work on. * One for multi-page block/unblock * One for multi-page protect/unprotect * One for multi-page patrol And maybe more bugs for other actions. You can reuse this bug for one of that feature request.
Splitted into seperated bugs: * bug 40275 * bug 40276 * bug 40277
Why is this marked fix?
Sorry, INVALID is a better status.
