Problem/Motivation
As things stand, the user edit form requests the current password to change the password. EXCEPT if there is a special value set in the session.
This is what the password reset link does when you follow it: it sets the special session token for 'don't ask current password'.
Detail
Steps to reproduce:
- Log off if necessary
- Request a new password
- Log back in with the old password [a]
- On receiving the password reset email, click on that link to log on [b]
- You are taken to the home page of the site, with a message "You are logged in as USERNAME. [LINK]Change your password[/LINK].
- Following the link takes you to the user edit form, which requires the current password if you enter a new one
Note that this requires 2 steps which don't seem terribly logical on the part of the user:
[a] Why would you request a new password, and then log in?
[b] Having logged in again, why would you click the link in the email?
Possible explanations include:
* the user was on the wrong machine or the wrong browser, and then remembered to switch to something that has their password stored.
* the user simply remembered it after requesting the reset
* the user is currently logged in, but is aware that they have forgotten their password, and wishes to reset it, and therefore goes to the site in a 2nd browser to get a password reset email sent to them, because that's the only way they know to reset their password without knowing the existing one.
Proposed resolution
add this token when user follows the password reset link AND they are logged in.
Remaining tasks
- Fix error (See #58 and #67
- manually test (once there is a new patch)
- add automated tests? (is this possible?)
- review 8.0.x
- commit 8.0.x
- backport to d7
User interface changes
A message when click the link.
API changes
No.