Last modified: 2014-03-12 23:46:44 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T51259, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 49259 - Patrolling through API is not possible any more due to the removal of rcid
Patrolling through API is not possible any more due to the removal of rcid
Status: NEW
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
1.22.0
All All
: Low minor (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-06 16:26 UTC by kipod
Modified: 2014-03-12 23:46 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description kipod 2013-06-06 16:26:50 UTC
so change 1e24733cafbfdc51b7a5a9a1c1baf948e760fe1a removed "rcid" from recent changes page.

rcid is needed for patrolling (i.e., marking a change "patrolled") through the API.

The API does not provide a way to translate edit id to rcid, or to mark change as "patrolled" using edit id (usually appears as "diff=" or "oldid=").

This basically completely invalidate several very useful patrolling tools, on which our community heavily depends. (specifically, [[he:Mediawiki:Gadget-rcPatrol.js]]

There is no known (to me) way of querying the rcid of an edit through the API, which means i can't really think of a way to execute patrolling directly from recentchanges/wathclist pages.

to the best of my understanding, each of the following will allow me to fix the tool. i listed them in descending order of "desirability":

(priority #1: this will be the best solution for me)
* teach action=patrol API call to optionally accept curid (which still appears in recentchanges page) or edit ID (content of diff=) instead of rcid.


(priority 2)
* bring back rcid to recentchanges and watchlist html pages


(priority #3)
* create new API call to translate either curid or edit ID to rcid


this is somewhat urgent, as the patroller community in hewiki do depend on these tools, so this regression which disabled them significantly hampers the patrolling activity on hewiki. i'm marking this as "hipri" bug (i usually don't do that, and leave prioritization to the developers). 


if someone can suggest a workaround that will allow patrolling from the recentchanges page with the current mw version (1.22wmf5), i'll be extremely grateful.

peace.
Comment 1 kipod 2013-06-06 16:30:53 UTC
link to change in previous message does not work - maybe bacause i left the leading "I" out of it?

let's try again:

I1e24733cafbfdc51b7a5a9a1c1baf948e760fe1a


peace.
Comment 2 kipod 2013-06-06 21:12:09 UTC
(In reply to comment #0)
> (priority #1: this will be the best solution for me)
> * teach action=patrol API call to optionally accept curid (which still
> appears
> in recentchanges page) or edit ID (content of diff=) instead of rcid.
> if someone can suggest a workaround that will allow patrolling from the
> recentchanges page with the current mw version (1.22wmf5), i'll be extremely
> grateful.
> 
> peace.

not 100% sure what "curid" is, but assuming it's the last "recent change" id for this page (which means the same "curid" can appear for more than one change), then using curid is not an option. using commit-id will still work for me.

peace.
Comment 3 Marius Hoch 2013-06-06 23:55:21 UTC
(In reply to comment #2)
> not 100% sure what "curid" is, but assuming it's the last "recent change" id
> for this page (which means the same "curid" can appear for more than one
> change), then using curid is not an option.
curid is the page id.

(In reply to comment #2)
> using commit-id will still work for me.
What you mean is the revision id. I've just implemented that and am going to upload it after some testing tomorrow as it seems to be the sanest way to resolve this bug.
Comment 4 kipod 2013-06-07 00:14:02 UTC
thanks you much. 
i agree with your assessment: i have no desire to see "rcid" - from userland POV, revision id is the only thing that counts, and teaching the API to execute the "patrol" action using revision id is the sanest solution in my mind also (and that's why it's listed in comment #0 as the "most desirable solution").

you are correct, i did mean "revision id". 
this can be read from the content of the "diff=" in the "prev" link on "recentchanges" and "wathclist" pages.

when you say "upload", does this mean deploy to wikis?

peace.
Comment 5 Marius Hoch 2013-06-07 00:16:45 UTC
(In reply to comment #4)
> when you say "upload", does this mean deploy to wikis?
No, it means that I upload it to gerrit (https://gerrit.wikimedia.org) so that it can be reviewed by other developers and later on be merged. https://www.mediawiki.org/wiki/Gerrit
Comment 6 db [inactive,noenotif] 2013-06-08 08:01:15 UTC
It is still possible to get the id through the api, see action=query&list=recentchanges&rcprop=ids, but it is hard to find the corresponding id for one title in one request, so the idea of allowing a revision id to be used in action=patrol is the better way.
Comment 7 Marius Hoch 2013-06-09 00:56:01 UTC
https://gerrit.wikimedia.org/r/67624
Comment 8 kipod 2013-06-10 21:00:17 UTC
Thanks. There is one more thing, though:
For a change in existing page, the revid is present as the parameter to the "diff=" field of the "prev" and "curr" fields in Special:RecentChanges.

However, for new pages, the revid is not part of the RecentChanges page.

It will be very helpful if we can add this information: strictly speaking it may not exactly belong in this patch, but if one thinks of this patch as "mitigating the negative effects of I1e24733cafbfdc51b7a5a9a1c1baf948e760fe1a", and considering the fact that we *did* have "rcid" for new pages, it make sense to add it.

I think it would be nice to have it (maybe something like "data-revid" attribute to the "abbr.newpage" element?), but the details are not that important - adding the revid *anywhere* on RecentChanges page for "newpage" lines will be good.

Thanks,
Peace.
Comment 9 kipod 2013-06-10 21:15:55 UTC
ooops - i mixed my metaphors. the revid is not in the "curr/prev" links (these belong to action=history, not Special:RecentChanges).

What I meant was "the "diff=" field of the "diff" link". 
for new pages, there is no "diff" link, so we do not have the revid for new pages, and it would be helpful to have it just anywhere on the "new page" line of recentchanges.


Peace.
Comment 10 Marius Hoch 2013-06-11 01:59:13 UTC
The above change has been merged, but I leave this bug open for now:

(In reply to comment #9)
> for new pages, there is no "diff" link, so we do not have the revid for new
> pages, and it would be helpful to have it just anywhere on the "new page"
> line of recentchanges.

I'm not a fan of this kind of workaround. Maybe we should also allow the patrolling api to take page names (only for new page patrol, obviously)?
Comment 11 Andre Klapper 2013-06-13 19:18:43 UTC
(In reply to comment #10)
> The above change has been merged

Thanks Markus! Lowering priority. Feel free to unassign if you don't plan to work on this further, and anybody feel free to update the bug summary to reflect what is left to do.
Comment 12 kipod 2013-06-26 12:21:24 UTC
since the main issue is resolved (and the script that uses it is working again - thanks!). 
i do not expect the little detail that's left unsolved to ever be fixed, and i'm lowering "importance" to "Low/minor".

i will rephrase the problem, in case someone would like to take a shot at it:

======= REPHRASING ==========
in order for us to be able to patrol new pages from "recent changes" special page, we need to have the "revid" of a new page available on "recent changes".
this can be done, e.g., by adding a "data-revid" attribute to one of the elements on the line that describes the new page.
this should be available for both "normal" and "enhanced" recent changes, and it would be best if it's available in exactly the same form on both.
============================

peace.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links