Bug 1304732

Summary: Inconsistent CLI options for modifying user email
Product: Red Hat Enterprise Linux 7 Reporter: Aneta Šteflová Petrová <apetrova>
Component: ipaAssignee: IPA Maintainers <ipa-maint>
Status: CLOSED WONTFIX QA Contact: Namita Soman <nsoman>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.2CC: pasik, pvoborni, rcritten
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-11-15 21:20:22 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Aneta Šteflová Petrová 2016-02-04 13:35:49 UTC
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 --email=user1

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 --addattr=mail=user2


Actual results:

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.

Comment 2 Rob Crittenden 2016-02-04 13:55:37 UTC
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.

Comment 3 Petr Vobornik 2016-02-04 14:33:25 UTC
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:
  --add-email
  --remove-email

So that users can avoid using --addattr and --setattr which are low level

I bet there is already some trac ticket filed by Honza.

Comment 4 Rob Crittenden 2016-02-05 07:40:55 UTC
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.

Comment 5 Aneta Šteflová Petrová 2016-02-05 09:46:35 UTC
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.

Comment 6 Petr Vobornik 2016-02-16 16:09:07 UTC
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/3054

Comment 9 Rob Crittenden 2018-11-15 21:20:22 UTC
Thank you taking your time and submitting this request for Red Hat Enterprise Linux. The request was cloned to the upstream tracker a long time ago (see link to the upstream ticket above), but it was unfortunately not given priority either in the upstream project, nor in Red Hat Enterprise Linux.

Given that this request is not planned for a close release, it is highly unlikely it will be fixed in this major version of Red Hat Enterprise Linux. We are therefore closing the request as WONTFIX.

To request that Red Hat reconsiders the decision, please reopen the Bugzilla with the help of Red Hat Customer Service and provide additional business and/or technical details about it's importance to you. Please note that you can still track this request or even offer help in the referred upstream Pagure ticket to expedite the solution.