feat(#9547): require password reset on first time login and admin password update

[Benmuiruri]

Description

Video showing password reset in action

Screen.Recording.2025-01-10.at.10.29.17.mov

Video showing permission enabling skipping password reset

Screen.Recording.2025-01-10.at.10.32.14.mov

Video showing api supports setting password_change_required: false for specific user

Screen.Recording.2025-01-10.at.10.44.23.mov

Video showing password change hint in admin app

Screen.Recording.2025-01-15.at.15.01.17.mov

Closes #9547

Code review checklist

• UI/UX backwards compatible: Test it works for the new design (enabled by default). And test it works in the old design, enable can_view_old_navigation permission to see the old design.
• Readable: Concise, well named, follows the style guide, documented if necessary.
• Documented: Configuration and user documentation on cht-docs
• Tested: Unit and/or e2e where appropriate
• Internationalised: All user facing text
• Backwards compatible: Works with existing data and configuration or includes a migration. Any breaking changes documented in the release notes.

Compose URLs

If Build CI hasn't passed, these may 404:

• Core
• CouchDB Single
• CouchDB Cluster

License

The software is provided under AGPL-3.0. Contributions to this project are accepted under the same license.

[Benmuiruri]

Hi @jkuester I resolved the feedback you gave me and this implementation is leaner than the previous one. It is now ready for review.

[jkuester]

This is coming together nicely! Couple additional comments/suggestions here.

I think my only remaining workflow-level question is if you think we need some kind of message in the admin app when changing a user's password that will alert the admin that the user will be prompted to change their password again? I am just concernd that we will still catch folks off guard with this functionality change... 🤔

[Benmuiruri]

Hi @jkuester Good point about adding a sort of warning. I came up with this

update.password.help = User will be prompted to reset password after login unless can_skip_password_change permission is enabled for the user role.

[jkuester]

@Benmuiruri Yes, that was exactly what I was thinking. Would it be possible to just hide it for users that have the can_skip_password_change permission? I would rather not mention the permission at all in the message and it seems it would be most helpful to just see it in the case where we know a password reset will be necessary. But, I am not sure if we have everything we need in context here to know which permissions the user is going to have...

[jkuester]

Fantastic! I had one minor suggestion about the update user code, but otherwise this is good to go!

[jkuester]

@Benmuiruri is there anything blocking us from getting this PR merged? Just want to be sure we don't accidentally miss the next cht-core release! 😅

[Benmuiruri]

Hi @jkuester thanks for the follow up.

I've pinged @PhilipNgari on the echis-ke repo to get clarification on merging it.

[jkuester]

@Benmuiruri I think we should go ahead and merge this. We have confirmed through broad and extensive discussion that this functionality is our intended path forward. Stakeholders have been made aware of the details of the changes. The can_skip_password_change permission provides instance administrators the ability to toggle off the behavior. This allows them the time/flexibility to update their administrative workflows as necessary. As I mentioned in the issue thread I think we all recognize this functionality as just being one piece to the whole user security puzzle, but we do not need to wait for all the pieces to be in place before releasing this one. (In fact, I think releasing this feature will make it easier to identify other features necessary to ensure user security.)

[PhilipNgari]

We raised the same issue again last week and it was put on hold. Given the @jkuester mention on the ability to "Toggle off" the functionality at the admin level, we can go ahead and merge but not deploy for eCHIS Kenya until the consumer Department at MoH gves a nod. I imagine its a similar concept to the new UI changes where they appear differently on both phone or laptop but can be toggled on or off.

We just need to be sure that it's harmonious across the instances so that this does not skip and deploy in some. cc @alexosugo

[andrablaj]

@Benmuiruri Per @PhilipNgari's comment above, could you please solve the conflicts and merge the PR, so this can be released in 4.17? Thank you!