Extension talk:ConfirmAccount/archive 1

The email confirmation messages
My users complain that whenever they register and click the email confirmation link, Wiki answers that the code is not valid anymore. I'm using 1.12.0 with the newest ConfirmAccount. The date and time settings on the server are correct. What could cause this?

New user account creation page don't show up
I have installed ConfirmAccount, and put the include_once line in LocalSettings.php (tried both before and after the $wgEnableEmail=true). But the wiki either don't display new user creation page, nor display a new account application form, Could you please tell me what's wrong with it?

Users can't register
I've installed newest svn ConfirmAccount and ConfirmEdit on 1.11.2 Mediawiki, and quite many users on Windows claim they can't register (because confirmaccount doesn't accept the answer to the calculation). Can this be jscript related? I haven't encountered this problem on Windows/Linux Firefox/Konqueror/IE/Opera, but now at least 6-7 users have. (still, most people can register without problems). I'm suspecting ConfirmAccount has an incompatibility issue with either older Firefox versions or jscript. Can anyone confirm my findings?

Confirmaccount doesn't update
On mediawiki 1.11.1 confirmaccount 1.1 and 1.0 do not update the number of registered users when their accounts are confirmed. The value is updated as soon as the confirmaccount is disabled and the main page reloaded. This seems to work as a temporary solution.
 * Just added stats updating to SVN. Thanks for pointing that out. Aaron 17:03, 18 February 2008 (UTC)

ConfirmAccount extension requires $wgEnableEmail set to true
Hi, I'm getting the errormessage above, although in LocalSettings.php the value is set to true... did I miss a step? -Dholzmann 17:42, 21 January 2008 (UTC)
 * Is the include line for the extension after the line that sets $wgEnableEmail=true? Is the $wgEnableEmail=true line after the include line for defaultsettings.php. Both of those should be the case. Aaron 19:52, 21 January 2008 (UTC)

Disable the email sending
Hi, I'm using this extension to create a login system that requires the users to have the account checked, but I don't want to use the email part of it. Is there a way of taking that section only out of it? -CustomJ 14:37, 7 December 2007 (UTC)
 * No. Aaron 09:09, 31 December 2007 (UTC)

Send account request to Administrator
After a new user confirmed the e-mail of his account request, the administrator receive an e-mail notification about this pending request with a direct link to Special:ConfirmAccounts. Tested in English and German.

Patch function in extensions/ConfirmAccount/ConfirmAccount_body.php
function confirmEmailToken( $code ) { global $wgUser, $wgOut; # Confirm if this token is in the pending requests $name = $this->requestFromEmailToken( $code ); if( $name !== false ) { # Send mail to admin after e-mail has been confirmed global $wgEmergencyContact; $u = User::newFromName( $name, 'creatable' ); $u->setEmail( $wgEmergencyContact ); $title = Title::makeTitle( NS_SPECIAL, 'ConfirmAccounts' ); $url = $title->getFullUrl; $u->sendMail (wfMsg('requestaccount-email-subj-admin'),                               wfMsg('requestaccount-email-body-admin', $name, $url)); $this->confirmEmail( $name ); $wgOut->addWikiText( wfMsgHtml( 'request-account-econf' )); $wgOut->returnToMain; return; }               # Maybe the user confirmed after account was created... $user = User::newFromConfirmationCode( $code ); if( is_object( $user ) ) { if( $user->confirmEmail ) { $message = $wgUser->isLoggedIn ? 'confirmemail_loggedin' : 'confirmemail_success'; $wgOut->addWikiText( wfMsg( $message ) ); if( !$wgUser->isLoggedIn ) { $title = SpecialPage::getTitleFor( 'Userlogin' ); $wgOut->returnToMain( true, $title->getPrefixedText ); }                       } else { $wgOut->addWikiText( wfMsg( 'confirmemail_error' ) ); }               } else { $wgOut->addWikiText( wfMsg( 'confirmemail_invalid' ) ); }       }

Translation file
Get the translation file from rrosenfeld at http://www.spinnaker.de/tmp/ConfirmAccount.i18n.php.txt and extend the english and german section:

English section: 'requestaccount-email-subj-admin' => ' Request account', 'requestaccount-email-body-admin' => 'The account "$1" has request an account and is waiting for confirmation. The e-mail address has been confirmed. You can confirm the request here "$2".',

German section: 'requestaccount-email-subj-admin' => ' Antrag auf Account', 'requestaccount-email-body-admin' => 'Das Benutzerkonto "$1" hat einen Antrag auf einen Account gestellt. Die Emailadresse wurde bereits bestätigt. Du kannst den Antrag unter "$2" freischalten.',

regards --schweny 22:50, 13 August 2007 (UTC)


 * I've added similar functionality now. Aaron 09:28, 31 December 2007 (UTC)


 * I also want to get an email when new users request a account on my wiki. But at this moment i am not getting any emails. So my question is where does the extension get the email address of the admin? Is this just the main email address in localsetting.php or do I have to fill in that address somewhere in the code that is show above here? Could somebody help me on the way? Thx.--Snapte 10:09, 7 February 2008 (UTC)


 * I am also having problems with this. I see in ConfirmAccount_body.php that a new variable is being used: $wgConfirmAccountContact, but declaring this in LocalSettings.php with the email address of my administrator hasn't worked - still no admin notifications being sent. 65.203.61.135 21:26, 3 March 2008 (UTC)

Feature requests from the Citizendium
First, well done on the "currently being viewed by" feature!

All, I am so glad to see that there are people helping Aaron with this extensionm, which is very useful and important to us. We do have a few feature requests, however. CZ would like to have the option to allow account approvers to do the following:
 * 1) Edit biographies.  (This allows us to remove information about hometowns, age, and school from people under 16 years old, without having to change it and then "oversight" the result.)
 * 2) Allow sysops, or perhaps a higher-level user, to save and view the info entered in "Identity confirmation."  And also CVs (especially--people often apply later for editorship and say, "but I already gave you my CV"--"sorry, but I can't access it anymore").  Currently this is either deleted or not visible, anyway.  Sometimes, we need to see the info in order to decide how to handle a specific problematic user--we sometimes want to doublecheck someone's identity when considering whether to boot them from the project. In general, we (rarely) need to see the info after an account has been approved.  That info might be added to the user's "block user" (Special:Blockip) page, which we use to locate the person's e-mail address, or else put it all in a new special page...obviously, the possible existence of such a "confidential info" page is one thing that would greatly distinguish CZ from WP.
 * 3) When request approvers use the "hold" and "reject" options, no one else can see the comments entered there.  That's crucial information for mutual oversight and collaboration.  We really need to be able to see that info in the reject and hold queues.
 * 4) Under "Signature" (bottom of the page) we'd like to have actually three separate checkboxes.

