312945 - Add forced account reverification support

Status: NEW

(Bugzilla :: User Accounts, enhancement, P3)

Description

[Joel Peshkin]

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.

Comment 1

[Frédéric Buclin]

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 [e-mail] 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).

Comment 2

[Joel Peshkin]

Attachment: erik's initial functional patch -- needs some boilerplate

Comment 3

[Joel Peshkin]

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

Comment 4

[Frédéric Buclin]

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

Comment 5

[Frédéric Buclin]

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".

Comment 6

[Max Kanat-Alexander]

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.