Periodically, in some environments, it is useful to confirm that users are really still at the email addresses they have provided. If Cryptpassword = "RESET" and a user attempts to log in, rather than indicating an incorrect password or permitting the login, redirect the user to a page that explains that they must reconfirm their account and allows them to get a password token emaile to them by merely clicking the "Submit" button.

For the record, note also bug 284570 and bug 284572. They could all share the same code, and offer different options from editusers.cgi: At next login, ask user foo@bar.com to: [ ] Change his password [ ] Change his email address [X] Check his account About this last option, note that if the user tries to log in using userA account, then it means that userA account is still active. ;) Something else I could imagine is if the user has opened a new account userB because he has a new email address but forgot he could update his email address for his account userA instead of creating a new one, then one interesting feature would be to merge both accounts, i.e. change all userA ID to userB ID, or vice versa. This way, he wouldn't need to have two email addresses (and this could facilitate clean user account deletion as there would be no reference to the old account, and so no referential integrity problem).

This needs a filter fix and a button in editusers.cgi to force an account to require reverification.

The trunk is now frozen to prepare Bugzilla 2.22. Enhancement bugs are retargetted to 2.24.

This bug is retargetted to Bugzilla 3.2 for one of the following reasons: - it has no assignee (except the default one) - we don't expect someone to fix it in the next two weeks (i.e. before we freeze the trunk to prepare Bugzilla 3.0 RC1) - it's not a blocker If you are working on this bug and you think you will be able to submit a patch in the next two weeks, retarget this bug to 3.0. If this bug is something you would like to see implemented in 3.0 but you are not a developer or you don't think you will be able to fix this bug yourself in the next two weeks, please *do not* retarget this bug. If you think this bug should absolutely be fixed before we release 3.0, either ask on IRC or use the "blocking3.0 flag".

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?". Then, either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2. This particular bug has not been touched in over eight months, and thus is being retargeted to "---" instead of "Bugzilla 4.0". If you believe this is a mistake, feel free to retarget it to Bugzilla 4.0.