Do not force customer to change the password when an agent has changed customer data via AdminCustomerUser

[hcamminadi]

Situation:

• PasswordExpiry is active (e.g. 90 days)
  An existing customer user has already signed in via customer.pl and changed the initial password. Afterwards an agent changes any data e.g. city or postal code via AdminCustomerUser. As the agent leaves the password field blank, the pw value is not overwritten in db.
  As customer_preferences preferences_key 'UserLastPwChangeTime' will be removed due to the agents action this will lead to another password change when the customer tries to log in the next time.

Suggestion:
Problem is that in AdminCustomerUser.prn DeleteOnePreference is called with key 'UserLastPwChangeTime' if the password did not match the old one. It would help if this action is skipped if the new password is empty as empty passwords will not be stored. If there are plans to allow an agent to empty an existing password this would not help.

The surrounding if in the next block is new and helps for me:

        if ($GetParam{UserPassword}) {
            if ( $CurrentUserData{UserPassword} ne $GetParam{UserPassword} ) {
                $UpdateSuccess = $CustomerUserObject->DeleteOnePreference(
                    Key    => 'UserLastPwChangeTime',
                    UserID => $GetParam{ID},
                );
            }
        }

[svenoe]

Hi hcamminadi,

thanks for your contribution. You are right, that this behavior should be changed. At the moment we do not yet totally support the customer preferences and password options. I think this here should be done as an addition to that general task, and I linked the issue to #750.

Best regards, Sven

[bschmalhofer]

When looking at the history of that code I found that code comment that might be interesting:

# Rother OSS - Reset Preferences UserLastPwChangeTime last login after password reset

Thus, when making changes it must be assured that resetting customer passwords still works.

[bschmalhofer]

@svenoe : Is this issue solved with #750?

[stefanhaerter]

Closed with merging #2532