So I guess it depends on if you are looking at this to mean
last-time-password-was-reset
or
last-time-password-was-changed

Well, after looking at the reset code, 'lastResetTime' isn't really even "last time password was reset", it's "last time the reset period was started" (it only gets reset when $hoursSinceLastReset > $resetHours). Not a huge difference, but it's still slightly misleading as-is (at least as far as the tooltip in the backend is concerned).

I was just surprised, because my assumption had always been that this value in the user manager was showing when the password was last changed. I only noticed that it wasn't when helping a client write some code to force changes after X months. And I suspect that a lot of folk have the same assumption, until they actually take a closer look.

I can understand why you might not want to reset it on a normal password reset, as that obviously isn't what the lastResetTime is intended for ... although i think the impact would be minimal if resetCount isn't changed. One could just look at it as restarting the reset timer.

It'd just be nice to actually have some notion of when a password was last changed, by whatever mechanism.

Oppose to abusing existing functionality. The lastResetTime is about lost password requests. Within a configurable time interval the amount of requests can be limited. Nothing to do with actually changing the password itself.

Appreciate the requirement to manage changing the password, regardless of how it was done. Or maybe not regardless how it was done. Anyway that would require different indicators. Would consider it bad practise to abuse the lost password reset request as last password change.
There are several aspects about password changes to be considered:

• done from the frontend or backend
• done by the user itself or an administrator
• done by user on own initiative or forced by administrator
• done due to loosing / not remembering

@sovainfo - yup, I agree (which is why I pretty much said it was a bad idea in my last comment). When I submitted the issue, I was simply looking at the "Last Reset" indicator in the user manager. Which, it turns out, has nothing to do with the password being reset. That time is just when the last reset period started - and is set when a password reset request is made, NOT when the password is reset through the request mechanism. So that date is set regardless of whether the user actually changed their password. Which, I suspect, is not what most admins think it is, reading the tooltip.

I think what we need is a new user param, which actually tracks the last change, made through any mechanism (lost request, front end, back end).

I'm happy to do that and submit a PR, if people think it's something that would get merged.

What is the use case for having this new option?

Simply to allow admins and 3rd party code to figure out when a password was last changed. Yes, could be done with a system plugin on onUserAfterSave and maintaining a separate table for it, but just seems like something that should be baked in.

I'm not religious about it, I just have several clients who want to implement a "force password change every X months" regime, and I was surprised that it wasn't already something J! keeps track of. So while I'm doing this for them, I thought it might be something I could usefully add to J!.

Sounds like a good new feature to me

"force password change every X months/days"

if can be enabled/disabled

Personally I'm not a bg fan of forcing password changes. There's a growing body of evidence to suggest that it actually makes passwords less secure. But my client wants it, so I'm not arguing.

However, regardless of whether it's used to force changes, knowing when someone last changed a password is a (mildly) useful feature.

Do you have code for that to send a pull request?

I am closing this at this time as the original question has been answered. Hopefully a pull request is forthcoming for the suggested new feature