Extension talk:Password Reset/LQT Archive 1

Rights
Maybe it is better to replace the 'userrights' with e.g. 'resetpassword' because with $wgRemoveGroups and $wgAddGroups it is possible that users who should not have access to Special:PasswordReset, can have access to it. SPQRobin 11:31, 3 November 2007 (UTC)
 * I opened bug 11914 SPQRobin 22:26, 9 November 2007 (UTC)
 * Yeah, but I despise non-standard permissions.
 * Thanks for fixing it. I had also seen the extension uses wfMsgForContent, but I think that's useless because there are translations. I changed it in the my second comment in the bug, but you haven't seen it I guess. Do you want to change it to wfMsg? Thanks, SPQRobin 21:14, 19 November 2007 (UTC)
 * The difference between wfMsg and wfMsgForContent is *which* language setting it translates to, wfMsgForContent does not change depending on the user's language prefererences, while wfMsg does change based on the user's language. It's still translating.  It just doesn't care what the User Preference is set to.
 * Yes, I know, but why should it use the site language and not the user language, if there are translations? SPQRobin 16:59, 20 November 2007 (UTC)
 * Because it's an admin page. Where on earth do we have site administrators that don't understand the default site language?  Though I suppose your argument is within the lines of "it wouldn't hurt," eh?
 * Yes :-) If you see really everything translated, but only this extension not... SPQRobin 18:39, 20 November 2007 (UTC)
 * Done in r27718.

Question

 * Could you add a checkbox to disable a user on your Special Page ?
 * It will make the password field be updated to ' * ', but without salting it, making it impossible for a user to ever match the password
 * Well, the user could always request a randomized password via email - Which could be diabled, I suppose.

Answer

 * What's wrong w/ the current blocking functionality in MW? I don't think there's any chance of a mainstream user 'guessing' 16 random characters either - wouldn't that be equally effective?  ;-)  Tim Laqua talk 14:15, 7 December 2007 (UTC)

Question 2

 * The current blocking feature blocks from editing, not login. We have a wiki install that requires login to even read, so user administration is essential.
 * We do effectively enter manually a random password for now, but this would be easier and completely failsafe.--Y.combarnous 15:27, 7 December 2007 (UTC)

Implemented

 * Implemented in r28251. Let me know if you notice any bugs w/ the new functionality.  Tim Laqua talk 18:06, 7 December 2007 (UTC)

Observation
Tim Laqua talk 08:22, 13 December 2007 (UTC)
 * I love the "disable" feature, however it would be great for it to also disable the "by email" feature. At the moment preventing a user from viewing a Wiki involves two steps: Using BlockUser to prevent the user from sending emails, and using PasswordReset to disable logins. - 149.171.89.39 07:12, 12 December 2007 (UTC)
 * Disabling their email so they can't reset their own password via email? Is that what you're referring to?  Tim Laqua talk 12:41, 12 December 2007 (UTC)
 * Yep, that's what I mean. - 149.171.89.39 00:05, 13 December 2007 (UTC)
 * Implemented blocking hook in r28418. Tim Laqua talk 20:21, 12 December 2007 (UTC)
 * I just tried r28418 and it still allows password reset by email... - 149.171.89.39 00:10, 13 December 2007 (UTC)
 * Please grab the current SVN revision, I removed some debug code from r28418.
 * Also, note that it only blocks users that have been disabled using the Disable User Account checkbox (which sets the user_password hash to "DISABLED").
 * What version of MediaWiki are you running and what is your default language? Tim Laqua talk 01:12, 13 December 2007 (UTC)
 * Thanks for working on this. I've grabbed the latest SVN revision. I'm running Mediawiki 1.11.0, and my language is English. I go to Special:PasswordReset, enter a username, select the Disable User Account? checkbox, then click "Reset Password". The disabled user is still able to reset their password with the "by email" button. - 149.171.89.39 06:21, 13 December 2007 (UTC)
 * That's pretty odd. I tested on 1.10.2, 1.11.0, and 1.12alpha (r25309) - works as expected.
 *  What database are you using?
 *  If you go to Special:Version in your wiki, scroll to the bottom in the Hooks section - do you see "GetBlockedStatus" Subscribed by "PasswordReset::GetBlockedStatus" ?
 *  What other extensions are you running and is PasswordReset the first or last extension to be included in LocalSettings.php?
 *  Do any of your other currently installed extensions Subscribe to "GetBlockedStatus" ?
 * In the case that you have other blocking extensions, try putting PasswordReset after all the other extensions in LocalSettings.php (if that doesn't work, give me the name of the exensions and I'll figure it out)
 * Tim Laqua talk 08:13, 13 December 2007 (UTC)
 * UPDATE - grab the SVN version again - r28436 defines the hook a little differently. Now, putting PasswordReset after the other extensions in LocalSettings.php really should resolve the problem if it's related to timing.

Bug report: several undefined PHP variables

 * PHP Notice: Undefined variable: newpass in mediawiki\\extensions\\PasswordReset\\PasswordReset_body.php on line 86
 * PHP Notice: Undefined variable: confirmpass in mediawiki\\extensions\\PasswordReset\\PasswordReset_body.php on line 91
 * PHP Notice: Undefined variable: validUser in mediawiki\\extensions\\PasswordReset\\PasswordReset_body.php on line 97
 * --Y.combarnous 15:27, 7 December 2007 (UTC)
 * Fixed in r28249. Tim Laqua talk 16:24, 7 December 2007 (UTC)