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

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

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)