Last modified: 2014-04-13 13:32:12 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 8697 - Implement button for marking all N changes as patrolled in a multi-edit span diff
Implement button for marking all N changes as patrolled in a multi-edit span ...
Status: NEW
Product: MediaWiki
Classification: Unclassified
Patrolling (Other open bugs)
unspecified
All All
: High enhancement with 27 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 12573 20060 42414 43977 (view as bug list)
Depends on:
Blocks: Wikisource
  Show dependency treegraph
 
Reported: 2007-01-19 00:32 UTC by Borgx
Modified: 2014-04-13 13:32 UTC (History)
27 users (show)

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


Attachments

Description Borgx 2007-01-19 00:32:16 UTC
In enhanced recent changes diff page, the diff is cumulated, so instead of
marking the changes as patrolled one by one per revision, it would be better if
we can marking those changes altogether. Please provide link to "mark these n
changes as patrolled" in the cumulated diff page.
Comment 1 Lars Åge Kamfjord 2008-05-30 15:05:56 UTC
I would like to support this and upgrade it's status to "high", as this would save local sysops/patrollers a lot of time with new users not aware of "preview"
Comment 2 Michael Frey 2008-05-30 17:02:34 UTC
Maybe an idea to simplify the implementation:
When a edit is reverted, then are the flags (the ! in the Recent Changes) reverted edits cleared, that mean they are shown like patrolled.
Disadvantage of this solution is, that there isn't a log entry, but I think that the code of revert could be a basic to work on.
Comment 3 Melancholie 2008-06-06 09:43:01 UTC
*** Bug 12573 has been marked as a duplicate of this bug. ***
Comment 4 Melancholie 2008-06-06 10:03:50 UTC
Note: By a rollback all revisions in between get auto-patrolled, so a function for this actually exists; just a link is missing.
Comment 5 Sebastian Dietrich 2008-10-17 06:04:17 UTC
Would be a great improvement - would reduce around 50% of my patrolling time...
Comment 6 Mike.lifeguard 2008-10-21 20:46:56 UTC
Doesn't block bug 9768, as it's fixed. Blocking bug 12641 seems dubious to me as well.
Comment 7 Nemo 2009-03-28 09:38:40 UTC
(In reply to comment #4)
> Note: By a rollback all revisions in between get auto-patrolled, so a function
> for this actually exists; just a link is missing.

A rollback auto-patrols every revision, but a rollback is possible only to revert edits by a single author: that's great, but it would be useful to patrol even revisions by different authors (since the multiple diff lets us know if they're fixed yet).
Actually, a rollback auto-patrols only the last edit (the revision added by the rollbacker), if you look at the logs, even if then the rollbacked revisions are considered patrolled. Thus, perhaps not only a link is needed. 
Comment 8 Chad H. 2009-08-15 17:51:17 UTC
*** Bug 20060 has been marked as a duplicate of this bug. ***
Comment 9 Svip 2009-08-15 18:02:26 UTC
(In reply to comment #4)
> Note: By a rollback all revisions in between get auto-patrolled, so a function
> for this actually exists; just a link is missing.
> 

Not all patrolling is removing content.  So, no, there is no such function.

I'd even recommend it to patrol even if some of the changes in the bunch are already patrolled (e.g. sysop edits) and obviously by any author.
Comment 10 Christoffer 2010-10-31 19:18:24 UTC
No progress yet? If it could speed up the process somewhat; let it at first only work with the edits of one user, just like the rollback function. Most of the time, to my own experience at least (on a small wiki), that would be enough.
Comment 11 Krinkle 2012-11-24 22:30:35 UTC
*** Bug 42414 has been marked as a duplicate of this bug. ***
Comment 12 Nemo 2013-01-15 22:35:41 UTC
This is made higher priority by the workaround [[m:User:Pathoschild/Scripts/Ajax_sysop]] being broken: https://github.com/Pathoschild/Wikimedia-contrib/issues/8
en.voy would like it too, it seems. http://lists.wikimedia.org/pipermail/wikivoyage-l/2013-January/000354.html
Comment 13 Marius Hoch 2013-01-15 23:29:39 UTC
I thought about implementing this but I'm struggling a bit...
Is there any reason at all to have older RC entries unpatrolled while newer ones are already patrolled?
Do we need a log entry for every revision that is patrolled? (This could flood the logs a LOT).

If the answer to the first question is "No" then the answer to the second one would IMO be that a single log entry is enough (as it's clear that this includes ALL older revisions)...
Comment 14 Nemo 2013-01-15 23:46:23 UTC
(In reply to comment #13)
> I thought about implementing this but I'm struggling a bit...
> Is there any reason at all to have older RC entries unpatrolled while newer
> ones are already patrolled?

Yes but only if one nitpicks a lot: strictly speaking you've not reviewed all edits but only a collation of them, however if you are looking at that specific multi-revisions diff it probably means it's a single edit in multiple steps (which can be patrolled only if from same author and with rollback), or some other sort of related diffs you're checking together and acting upon as a consequence (if you come from enhanced RC, they must be in the same solar day).

> Do we need a log entry for every revision that is patrolled? (This could
> flood
> the logs a LOT).

I don't think it would flood logs a lot, because it's merely what we're already doing now (especially with AJAX patrolling), just with less clicks. And patrol log entries are hidden by default.
Either way, it doesn't matter much IMHO.
Comment 15 Marius Hoch 2013-01-15 23:56:22 UTC
(In reply to comment #14)
> Yes but only if one nitpicks a lot: strictly speaking you've not reviewed all
> edits but only a collation of them, however if you are looking at that
> specific
> multi-revisions diff it probably means it's a single edit in multiple steps
> (which can be patrolled only if from same author and with rollback), or some
> other sort of related diffs you're checking together and acting upon as a
> consequence (if you come from enhanced RC, they must be in the same solar
> day).
In case we only want this for either the same day or even better the same user this is feasible. If you want it for all revision covered by the current diff thinks are going to get a lot more complicated as the recentchanges table lacks usable indexes here and there are pages with a LOT of revision in the RC life span ( eg. https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/Incidents )
> 
> > Do we need a log entry for every revision that is patrolled? (This could
> > flood
> > the logs a LOT).
> 
> I don't think it would flood logs a lot, because it's merely what we're
> already
> doing now (especially with AJAX patrolling), just with less clicks. And
> patrol
> log entries are hidden by default.
> Either way, it doesn't matter much IMHO.
(Per above) If that only covers several edits by one user it's probably fine but if it covers the whole RC lifespan this could grow up to several thousand changes which in turn would mean several thousand log entries (which is insane for various reasons).
Comment 16 Nemo 2013-01-16 08:01:55 UTC
(In reply to comment #15)
> (Per above) If that only covers several edits by one user it's probably fine
> but if it covers the whole RC lifespan this could grow up to several thousand
> changes which in turn would mean several thousand log entries (which is
> insane
> for various reasons).

It would be fair, I think, to allow multi-diff patrols e.g. only when opened with a parameter similar to rcid, which would be provided on RC/WL only; it's what most comments ask. 
Then the issue of making it always available would be split to another bug similar to bug 15936, to be worked on after evaluating performance and community effects of this first implementation, and how big the need for it is.
Comment 17 Marius Hoch 2013-01-16 08:53:53 UTC
(In reply to comment #16)
> It would be fair, I think, to allow multi-diff patrols e.g. only when opened
> with a parameter similar to rcid, which would be provided on RC/WL only; it's
> what most comments ask. 
> Then the issue of making it always available would be split to another bug
> similar to bug 15936, to be worked on after evaluating performance and
> community effects of this first implementation, and how big the need for it
> is.

The rcid parameters we're currently using are there for performance reasons (and I'm on getting rid of them). So I would like to either do this right (no parameter) or not (a parameter couldn't increase the performance here anyway as we would need to know a lot of rcids).

The best way I currently see is to have it patrol all changes by a user in a row (that's feasible on the MediaWiki side and shouldn't be overly controversial on the community side).
Comment 18 Nemo 2013-01-16 08:57:20 UTC
(In reply to comment #17)
> The best way I currently see is to have it patrol all changes by a user in a
> row (that's feasible on the MediaWiki side and shouldn't be overly
> controversial on the community side).

That would surely be a very nice first step but wouldn't be enough to close this bug. At least the diff links provided by the interface itself in enhanced RC should be patrollable, this bug asks. Anyway, one step at a time is a wise way to proceed.
Comment 19 Bartosz Dziewoński 2013-05-29 19:33:13 UTC
What's the relation of this to hoo's recent patrolling changes? (I1e24733c)
Comment 20 Nemo 2013-05-30 09:09:13 UTC
(In reply to comment #19)
> What's the relation of this to hoo's recent patrolling changes? (I1e24733c)

See bug 43977 comment 21; this part may have been removed completely though, or rather left to a following step, because I don't see anything to patrol multiple edits, even very recent, nor coming from history nor from RC.
Comment 21 Marius Hoch 2013-11-23 18:55:27 UTC
*** Bug 43977 has been marked as a duplicate of this bug. ***

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


Navigation
Links