Page MenuHomePhabricator

Allow manual override to the auto-confirmation system
Open, LowPublicFeature

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

Details

Reference
bz15702

Event Timeline

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

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.

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.

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).

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.

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.

(In reply to comment #2)

Manual autoconfirmation would be useful when setting up bot accounts

Bots and sysops are already autoconfirmed.

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.

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.

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.

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

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)

llampak wrote:

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

  • Bug 21093 has been marked as a duplicate of this bug. ***

Isn't this resolved by the confirmed usergroup?

Nope. Removing the autoconfirmed group doesn't work with the confirmed usergroup

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:01 AM
Aklapper removed a subscriber: wikibugs-l-list.