We won't be opposed if you want to make these off by default, since they are important mainly for CZ's policies. But we do need these things.

There's another big feature request that we badly need. There are multiple roles in our system: author and editor. Not only would we like a checkbox that someone can check if they're interested in becoming an editor...we'd actually like to go further and create three new queues: new editor applications, editor applications on hold, and rejected editor applications. Note that we'd have to be able to have all the relevant info after an author account had been approved. If anyone is interested in doing this, e-mail me at sanger [at] citizendium.org and I'll send you more detailed requirements.

I'd like to know who is using this extension, just out of curiosity. --Larry Sanger 18:13, 28 December 2007 (UTC)


 * Looks like it is all doable. I was opposed to biography editing, but if a credentials table is added, then it can store the original, so that way we can be sure what they really sent. Aaron 23:32, 28 December 2007 (UTC)


 * Actually, I don't see the point of #4 since even two looked cluttered. Still working on the rest though. Aaron 02:00, 29 December 2007 (UTC)


 * Glad to hear it's doable! Do let me know when you're ready to do the editor system; there are several nonobvious requirements.


 * As to #4, well, we'd just like to make sure people read and understand that there are three things they're agreeing to. This is a lot more important than an uncluttered look.  Besides, for other websites, just one checkbox (or none) could be the default setting. --Larry Sanger 03:19, 29 December 2007 (UTC)


 * Should this credential page be update-able or should it stay as it was during the time of account approval? People can always post their their info and post/link to/upload their resume afterwards and have it on some subpage, and the original "identity" info is fairly private; so I guess this special page would be static then? Aaron 04:48, 29 December 2007 (UTC)
 * I'll just make the schema able to have revisions. Aaron 23:32, 29 December 2007 (UTC)

Possible bug with picking new usernames
I ran into problems when overriding the user's choice of a username. In the acceptance form I chose a different login name for this user that did not start with an uppercase letter. This username (all lowercase) was then inserted in the mysql database. Since mediawiki seems to convert the first letter of every loginname to uppercase, the user was not able to log in afterwards. All went fine when I changed the first letter of the login-name to uppercase within the mysql database.

In summary I think the acceptance form lacks an automatic conversion to uppercase for the first letter of the login name. I am not using the actual version of ConfirmAccount but a version prior to the 26.10.200; I apologize if this has already been corrected but this is a production system and at the moment I don't have time to fiddle with new versions.

Anyway, thanks for your work on this Aaron! Except of this minor bug it's working like a charm here. --Arnd 10:38, 8 January 2008 (UTC)


 * Fixed. Aaron 00:12, 9 January 2008 (UTC)

Bios
When setting, the account creation page still says that the bio will copied into the user's page (at least in German). By the way, is there a means to turn off the form with the bio information entirely? (I am administrating a wiki for people in a work group who have to come to the regular meetings to be allowed to get an account - no need for writing a bio). --Tillmo 15:20, 23 January 2008 (UTC)
 * No, but you can set the mimimum bio length very low. Aaron 19:34, 23 January 2008 (UTC)

MySQL command
"people should know this already"

