Last modified: 2011-06-25 18:21:38 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 T24713, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 22713 - rollback action does not match abusefilter
rollback action does not match abusefilter
Status: RESOLVED DUPLICATE of bug 23087
Product: MediaWiki extensions
Classification: Unclassified
AbuseFilter (Other open bugs)
unspecified
All All
: Lowest major (vote)
: ---
Assigned To: Andrew Garrett
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-03 16:13 UTC by merl
Modified: 2011-06-25 18:21 UTC (History)
4 users (show)

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


Attachments

Description merl 2010-03-03 16:13:25 UTC
Abusefilter does not match on rollback action only on edit, move, upload, ....
On dewiki many people (all Editors) can use rollback so that's a big problem.
Comment 1 Gurch 2010-03-03 17:33:39 UTC
I would consider that a feature, not a bug.

Rollback can only restore previous versions of pages, and said previous versions can only exist if they got past the abuse filter in the first place.

Sure, if you really wanted to, you can search through recent changes and find a page where rollback will reintroduce vandalism, and then do the rollback. But if you have members of one of your privileged groups deliberately doing that, you have worse problems than the abuse filter.

It is better to allow rollback to fix vandalism and trust your privileged group to use the tool correctly, than to end up having vandalism that *cannot* be removed because the previous version of the page trips some obscure filter. Because then you have a situation where you have to get an administrator in to fix the problem (I have no doubt you've given your administrators a free pass on all filters, just like en.wikipedia has).

Why do you even want to create filters that apply to your privileged group (did I mention this is a *privileged group* here?) If you don't trust them to edit properly without your supervision, why are they in the group in the first place? Enough of the 'us vs. them' mentality.
Comment 2 merl 2010-03-04 03:09:57 UTC
It's not Vandalisms, but Edit-War. And i made very good experience by limiting the edit count on a single page per user on dewiki. I set a limit of three edits per day for each user and article and that reduces die edit-war and in most cases solves the problem by time.
Some full locks in the past weren't not successful because the party of the blocked version did not participate at the discussion.

I tried the editlimit at some pages which had sysop protected since years and after a week the edit war stopped in about 80% of the pages. Now there aren't many sysop protected pages anymore.

But with rollback you can bypass the edit limit.
I think you know that it is not always easy to revoke editor right for people committing since years and the editlimit filter is more effective than i ever expected in my dreams before.
Comment 3 Gurch 2010-03-04 12:04:15 UTC
(In reply to comment #2)
> It's not Vandalisms, but Edit-War.

Again, this is a *privileged group* you've given rollback to. If they're abusing their position, the solution is not restrictive abuse filters, it's to remove them from that position of trust.

> And i made very good experience by limiting
> the edit count on a single page per user on dewiki. I set a limit of three
> edits per day for each user and article and that reduces die edit-war and in
> most cases solves the problem by time.

Ugh... you really did that? I'm glad German isn't my native language. Yes, I'm sure it has drastically reduced the edit warring problem. It's also lost you a lot of useful contributions.

> Some full locks in the past weren't not successful because the party of the
> blocked version did not participate at the discussion.

Then you unprotect the page, and block the edit warring user if they continue. I don't see why the abuse filter needs to get involved.

> I tried the editlimit at some pages which had sysop protected since years and
> after a week the edit war stopped in about 80% of the pages. Now there aren't
> many sysop protected pages anymore.

Sounds to me like you'd been leaving those pages protected far longer than necessary. Full protection because of an edit war should never last "years". I think you're making a false correlation here -- I assure you if you'd just unprotected those pages without putting any abuse filters in place at all, you would still see an 80% reduction in edit wars, because years later, most people have either resolved the issue through discussion, or more likely completely forgotten about and abandoned the argument.

And even if they haven't, you remove the protection anyway and block them if they resume. Otherwise, nobody ever gets to contribute. Full protection because of an edit war should never last more than a few weeks.

> But with rollback you can bypass the edit limit.
> I think you know that it is not always easy to revoke editor right for people
> committing since years

Type their name into [[Special:Userrights]], click a few buttons. It sounds pretty easy to me. If they're edit warring, they have no excuse. If they're not only edit warring but intentionally bypassing your project's policy on edit warring after you've told them to stop, then frankly I think a block would be in order, let alone de-grouping.

> and the editlimit filter is more effective than i ever
> expected in my dreams before.

Only because you have a warped definition of 'effective'. You could full-protect every page on the wiki and be 100% 'effective' at preventing vandalism, spam, edit warring and everything else. Do you see the fallacy there? If your filters are anything like those on the English Wikipedia -- and everything you've said points to them being much, much worse -- you are losing thousands of useful contributions, both because your filters are preventing them, and because new users frustrated with your filters are never becoming engaged enough with the project to regularly contribute.

I swear the abuse filter is the worst thing to happen to this project in recent years.
Comment 4 Happy-melon 2010-03-07 23:07:18 UTC
(In reply to comment #3)
> I swear the abuse filter is the worst thing to happen to this project in recent
> years.

I'm not sure I'd go quite that far; but fixing this would certainly not be a step in the right direction.  WONTFIX.
Comment 5 db [inactive,noenotif] 2011-06-25 18:21:38 UTC

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

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


Navigation
Links