The memberOf attribute includes members that are directly in the group
via the "member" attribute and those that are included as a result of
being in a group that is in the group.
The UI needs to be able to distinguish between the two.
438706
This runs the risk of showing too much and confusing users but on the other
hand it often includes required information detailing why the error
occurred such as what attribute the user lacks write access too and why
changing a password failed.
438057
Fix group RDN changes
Remove a copy/paste error in the group UI update that caused 2 updates
Fix variable name so groups don't get user objectclasses
Remove color CSS for field backgrounds as they override disabled field display
This adds 2 new groups: activated and inactivated.
If you, or a group you are a member of, is in inactivated then you are too.
If you, or a group you are a member of, is in the activated group, then you
are too.
In a fight between activated and inactivated, activated wins.
The DNs for doing this matching is case and white space sensitive.
The goal is to never have to actually set nsAccountLock in a user directly
but move them between these groups.
We need to decide where in the CLI this will happen. Right it is split
between ipa-deluser and ipa-usermod. To inactivate groups for now just
add the group to inactivate or active.
to edit other users (the Edit link won't appear otherwise). Additional
delegation is need to grant permission to individual attributes.
Update the failed login page to indicate that it is a permission issue.
Don't allow access to policy at all for non-admins.
By default users can only edit themselves.
Rob Crittenden
Karl MacMillan
Kevin McCarthy