Page MenuHomePhabricator

Reverting to a flagged revision should automatically mark the resulting revision as flagged, too
Closed, DeclinedPublic

Description

Author: Wiki.Melancholie

Description:
Reverting to a flagged revision should automatically mark the resulting revision as flagged, too.

At least if a revert is done by the sysop's rollback feature!


Version: unspecified
Severity: enhancement

Details

Reference
bz13978

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 10:13 PM
bzimport set Reference to bz13978.
bzimport added a subscriber: Unknown Object (MLST).

I'm going to close this one, unless there are some examples.

Wiki.Melancholie wrote:

[[:de:Blasenkirschen]] was one, it got reverted by &undo= (by a non-sysop, not rollback) to exactly the same content the flagged revision had, see bug [[13977]]. The resulting revision had to be re-checked (re-marked as "sighted").

Does it already work for a sysop rollback?

I'll test around with undo.

(In reply to comment #3)

[[:de:Blasenkirschen]] was one, it got reverted by &undo= (by a non-sysop, not
rollback) to exactly the same content the flagged revision had, see bug
[[13977]]. The resulting revision had to be re-checked (re-marked as
"sighted").

Does it already work for a sysop rollback?

Did the person have basic review rights?

Wiki.Melancholie wrote:

Currently "reverting will re-flag" is only the case for users that are sighters. See [[:de:Kempten_(Allgäu)]]!
http://de.wikipedia.org/w/index.php?title=Kempten_(Allgäu)&action=history
where the latest rev (an undo revert) did not get re-flagged.
Content is 100% the same as it was, when being flagged two revs ago.

Should I create a new feature request for that?

The fix doesn't work on all WMF wikis, see for example the two following historys: http://test.wikipedia.org/w/index.php?title=Parent_page/subpage&action=history and http://en.wikibooks.org/w/index.php?title=Microprocessor_Design/Design_Steps&action=history both wikis are running 1.16wmf4 (r70933) and I have no 'autoreview' in both.

(In reply to comment #9)

The fix doesn't work on all WMF wikis, see for example the two following
historys:
http://test.wikipedia.org/w/index.php?title=Parent_page/subpage&action=history
and
http://en.wikibooks.org/w/index.php?title=Microprocessor_Design/Design_Steps&action=history
both wikis are running 1.16wmf4 (r70933) and I have no 'autoreview' in both.

Are you a reviewer?

(In reply to comment #10)

Are you a reviewer?

I just have the usual autoconfirmed rights in both wikis (which do not include either review of autoreview) + the global rollbacker rights, which do not include autoreview or review as well. (http://meta.wikimedia.org/wiki/Global_rollback)

(In reply to comment #11)

(In reply to comment #10)

Are you a reviewer?

I just have the usual autoconfirmed rights in both wikis (which do not include
either review of autoreview) + the global rollbacker rights, which do not
include autoreview or review as well.
(http://meta.wikimedia.org/wiki/Global_rollback)

Only self-reverts to the stable version are allowed for people without 'autoreview'.

(In reply to comment #12)

Only self-reverts to the stable version are allowed for people without
'autoreview'.

I tested it again on testwiki (with another account as vandal) http://test.wikipedia.org/w/index.php?title=Parent_page/subpage&action=history and it's not autoreviewing the change...

Will this be changed in the future?

(In reply to comment #13)

(In reply to comment #12)

Only self-reverts to the stable version are allowed for people without
'autoreview'.

I tested it again on testwiki (with another account as vandal)
http://test.wikipedia.org/w/index.php?title=Parent_page/subpage&action=history
and it's not autoreviewing the change...
Will this be changed in the future?

I thought you didn't have 'autoreview'? Why *would* it be autoreviewed?

(In reply to comment #14)

I thought you didn't have 'autoreview'? Why *would* it be autoreviewed?

Because I'm restoring a version, which somebody else already marked as "Ok", so there is no need to review it again, is there? :)

That would let vandals just revert to super old versions, which could become the stable version. That doesn't seem acceptable.

This report was about sysops (or trusted users at least). A more general request should be made as a separate report.

(In reply to comment #16)

That would let vandals just revert to super old versions, which could become
the stable version. That doesn't seem acceptable.

You didn't understand. Hoo was talking about rollbacks, not generic reverts. Rollbackers are trusted users, and rollback has a different behaviour from normal reverts also with regard to patrolled revisions (rollbacked revisions are marked as patrolled, even if this doesn't appear in logs).
Rollback restores the most recent revision (excluding those from the rollbacked user).

(In reply to comment #15)

(In reply to comment #14)

I thought you didn't have 'autoreview'? Why *would* it be autoreviewed?

Because I'm restoring a version, which somebody else already marked as "Ok", so
there is no need to review it again, is there? :)

So it the request to give 'autoreview' to "global rollbackers"? That should be a separate "site request" and might require discussion.

(In reply to comment #18)

(In reply to comment #15)

(In reply to comment #14)

I thought you didn't have 'autoreview'? Why *would* it be autoreviewed?

Because I'm restoring a version, which somebody else already marked as "Ok", so
there is no need to review it again, is there? :)

So it the request to give 'autoreview' to "global rollbackers"? That should be
a separate "site request" and might require discussion.

No, because "autoreview" would apply also to non-rollback edits.
But even if you don't have autoreview, it doesn't make sense that, if you restore an old version of the page, that version now has a different flag.

(In reply to comment #19)

But even if you don't have autoreview, it doesn't make sense that, if you
restore an old version of the page, that version now has a different flag.

Oops, I suppose this is bug 13751.

So is this to make rollback by anyone, regardless of rights, auto-review that revision? That would be a bad separation rights. Is the request to make a new right for "autoreview on rollback" and then grant that to "global rollbackers"?

(In reply to comment #21)

So is this to make rollback by anyone, regardless of rights, auto-review that
revision? That would be a bad separation rights.

Why? You said that the problem was the possibility that someone made an old version the new stable version, but this doesn't apply to rollbacks. On bug 13751 you said that there are "some exploits" but you didn't specify them (but you said also «I'll probably make it at least basic reviewed»).
So, what's the problem?

Is the request to make a new
right for "autoreview on rollback" and then grant that to "global rollbackers"?

If you want to say so; but I think that such a right should be implicit in the "rollback" right.

(In reply to comment #17)

rollback has a different behaviour from
normal reverts also with regard to patrolled revisions (rollbacked revisions
are marked as patrolled, even if this doesn't appear in logs).

You can see an example on pt.wiki, where rollbackers (and autoconfirmed) don't have autopatrol (http://pt.wikipedia.org/wiki/Especial:Lista_de_privil%C3%A9gios_de_grupos?uselang=en ), if you pick a rollbacker who is not autopatroller (http://pt.wikipedia.org/w/index.php?title=Especial:Lista_de_utilizadores&group=rollbacker&uselang=en ): if you're autoconfirmed, you'll see that e.g. this edit http://pt.wikipedia.org/w/index.php?title=Chuva_%C3%A1cida&diff=21560746&oldid=21359167 is shown as patrolled because it was implicitly autopatrolled by the subsequent rollback http://pt.wikipedia.org/w/index.php?title=Chuva_%C3%A1cida&diff=next&oldid=21560746 (it was not explicitly patrolled because otherwise it would be listed in the log and it is not: http://pt.wikipedia.org/w/index.php?title=Especial:Registo&dir=prev&offset=20100809003204&limit=3&page=Chuva+ácida&hide_patrol_log=0 ).
Therefore, the current behaviour of rollback with regard to FlaggedRevs is inconsistent.

(In reply to comment #23)

Therefore, the current behaviour of rollback with regard to FlaggedRevs is
inconsistent.

Excuse me, I was not clear here: I meant that this a sort of autopatrol right implicit in rollback right, and that making also "autoreview on rollback" implicit in rollback seems analogous to me.

The core commitRollback() function always auto-patrols. FR can't really control that nicely. Eventually most of FR's usage of RC patrol will be removed, which already started with the (pending review) and (unreviewed) links on RC/watchlist/RLC pages (to replace ! marks).

I don't have *strong* feelings on making rollback implicitly autoreview (to the lowest level). Is that what this comes down to and nothing else? Or should the flags be identical to the base revision that the page was reverted to? The only thing I worry about ("exploits") are template/file vandalism/misinformation that slips through on a page that uses them (the templates) without notice (on rollback).

I would prefer to have identical flaggs for the original and for the reverted version. If you don't want to activate that per default for every rollback, you can as well create a new user right like 'restoreflagg' so the stewards could set it for the global rollbackers

(In reply to comment #26)

I would prefer to have identical flaggs for the original and for the reverted
version. If you don't want to activate that per default for every rollback, you
can as well create a new user right like 'restoreflagg' so the stewards could
set it for the global rollbackers

This would be like comment #21.

We're discussing this issue now. Our inclination is to mark this as "wontfix", but I'd like to read through this to make sure that we stand by this assessment.

Note, there is the case on Wikinews where reviewers don't have autoreview rights, so rollback to sighted revision not being auto-sighted for reviewers is kind of annoying, but still a rather minor annoyance. (I know this is similar to other cases mentioned above, I only mention it as 99% of wikis the reviewers would have autoreview, so this bug being fixed (if it were to be fixed) would have a somewhat different effect for wikinews)

Ok, I've read though this one enough that I feel comfortable marking this as "wontfix". I share Aaron's concern that mixing privileges is a bad idea.

If we still really need to revisit this issue, please file a more specific feature request. The current title/description is too far-reaching, but a more specific request for a new "autoreview on rollback" right might fly.

(In reply to comment #30)

If we still really need to revisit this issue, please file a more specific
feature request. The current title/description is too far-reaching, but a more
specific request for a new "autoreview on rollback" right might fly.

I've reopened bug 13751.