Last modified: 2014-09-24 01:32:13 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 T45977, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 43977 - Diffs for more than one unpatrolled revision don't have corresponding multi-revision patrolling action
Diffs for more than one unpatrolled revision don't have corresponding multi-r...
Status: RESOLVED DUPLICATE of bug 8697
Product: MediaWiki
Classification: Unclassified
Recent changes (Other open bugs)
1.21.x
All All
: Normal enhancement with 12 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-14 22:56 UTC by Peter Fitzgerald
Modified: 2014-09-24 01:32 UTC (History)
22 users (show)

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


Attachments

Description Peter Fitzgerald 2013-01-14 22:56:35 UTC
Single edits are patrollable (i.e., you can click the diff from special:recentchanges, and in the edit comparison page, there will be a "marked as patrolled link"). But grouped edits, which are achieved when you enable "Use enhanced recent changes (requires JavaScript)" in special:preferences, do not show the "marked as patrolled" link after reaching the edit comparison page. 

Patrolling grouped edits from recentchanges is something we Wikivoyagers got used to in our pre-WMF days, and it would be great to have it back, especially with the vastly increased patrolling workload post-launch.
Comment 1 atsirlin 2013-01-15 20:03:39 UTC
Yes, this feature is highly demanded.
Comment 2 Bartosz Dziewoński 2013-01-15 20:16:39 UTC
Confirming.

