Red Hat Bugzilla – Bug 1304732
Inconsistent CLI options for modifying user email
Last modified: 2018-06-19 09:30:49 EDT
Description of problem:
The "--email" option used with "ipa user-mod" (or "ipa stageuser-mod") modifies the specified user's email:
ipa user-mod user_login --firstname.lastname@example.org
However, when modifying the email with the "--addattr" option, "--addattr=email" doesn't work. The "--addattr=mail" option must be used for the operation to succeed:
ipa user-mod user_login --email@example.com
The current behavior can be very confusing, especially because help commands (such as "ipa user-mod -h") don't mention that the "mail" option even exists.
This is working as designed. When using *attr you use the actual LDAP attribute name which in this case is mail. The option names were chosen to be more human-readable equivalents.
Yes Rob, but the main point is that it is confusing.
In a different conversation I proposed e.g. new options for multivalued attributes. E.g:
So that users can avoid using --addattr and --setattr which are low level
I bet there is already some trac ticket filed by Honza.
That's fine but it doesn't make this bug any more valid. The *attr options specifically require LDAP attributes in order to provide the most possible flexibility to administrators so they don't have to resort to ldapmodify.
If an attribute can be multi-valued but is not defined as such in the IPA param then that is a separate bug. The fact that you can add them at all is a testament to the flexibility of *attr.
And note that if you try to do IPA param name -> attribute mapping then you are just creating a whole new test matrix. Better to keep it simple.
Rob, I understand that the tools are working as designed. I didn't file this bug because I thought that the design is wrong; I filed it because I think there is a usability problem. How can a regular user figure out that they have to use "email" in one case and "mail" in another? I only found out by accident.
I've already added a note to the official documentation about this, but modifying the tools so that they behave in a consistent and predictable way would be a much better solution.