Password Policy module not forcing force password change

A bit late now, but any update?

i think i have run into a similar issue. i have two sites almost identical in setup, it works on one and doesnt work in other. the force_password_change value is 1 in database (user.data), but when i try dpm(user_load()), this variable is on 0 . Any suggestions would be highly appreciated :) thanks.

scenario :

1. user is created but not activated, gets the value force_password_change= 1
2. admin loads the user edit form, sees the " Force password change on next login" checked, activates the user
3. the value force_password_change is set to 0 while saving
4. user gets an activation email, logs in, but is not forced to change the password

i think all this is because of this piece of code (function password_policy_user) :

   case 'update':
     if ($account->force_password_change) {
       db_query('UPDATE {password_policy_force_change} SET
force_change = 0 WHERE uid = %d', $account->uid);
     }
     elseif (!empty($edit['force_password_change'])) {

it sounds to me that it is somehow assumed , that the first change is done by the user herself. I guess adding a check for that could help (&& $user->uid == $account->uid.

I am not sure thogh how it was ment, if someone confirms i can make a patch.

Here's my pass at a change. What I think really should be checked is that a user, more specifically than just updating their profile, is updating their password specifically. This should take care of that change.

committed

I ported the patch to 7.x-1.x branch.

I recently updated the tests for Drupal 7. For more recent versions of Drupal, the test to check whether an administrator could force their own account to require a password change is failing.

The issue appears to be related to the port of this patch committed in Comment #8 above. From what I can tell, the steps necessary to check whether a password has been updated changed a bit between Drupal 7.0 and 7.1 due to #999004: user_save() relies on $edit instead of $account.

I'm attaching a patch that fixes the issue, by comparing the current and original passwords associated with the account when deciding whether to toggle the force_change field off. This fixes the one currently remaining failing test.

Committed