*** Bug 89758 has been marked as a duplicate of this bug. ***

It's worse than that -- you don't actually have to change a group or anything.
Just double click a user to open their userProperties window, and press okay,
and the max password lifetime field will get set to zero if it was previously 99999.

Here's what's going on: redhat-config-users has a check to see if password
expiration is enabled. It does this by checking if both the password minimum
lifetime and the password expiration warning time are set to anything but -1.

If either of these has a different value -- and a different value is the
/etc/login.defs default -- then it considers password expiration to be enabled.
It also checks the password invalid field, but for some reason that I'm not
clear on, this value can be either -1 or empty and either way, password
expiration is considered active. (Not sure why this one is different -- the code
in userProperties.py is the same as the others.) 

In each case, whenever the value is other than -1, the corresponding field in
the password info tag is filled out with that value. If it *is* -1 (or null, in
the case of invalid-days), it gets left at the default value of '0'.

But then, it does something strange. It tries to make a fourth check, this time
to see if password max lifetime is anything but 99999. In other words, the
intention to disable password expiration if the four fields are set to
-1:99999:-1:-1. Here's the flaw, though: when the value is the magic number
99999, the form field is never filled in! It's left at its default value of 0!

This is fine when all the other fields are -1, since then password expiration is
considered disabled, the form is greyed out, and nothing happens. But if the max
lifetime *is* 99999 but any of the other fields are set, the form gets activated
but the 99999 is written as 0, and then written out that way. Ooops!

I tried changing the login.defs entries for PASS_MIN_DAYS and PASS_WARN_AGE to
-1 as a workaround, but this doesn't work since that just causes the fields to
be null. However, setting the default PASS_MAX_DAYS to 99998 *does* work, albeit
in a sort of silly way. Of course, I'm not suggesting that kludge as a solution
-- the right thing to do is to separate the filling out of the form fields from
the logic to decide if expiration is active. (First decide, then set the form.)

Created attachment 91549 [details]
moves form-fill to after is-expire-enabled check

Should be fixed in redhat-config-users-1.1.17-1.  Long term, the UI in this
notebook tab should be improved, but this fix should work in the meantime.

*** Bug 101463 has been marked as a duplicate of this bug. ***

*** Bug 91452 has been marked as a duplicate of this bug. ***