no! I didn't. It took me about half an hour to figure it out. I could have saved this time... --Tillmo 09:18, 29 January 2008 (UTC)

Me, too
Add me to the list of ignoramuses who don't know how to do this. Can anyone point me in the right direction? Can it be done through PHPMyAdmin, or do you need to do it via command line? --StochasticJack 20:39, 22 April 2008 (UTC)


 * Okay, I figured it out. For those who, like me, aren't thoroughly familiar with MySQL, here's the solution:
 * * As the comments in the ConfirmAccounts.sql file say, replace the string  with the prefix of the tables in your database. That includes the comment marks. In my case,   became.
 * * If you're using PHPMyAdmin, like I was, after selecting your database, you click on the tab labeled "SQL."
 * * Copy and paste the contents of ConfirmAccounts.sql into the big text box on the screen under the SQL tab.
 * * Click "Go." If all works out well, you should now have two new tables: account_credentials and account_requests.
 * --StochasticJack 23:19, 22 April 2008 (UTC)

Error with postgresql
Hi,

in order to get the sql script with postgresql 8.1 running, I had to remove one line in ConfirmAccount.pg.sql concerning "acr_type":

svn diff ConfirmAccount.pg.sql Index: ConfirmAccount.pg.sql =================================================================== --- ConfirmAccount.pg.sql      (revision 30521) +++ ConfirmAccount.pg.sql      (working copy) @@ -20,7 +20,6 @@   acr_ip                   CIDR, acr_filename            TEXT, acr_storage_key         TEXT, - acr_type                 INTEGER, acr_areas               TEXT, acr_deleted             BOOL      NOT NULL DEFAULT 'false', acr_rejected            TIMESTAMPTZ,

Otherwise I got an error complaining about duplicate keys in the table definition and in fact the svn version of the file originally contained two separate definitions of this key.


 * I see. I removed the duplicate on SVN now. Aaron 16:11, 4 February 2008 (UTC)

Special:ConfirmAccounts queue missing
I get the message, ending "Select an account confirmation queue from below:", but the queue is not displayed, although a look into the database shows that there are 3 pending requests. While the users requesting accounts did get a confirmation email, I as the admin did not get any emails. Hence, I cannot confirm the pending requests. I use MediaWiki 1.11.1, PHP 5 and MySQL 5.0.26. --Tillmo 13:09, 11 February 2008 (UTC)
 * I don't have this problem. What do you have $wgAccountRequestTypes set as? Are the queues listed a Special:ConfirmAccounts? Are the actual queue lists just empty? Aaron 21:09, 11 February 2008 (UTC)
 * I have, because I do not need this information. The queues are not listed at Special:ConfirmAccounts, as I wrote. --Tillmo 13:58, 19 February 2008 (UTC)
 * Indeed, if I uncomment, then it works! --Tillmo 14:40, 19 February 2008 (UTC)

500 Internal Server Error
I had ConfirmAccount running successfully for months (mediawiki 1.11.0). Suddenly it has started returning a '500 internal server error' when a request is submitted. The email is sent to the requestor, but the process appears to fail at the point where it adds the request to the database (the email token is invalid, and the request does not appear on the special:confirmaccount). Also, an account must have been requested prior to the script failure; I cannot approve this script: pressing the submit button returns the same error.

I reinstalled the latest version of ConfirmAccount (deleted the table and re-ran the query as well), and also removed the configuration items from local setting: still the same problem.

Error log reports only: "Premature end of script headers: /home/paeds/public_html/wiki/index.php" every time.

I can only assume something in my site has changed to stop the scripts working. Any ideas what? I have tried everything I can think of.

The only other recent changes to note are installations on the same server of: phplist, joomla, 'gallery'. One was installed via Fantastico, the others manually. Could these interfer? Could a common temp file, for example, be to blame?

I have had to de-activate ConfirmAccount since it is blocking sign-ups on my site. Advice for myself and others appreciated. --91.109.245.99 00:26, 27 February 2008 (UTC) N.Prince

Sorry; I have now realised that any account creation on the site fails in the same way. The above questions remain. I have had to block user account creation for now. Apologies for the mis-placed approach for help. But any ideas? Many thanks. --91.109.245.99 00:59, 27 February 2008 (UTC) N. Prince

Database Error
I followed the instructions to install ConfirmAccount and I got the following error once logged in: A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "wfConfirmAccountsNotice". MySQL returned error "1146: Table 'XXXX.account_requests' doesn't exist (localhost)". I was executing the sql commands (ConfirmAccount.sql) in the web host's control panel. It turns out that the control panel is doesn't like the commented lines in the SQL. I deleted all lines beginning '--' and it now works.

Config Cleanup
I cleaned up the configuration section attempting to add clarity to the descriptions and the data types that the configuration variables require. I did this after noting that clarity was needed to configure "How Long before a request is rejected." since such a statement does not define the time units. Looking at the code, it turns out the time unit is in seconds -- not days as one would expect.