Last modified: 2011-04-28 13:33:55 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 15702 - Allow manual override to the auto-confirmation system
Allow manual override to the auto-confirmation system
Status: NEW
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Low enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 21093 25428 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-24 06:02 UTC by od_mishehu
Modified: 2011-04-28 13:33 UTC (History)
7 users (show)

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


Attachments

Description od_mishehu 2008-09-24 06:02:11 UTC
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.
Comment 1 NE2 2008-09-24 06:37:20 UTC
"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.
Comment 2 Gurch 2008-09-24 10:27:10 UTC
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.
Comment 3 Chad H. 2008-09-24 12:12:22 UTC
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).
Comment 4 Happy-melon 2008-09-24 12:25:56 UTC
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.
Comment 5 Chad H. 2008-09-24 12:32:54 UTC
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.
Comment 6 Max Semenik 2008-09-24 16:42:17 UTC
(In reply to comment #2)
> Manual autoconfirmation would be useful when setting up bot accounts

Bots and sysops are already autoconfirmed.

Comment 7 Gurch 2008-09-24 16:57:54 UTC
^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.
Comment 8 Chad H. 2008-09-24 19:13:37 UTC
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.
Comment 9 Alex Z. 2008-09-25 02:26:50 UTC
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.
Comment 10 Chad H. 2010-10-05 21:08:43 UTC
*** Bug 25428 has been marked as a duplicate of this bug. ***
Comment 11 lampak 2010-10-06 19:32:47 UTC
(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)
Comment 12 lampak 2010-10-06 19:37:40 UTC
*off-the-date - I meant "out-of date". Sorry.
Comment 13 John Mark Vandenberg 2011-04-28 13:33:55 UTC
*** Bug 21093 has been marked as a duplicate of this bug. ***

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


Navigation
Links