Allow manual override to the auto-confirmation system
OpenPublic

Description

Currently, the autoconfirmation system is completely automatic. I think that while usually it's a good thing, there may be cases where it should be overridden. I think that a mechanism should exist to allow admins to autoconfirm accounts before they reach the local autoconfirmation standard; de-autoconfirm accounts which already have reached that standard and prevent re-autoconfirmation; and reset the autoconfirmation timer/edit count.


Version: unspecified
Severity: enhancement

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz15702.
OdMishehu created this task.Via LegacySep 24 2008, 6:02 AM
bzimport added a comment.Via ConduitSep 24 2008, 6:37 AM

neroute2 wrote:

"de-autoconfirm accounts which already have reached that standard and prevent re-autoconfirmation" sounds like yet another "class" of user for very little point. If someone is doing something bad that do-autoconfirming would prevent them from doing, they probably need to be blocked.

bzimport added a comment.Via ConduitSep 24 2008, 10:27 AM

matthew.britton wrote:

Indeed. Manual autoconfirmation would be useful when setting up bot accounts, and necessary to deal with false positives from the abuse filter extension, but I can't see any value in de-autoconfirmation.

Chad added a comment.Via ConduitSep 24 2008, 12:12 PM

Suggest WONTFIX. Agree 100% that de-autoconfirmation has little value. However, I disagree with manual autoconfirmation. Part of autoconfirmation is "auto," as in it doesn't happen because of user input. If that were to be the case, "autoconfirmed" would be a defined user group rather than an implicit user group. Secondly, there is no mechanism in place to _force_ autoconfirmation short of raising their edit count and making their register date further back, both of which are arbitrary and generate bad data (their register date will then be inaccurate, they will have made fewer edits than their editcount reports).

bzimport added a comment.Via ConduitSep 24 2008, 12:25 PM

happy_melon wrote:

Autoconfirmation seems to be another of those features that was very simple when first implemented, but for which we have since found other uses and now we want to play with it more than it's designed to accomodate. With extensions like AbuseFilter potentially implementing modifications to autoconfirmed status automatically, it's currently possible for an account's autoconfirmed status to be accidentally revoked with no easy way to restore it. In my opinion, it's time we made autoconfirmed a defined user group, for internal consistency if nothing else. Currently we have the situation where some permissions are granted based on one check system, which is pleasingly modular, flexible and convenient for both humans and extensions to work with, while a minority of permissions are based on a single hardcoded pseudo-group that we need to hack at to do anything more with it than was originally intended. Unless there are very significant overhead benefits from the current system, we'd be doing us all a favour to make autoconfirmed an explicit group, accessible through Special:UserRights and the usual hooks, and write some efficient code to automatically promote users when the autoconfirmed requirements are met.

Chad added a comment.Via ConduitSep 24 2008, 12:32 PM

Autoconfirmed isn't really hardcoded, it's based on the Autopromote class. If by hardcoded you mean set as a default in the software, then yes.
Like any other group, it can be granted/denied any permissions needed. It sounds to me this is more the case: the default rights given to autoconfirmed aren't necessarily what one would like. If a problem exists in what is assigned to autoconfirmed or the autoconfirm levels, those can be changed easily.

Autopromoted group => automatically handled
Defined group => must be assigned manually

This is the way it was designed.

MaxSem added a comment.Via ConduitSep 24 2008, 4:42 PM

(In reply to comment #2)

Manual autoconfirmation would be useful when setting up bot accounts

Bots and sysops are already autoconfirmed.

bzimport added a comment.Via ConduitSep 24 2008, 4:57 PM

matthew.britton wrote:

^demon: The problem is not that autoconfirmation grants the wrong rights or that the threshold is wrong, it's that Werdna's abuse filter extension de-autoconfirms users, and there needs to be some way to reverse that when the extension makes mistakes, which it inevitably will at some point. Otherwise, every mistaken de-autoconfirmation would have to be reversed manually by a developer; I'm sure they have better things to do.

Chad added a comment.Via ConduitSep 24 2008, 7:13 PM

From looking at the AbuseFilter (this is just a first-time cursory glance), it sets the autopromoted value to false in the cache. Wouldn't it be easier for AbuseFilter to have a method within itself (a specialpage, maybe?) to allow the reversal of this? Seems to be a lot easier than changing the core.

Extensions change core MW behavior. If it has an unintended side effect, it's the extension's job to fix that. It's not really a bug in core, rather a problem in AbuseFilter's implementation. Autopromoted groups weren't made to be revoked, so the AbuseFilter needs to handle what happens when it accidentally revokes it when it shouldn't.

Mr.Z-man added a comment.Via ConduitSep 25 2008, 2:26 AM

I agree with ^demon, I don't think there's currently anything in core that removes autoconfirm, and given the limited extra rights it gives by default, I don't think creating a system in core to do this would be worthwhile. If an extension removes (AbuseFilter) or modifies (TorBlock) autoconfirm, the extension should be the one to handle returning to the status quo. Suggest WONTFIX.

Chad added a comment.Via ConduitOct 5 2010, 9:08 PM
  • Bug 25428 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitOct 6 2010, 7:32 PM

llampak wrote:

(In reply to comment #10)

> *** Bug 25428 has been marked as a duplicate of this bug. ***

Em, so I guess the discussion above together with the bug title have just got slightly off-the-date as bug 25428 didn't concern autoconfirm group only. It was more about allowing FlaggedRevs "not to reinvent the autopromote wheel" (bug 24948). "Editor" group in FlaggedRevs must be possible to be managed manually and the current core autopromotion system is lacking this functionality. "Each system implements a bunch of features the other doesn't. The features of $wgFlaggedRevsAutopromote should be merged into $wgAutopromote, and the former should be dropped." (from aforementioned bug 24948)

bzimport added a comment.Via ConduitOct 6 2010, 7:37 PM

llampak wrote:

*off-the-date - I meant "out-of date". Sorry.

jayvdb added a comment.Via ConduitApr 28 2011, 1:33 PM
  • Bug 21093 has been marked as a duplicate of this bug. ***

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.