This will probably get fixed by I1e24733c when it gets merged.
Comment 3 Bawolff (Brian Wolff) 2013-01-15 20:19:43 UTC
[mid-air collision!]
Interesting. Do you know how this was made to work in the old days (Was there an extension, or is this something that used to work in mediawiki that got broken somewhere along the line and we just didn't notice).

As an aside, when Gerrit change #41196 is finalized, it will fix this issue as a side effect.
Comment 4 Peter Fitzgerald 2013-01-15 20:36:02 UTC
This was a custom hack. We have a lot of demand for it right now because our public launch (with global sitenotice) has attracted about 15-20x the usual edit load. Our 20-30 patrollers are hard at work, but this would make the job a lot easier!
Comment 5 James Heilman 2013-01-15 20:38:22 UTC
Agree with Peter, how long before it can be gotten up and running?
Comment 6 Bawolff (Brian Wolff) 2013-01-15 20:51:40 UTC
(In reply to comment #5)
> Agree with Peter, how long before it can be gotten up and running?

Hmm, I cannot reproduce this on my local wiki.

----

To verify that I understand the issue correctly, when viewing enhanced recentchanges, and there is a group of edits.
*Only the first edit will show the red ! mark for unpatrolled, even if the other edits require being patrolling
*Clicking on the relavent links (The diff to "prev") the other links in the group don't allow you to patrol the revision
?
Comment 7 Peter Fitzgerald 2013-01-15 20:54:44 UTC
This should make it very clear:

http://wts.wikivoyage-old.org/wiki/WtTech:Grouped_edits_not_patrollable
Comment 8 Bawolff (Brian Wolff) 2013-01-15 20:57:57 UTC
Ok, I understand now.

Don't suppose the source code for this is available anywhere.

[So there's not unrealistic expectations, this is probably not going to be fixed super immediately]
Comment 9 Bawolff (Brian Wolff) 2013-01-15 22:41:40 UTC
highly related: bug 8697
Comment 10 Nemo 2013-01-15 23:05:22 UTC
(In reply to comment #9)
> highly related: bug 8697

I can't tell the difference, unless this bug is asking such a link next to the "8 changes | hist" link circled in http://wts.wikivoyage-old.org/wiki/File:Patrolling_grouped_edits.png
That would make it a blocker of bug 14123 comment 6
Comment 11 Cacahuate 2013-01-16 06:22:16 UTC
I'm shocked to realize this isn't a built in feature of MW, and that it was a custom hack on WT? It is so amazingly useful, having to make do without it when we were used to it for so long is majorly painful. Every wiki would benefit so so much from this. I hope you can implement it soon
Comment 12 Dereckson 2013-01-17 19:12:36 UTC
Thank you for your feedback.

Priorities differ from one person to another. I must confess I have a lot of difficulties to see how the lack of a tiny feature in a software could shock you. A software is a work in progress, to improve.

Don't hesitate to open a new bug for any other feature request you would like to find in the future implemented in the software. This is how we improve our product.
Comment 13 Peter Fitzgerald 2013-01-17 20:31:26 UTC
On the flip side, what may seem tiny to some is actually of huge importance for us—we have not been able to coordinate the patrolling effort for just this one reason!
Comment 14 jc8136 2013-01-21 09:39:41 UTC
Hi! This bug causes some major additional work at Wikivoyage. We have just started and to patrol every single (and often multiple) edit is very tiresome. Could you please give it a higher priority?
Comment 15 Marius Hoch 2013-01-21 09:42:45 UTC
(In reply to comment #14)
> Hi! This bug causes some major additional work at Wikivoyage. We have just
> started and to patrol every single (and often multiple) edit is very
> tiresome.
> Could you please give it a higher priority?

I'm working on this as a volunteer, so I can't work/ don't want to work on this all day. Doing this properly on the server side isn't trivial for several reasons so it will take some time and code review will take even more time. Thanks for your patience ;)
Comment 16 Ikan Kekek 2013-01-21 10:09:36 UTC
I am an admin at English Wikivoyage. This bug really makes patrolling at Wikivoyage untenable, especially with the increase in traffic since the site was publicly launched. There is no way I am going to patrol 12 recent edits in one article individually. Marius, like you, I am a volunteer. I am not a software maven, so I don't know how easy or difficult this problem is to fix, but I do appreciate your attention to it. Thanks.
Comment 17 Sertmann 2013-02-23 23:11:13 UTC
As all the other ex-wikitravellers I am also desperate to have this tool back. However, not trying to go overboard on the 'bugging', just a pointer; Since I can't recall most any development done by Internet Brands, I suspect the feature must originally have been implemented/hacked by Evan ( http://en.wikipedia.org/wiki/User:EvanProdromou )
Comment 18 Marius Hoch 2013-02-23 23:13:41 UTC
To give a little status update on this from my side:

I've hacked a bit on that a few weeks back but decided to not push it for review unless https://gerrit.wikimedia.org/r/41196 made it. And the linked change desperately wants some attention by someone who's firm with the WMF memcached setup...
Comment 19 Cacahuate 2013-02-24 01:13:38 UTC
It was indeed Evan who created this feature originally, I spoke to him a little via email and he was going to try and dig back to look at it but I haven't heard anything new, I think he's busy. Marius if you happen to know him or have time, reach out to him as he may be able to guide you. It's such a good feature, I hope we can figure it out
Comment 20 Bartosz Dziewoński 2013-05-29 19:28:36 UTC
That change was merged, so I am assuming this is fixed now.
Comment 21 Nemo 2013-05-29 19:49:05 UTC
(In reply to comment #20)
> That change was merged, so I am assuming this is fixed now.

The assumption is wrong. :) AFAIK the commit was supposed to fix bug 8697, which can be considered a subset of this, but not this one which asks for groups of *unlimited* number of edits to be patrollable at same time.
Comment 22 Peter Fitzgerald 2013-06-06 05:24:32 UTC
Would anyone be able to provide a status update on this request? In the absence of this feature, we effectively do not coordinate admin work on Wikivoyage, meaning that we both miss things and duplicate effort every day.
Comment 23 Alex Monk 2013-06-06 12:03:19 UTC
(In reply to comment #18)
> To give a little status update on this from my side:
> 
> I've hacked a bit on that a few weeks back but decided to not push it for
> review unless https://gerrit.wikimedia.org/r/41196 made it. And the linked
> change desperately wants some attention by someone who's firm with the WMF
> memcached setup...

Could you push the commit for review now, Marius? That change was merged...
Comment 24 Marius Hoch 2013-06-06 14:41:35 UTC
(In reply to comment #23)
> Could you push the commit for review now, Marius? That change was merged...
No, the issue isn't fully resolved (see https://gerrit.wikimedia.org/r/67040 and related bugs). Furthermore I'm not even sure I got the change around still, but I'll still work on this (unless someone else wants to take this bug, then feel free).
Comment 25 Nemo 2013-07-11 07:12:28 UTC
(In reply to comment #24)
> (In reply to comment #23)
> > Could you push the commit for review now, Marius? That change was merged...
> No, the issue isn't fully resolved (see https://gerrit.wikimedia.org/r/67040
> and related bugs). Furthermore I'm not even sure I got the change around
> still,
> but I'll still work on this (unless someone else wants to take this bug, then
> feel free).

That has been stable for a while now, is something still blocking this?
Comment 26 Peter Fitzgerald 2013-08-12 19:09:11 UTC
(In reply to comment #25)
> (In reply to comment #24)
> > (In reply to comment #23)
> > > Could you push the commit for review now, Marius? That change was merged...
> > No, the issue isn't fully resolved (see https://gerrit.wikimedia.org/r/67040
> > and related bugs). Furthermore I'm not even sure I got the change around
> > still,
> > but I'll still work on this (unless someone else wants to take this bug, then
> > feel free).
> 
> That has been stable for a while now, is something still blocking this?

May we have a status update. This remains perhaps Wikivoyage's #1 Bugzilla request, and would be really, really great to finally resolve.
Comment 27 Marius Hoch 2013-08-13 00:30:16 UTC
(In reply to comment #26)
> May we have a status update. This remains perhaps Wikivoyage's #1 Bugzilla
> request, and would be really, really great to finally resolve.
Of course you can have one, but sadly I can't give you any good news on this one. As there are just to many things I need to do in the nearer future I wont have the time to work on this. Of course I'm still going to monitor any progress and may jump in later.
Comment 28 Sumana Harihareswara 2013-08-22 23:38:00 UTC
So, I asked another developer to take a look at this, and he said:

"I've looked into it but can't replicate/don't understand the issue. I
caused Special:RecentChanges to show a group of edits, but all the diff
links ('2 changes', 'cur', 'prev') I get when expanding it lead to pages
with patrol links."

I'm going to ask him to look again at http://wts.wikivoyage-old.org/wiki/WtTech:Grouped_edits_not_patrollable in case that helps.  I tried going to my preferences on English Wikivoyage and couldn't find a preference with the word "enhanced" in it ("But grouped edits, which are achieved when you enable "Use enhanced recent changes (requires JavaScript)" in special:preferences, do not show the "marked as patrolled" link after reaching the edit comparison page.") so I can't figure out how to reproduce this either!

So perhaps people could give some current screenshots of the broken functionality, and let us know what they've set in their Recent Changes and Gadgets tabs in their preferences (e.g., https://en.wikivoyage.org/wiki/Special:Preferences#mw-prefsection-rc and https://en.wikivoyage.org/wiki/Special:Preferences#mw-prefsection-gadgets ).

Thanks! The more information we have, the better the chances of the "a-ha!" moment that leads to a fix.  And I'm sorry for the wait.
Comment 29 Ryan Holliday 2013-08-22 23:48:55 UTC
There may have been a change in behavior since this bug was initially filed, but as of today if you check the box for "Group changes by page in recent changes and watchlist (requires JavaScript)" in the "Recent Changes" preferences and then view http://en.wikivoyage.org/wiki/Special:RecentChanges you will see multiple edits as a group.  If your account has the "patroller" permission any one edit in a group is unpatrolled then the entire group shows up as unpatrolled.  Clicking the "X changes" link next to the grouped item leads to a page that may have a "mark as patrolled" link, but that link only marks the most recent edit as patrolled and NOT the entire group for which the diff is being displayed.  A patroller can still scroll through each individual revision and mark each one as patrolled, but it is far more efficient to be able to mark the grouped diff as patrolled.

The reason that this is a big deal on Wikivoyage is that we really do try to patrol every edit since our wiki is a target for business spamming.  Since most editors will make multiple (and often dozens) of edits to an article, being able to flag all edits in a grouped diff as "patrolled" is a HUGE time saver.

If anyone needs the patroller flag added to their account to reproduce this issue feel free to leave a note at http://en.wikivoyage.org/wiki/User_talk:Wrh2 and I can update the account rights.
Comment 30 Bawolff (Brian Wolff) 2013-08-23 00:55:57 UTC
(In reply to comment #28)
> So, I asked another developer to take a look at this, and he said:
> 
> "I've looked into it but can't replicate/don't understand the issue. I
> caused Special:RecentChanges to show a group of edits, but all the diff
> links ('2 changes', 'cur', 'prev') I get when expanding it lead to pages
> with patrol links."
> 

I think s/he's misunderstanding.

Steps to reproduce:

*Get a diff with an intermediary revision and none of them patrolled (so if we have edit 1, 2 and 3 to a page, a diff between 1 and 3)
*Try to patrol it
*Expected behaviour, a patrol link that patrols all changes shown in the diff

*Actual behaviour, no patrol link.

This should be easy to reproduce locally (just make sure you are a different user when patrolling then one editing, and set $wgUseRCPatrol to true).
Comment 31 Nemo 2013-08-23 08:26:45 UTC
(In reply to comment #30)
> *Get a diff with an intermediary revision and none of them patrolled (so if
> we
> have edit 1, 2 and 3 to a page, a diff between 1 and 3)

To further simplify, this means:
a) open Special:RecentChanges,
b) click the link to the history of any of the pages,
c) ensure there are at least three edits in the last month,
d) click the left radio button in third row or lower,
e) click the button "compare selected revisions".

This doesn't strictly have to do with grouped changes aka enhanced recent changes, it's a general behaviour of multi-diffs.
Comment 32 Yaroslav Blanter 2013-09-11 16:19:48 UTC
Just to add that it would be great to have this feature enabled on all language versions of wv which use edit patrol. I can certainly speak for ru.wv From what I remember, the feature is enabled on a number of Wikipedias including ru.wp
Comment 33 Marius Hoch 2013-11-23 18:55:27 UTC

*** This bug has been marked as a duplicate of bug 8697 ***

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


Navigation
Links