Last modified: 2014-04-13 13:32:12 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.
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"
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.
*** Bug 12573 has been marked as a duplicate of this bug. ***
Note: By a rollback all revisions in between get auto-patrolled, so a function for this actually exists; just a link is missing.
Would be a great improvement - would reduce around 50% of my patrolling time...
Doesn't block bug 9768, as it's fixed. Blocking bug 12641 seems dubious to me as well.
(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.
*** Bug 20060 has been marked as a duplicate of this bug. ***
(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.
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.
*** Bug 42414 has been marked as a duplicate of this bug. ***
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
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)...
(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.
(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).
(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.
(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).
(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.
What's the relation of this to hoo's recent patrolling changes? (I1e24733c)
(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.
*** Bug 43977 has been marked as a duplicate of this bug. ***
