Page MenuHomePhabricator

Patrolling through API is not possible any more due to the removal of rcid
Closed, ResolvedPublic

Description

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.


Version: 1.22.0
Severity: minor

Details

Reference
bz49259

Event Timeline

bzimport raised the priority of this task from to Low.
bzimport set Reference to bz49259.
bzimport added a subscriber: Unknown Object (MLST).
Kipod created this task.Jun 6 2013, 4:26 PM
Kipod added a comment.Jun 6 2013, 4:30 PM

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.

Kipod added a comment.Jun 6 2013, 9:12 PM

(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.

hoo added a comment.Jun 6 2013, 11:55 PM

(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.

Kipod added a comment.Jun 7 2013, 12:14 AM

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.

hoo added a comment.Jun 7 2013, 12:16 AM

(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

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.

Kipod added a comment.Jun 10 2013, 9:00 PM

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.

Kipod added a comment.Jun 10 2013, 9:15 PM

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.

hoo added a comment.Jun 11 2013, 1:59 AM

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)?

(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.

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.

Anomie closed this task as Resolved.Feb 19 2015, 7:00 PM
Anomie set Security to None.

Bug as stated is resolved. If you want to request new features, please file a new bug against the proper projects.