In _password_policy_constraints_validate() within password_policy.module, we have the following at ~213:


  // Force failure.
  $force_failure = FALSE;

  if ($roles != $original_roles && $form_state->getValue('pass') == '' && !empty($applicable_policies)) {
    // New role has been added and applicable policies are available.
    $force_failure = TRUE;
  }

This prevents someone who can administer users (and permissions, to be able to assign roles) from editing another user without setting them a new password, even if the role changes do not result in new policies being needed.

I can understand that if a user has a new role, they may have a new policy that requires a different password but if you are editing another account, I would have thought you shouldn't have to set their password at that time?

This is causing me an issue in combination with the roleassign module (along with another issue which I have a patch for), but it also affects core.

Would it not be better to:

1) If the current user is the same account being edited & the roles have changed, force a failure.
2) If the current user is not the same account being edited but there are applicable policies, then expire the password so the user is forced to change it on next log in
3) If possible: Check whether the change in roles results in a different set of applicable policies. If so, then perform either of the above or keep the current functionality.

Just wondering why this failure is forced, as to how I can go about resolving it.

Cheers

Comments

smaz created an issue. See original summary.

vegantriathlete’s picture

One workaround is that instead of adding / removing roles from the user account edit interface, do it through the people administration interface. Select the account to which you want to add or remove a role and then use the Actions dropdown.

Joachim Namyslo’s picture

Anotherone is to use drush urole

moshe weitzman’s picture

Status: Active » Closed (duplicate)