Updating password through the password reset link fails to update the last updated date in the user's account

[Susan Morrison]

3.10

When users update their password with the link provided by the Send Password Reset Link function in the staff client, the Last Updated date does not update in their account. (If users reset their password through the OPAC, or if it's updated in their account in the staff client, the Last Updated date does update in their account.) I don't know the technical jargon for this, but it appears that with the link the password reset is happening "outside" of the account so it's not logging the update. Once the password is reset through the link, you then get a prompt to log in to your account.

Use case:
A Local Admin staff member is requiring that all staff update their Evergreen passwords and is sending each staff member the password reset email through their account. The Local Admin would like a way to track that the password has been reset, and the Last Updated date would be a good indicator.

[Galen Charlton (gmc)]

Noting that while awaiting a change to the code, an SQL report on actor.passwd.edit_date will reliably indicate the last time that the password was updated. (Emphasis is on SQL here; the actor.passwd table is intentionally not made available to the Reporter to avoid risking mass exposure of (salted, hashed) passwords).

[Galen Charlton (gmc)]

And thinking aloud, while I think it makes sense to update actor.usr.last_update_time when the password is changed, that won't be a perfectly precise signal of when the password was last changed, as some other update to the patron record might have happened instead.

Consequently, I think it would be useful to _also_ do the following:

[1] Make the password's last edit time available in the patron editor or view
[2] Create a view on actor.passwd that omits the salt and password hash that can be used for reporting on metadata about the password, particularly the password type and the dates.