Last modified: 2009-09-27 22:54:26 UTC
I think the title pretty much explains it. Right now, when I create an account as an admin it isn't autoconfirmed and I need to wait 4 days for it to be autoconfirmed. I don't see a reason why accounts created by admins shouldn't do this automatically.
"Autocomfirmed" is on-demand right, it is not stored directly. Some groups automatically have it, but it would be somewhat difficult to trace back to who made the account in an efficient way.
In the current setup, yeah. We would need to store what usergroup made the user, or something. (Or maybe, and I'm being evil here, we could store 'autoconfirmed' sometimes explicitly and sometimes implicitly . . . but that would be evil.)
I'm not entirely sure I follow the reasoning here. Why would admins need to create accounts? If it's a moderated wiki, where all accounts are created by admins, they could just change the autoconfirm time or give everyone access to move/create. If it's a foundation wiki where they're just creating accounts for visually impaired users who can't pass the capcha, they should be able to wait. It would be possible to have a confirmed group with equivalent privs that could be set manually. That would be a little less messy, since it wouldn't need a software change, or take way the ability of an admin to create a non-confirmed account.
Admins create accounts all the time on different wikis and there's no reason for the users they create not to be autoconfirmed. For example, yesterday I created a bot account on the commons but couldn't start a test run since the captcha screen kept popping up. It is a very low priority bug, but a bug nonetheless.
"autoconfirmed" is a permission given to users whose accounts are older than $wgAutoConfirmAge and who have more than $wgAutoConfirmEdits. These are determined based on the user.user_registration and user.user_editcount columns. Since it wouldn't be appropriate to insert bogus data into the user table, we'll either have to introduce a new column and another "confirmed" right, or think up some clever alternative.
On enwiki at least, the most common reason for an admin to create an account is either that they're bypassing a CAPTCHA for an anon who wants an account who can't solve it for some reason, or that they're bypassing AntiSpoof for an anon who wants an account in a situation where either it's a false-positive, or the similar username looks unlikely to be used (and therefore the risk of confusion is low). In neither of these cases would autoconfirmed-by-default be desirable; either the solution in comment #3 (the ability for admins to accelerated-autoconfirm any user) or at least disabling this feature for accounts created 'by email' would be better.
It's also important to consider the following scenarios. I'm not saying these are 100% _going to happen_, but I think it's worth noting since nobody's said them before, and they're very plausible scenarios: Regarding auto-confirming accounts created by admins: 1. "John" exists in real life. 2. "Sally," a psychopath, decides to find ways to spam John into oblivion because John took the last Coke from the soda machine. 3. Sally asks an admin to add an account for her (email: john@john.com) on "YourWiki." 4. Since the address is, as you are proposing, already confirmed, Sally and/or anyone else can spam John's mailbox via YourWiki-- especially if Sally starts posting highly inflammatory things on various articles or discussions. 5. John, instead of using the forgotten password link, reports YourWiki for spamming to "RandomRBL," because he never opted-in to receive email from YourWiki; and, seeing as lack of opt-in is one of the easiest ways to get RBLed... 6. RandomRBL blocks YourWiki's IP range. 7. Any user that uses an ISP that adds "RandomRBL" to their SpamAssassin criteria ends up sending all legitimate emails from actual users to their junk mail folders. 8. You spend hours on the phone and/or a dozen or so emails trying to convince RandomRBL to unblock YourWiki's IP ranges, and those users that those ISPs will complain about not having received email notifications. An simpler alternative scenario might involve "Michael," who hates YourWiki with a passion, doing something similar; but, instead giving your admin spamtrap@somerandomdomain.com as his email address. This will accomplish the same thing if YourWiki's class C sends more than one similar spam mail to the spamtrap-- all of which is easily accomplished by the spammer enabling email on the account and sending what would look like spam to the spamtrap. For all intensive purposes, YourWiki would end up being equated with an open formmail relay, and would almost certainly be blocked. In a nutshell, it's a bad idea to blanket auto-confirm an email address that is allegedly the user's without knowing definitively that the user has access to that email address.
(In reply to comment #7) > It's also important to consider the following scenarios. I'm not saying these > are 100% _going to happen_, but I think it's worth noting since nobody's said > them before, and they're very plausible scenarios: > Regarding auto-confirming accounts created by admins: > 1. "John" exists in real life. > 2. "Sally," a psychopath, decides to find ways to spam John into oblivion > because John took the last Coke from the soda machine. > 3. Sally asks an admin to add an account for her (email: john@john.com) on > "YourWiki." > 4. Since the address is, as you are proposing, already confirmed, Sally and/or > anyone else can spam John's mailbox via YourWiki-- especially if Sally starts > posting highly inflammatory things on various articles or discussions. You've misunderstood the meaning of 'autoconfirmed' (which is quite different from 'emailconfirmed'!). 'autoconfirmed' allows a user to edit semi-protected pages (and on some wikis, the permission is required to reupload images over existing images, to rename pages, and/or to patrol edits); it has nothing to do with email. The scenario you suggest breaks down at step 3; suppose Sally turns up at [[w:en:WP:ACC]] and requests the email, and I answer the request; then John will get a message saying something like 'Someone (probably you) requested an account on en.wikipedia; if this is you, please log on with such-and-such a password...' and John will ignore it (and possibly misinterpret it as a phishing request, but whether John does or not is irrelevant). The email-this-user feature is at that point not enabled (for an example, see <http://test.wikipedia.org/wiki/Special:Emailuser/Account_Ais523_made_to_test_account_creation_1>; I'm not an admin on testwiki, but it wouldn't make a difference if I were, and I created the account as an example for this bug (I'm going to ignore the confirmation email it sends me).)
presumably fixed with the confirmed usergroup created in bug 19611
