himer2001 wrote:

Yes, this feature is highly demanded.

Confirming.

This will probably get fixed by I1e24733c when it gets merged.

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

peter wrote:

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!

Agree with Peter, how long before it can be gotten up and running?

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

peter wrote:

This should make it very clear:

http://wts.wikivoyage-old.org/wiki/WtTech:Grouped_edits_not_patrollable

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]

highly related: bug 8697

(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

yocacahuate wrote:

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

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.

peter wrote:

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!

jc8136 wrote:

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?

(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 ;)

sepuluhringgit wrote:

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.

sertmann wrote:

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 )

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

yocacahuate wrote:

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

That change was merged, so I am assuming this is fixed now.

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

peter wrote:

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.

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

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

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

peterbugzilla wrote:

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

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

sumanah wrote:

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.

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.

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

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

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

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