Fixes #4443 - Fix reporting for user without password on userManagementv...

[nperron]

Fixes #4443 - Fix reporting for user without password on userManagementv2.0

cf http://www.rudder-project.org/redmine/issues/4443

[nperron]

The ifvarclass become difficult to read...
To understand the change, i've used another way of display.
Before:

(
  (!usermanagement_user_password_ok_${usergroup_user_index}.!usermanagement_user_password_repaired_${usergroup_user_index}.!usermanagement_user_password_failed_${usergroup_user_index})
  .usermanagement_user_pwoneshot_${usergroup_user_index}.usermanagement_user_exists_${usergroup_user_index}
)
|usermanagement_user_remove_${usergroup_user_index}

After:

(
  (!usermanagement_user_password_ok_${usergroup_user_index}.!usermanagement_user_password_repaired_${usergroup_user_index}.!usermanagement_user_password_failed_${usergroup_user_index})
  .(usermanagement_user_pwoneshot_${usergroup_user_index}.usermanagement_user_exists_${usergroup_user_index})
  |usermanagement_user_pwempty_${usergroup_user_index}|
  (usermanagement_user_update_${usergroup_user_index}.!usermanagement_user_exists_${usergroup_user_index})
)
|usermanagement_user_remove_${usergroup_user_index};

For empty password I've added usermanagement_user_pwempty_${usergroup_user_index}
For user who can't be updated since they don't exist, I've added (usermanagement_user_update_${usergroup_user_index}.!usermanagement_user_exists_${usergroup_user_index})

This is based from the PR #441

[peckpeck]

I've check the logic of the ifvarclass, it matches your comment.
However I 'm not sure we should issue a success report if we can't update a user that don't exist.

[jooooooon]

I'm not sure about the full logic (I didn't re-read the full technique, sorry) but the report that is changed here says "The user password change is not required".

I think this can in fact be two different cases:

1. The password should be set but it is already OK - that is the definition of "success"
2. We don't need to check the password for some reason (it's not configured, the user account doesn't exist, etc...) - that is the definition of the "result_na" report type.

Maybe we should be implementing two cases here?

[ncharles]

Caution, result_na appeared only in Rudder 2.10 !

[peckpeck]

Ticket already rejected