Description of problem: Adding an Organizational unit from console throws netscape.ldap.LDAPException: error result (65). This happens when Alias field is filled with some values and then removed at the second attempt to add a new OU. Version-Release number of selected component (if applicable): How reproducible: Consistently with the steps mentioned here. Steps to Reproduce: 1. Open the Directory Sever console for an instance. 2. Click on Directory tab and right click on the suffix. 3. Select New Organizational Unit 4. Enter values as test in Alias(optional) field and Name(mandatory) field and click on "OK" 5. Netscape LDAP Exception error is displayed with invalid syntax error 21. 6. Click on OK to remove the values from "Alias" field and then click OK to add the Organization Unit. 7. This time, it throws error 65, Object class violation, missing attribute "aliasedObjectName" required by objectclass alias. Attaching a screenshot. Actual results: Objectclass violation error displayed. Builds tested: [root@ratangad ~]# rpm -qa |egrep -i '389-|^idm-' 389-ds-base-1.3.3.1-16.el7_1.x86_64 389-ds-console-1.2.12-1.el7dsrv.noarch 389-ds-console-doc-1.2.12-1.el7dsrv.noarch 389-ds-base-libs-1.3.3.1-16.el7_1.x86_64 idm-console-framework-1.1.13-1.el7dsrv.noarch 389-admin-1.1.40-1.el7dsrv.x86_64 389-admin-console-doc-1.1.10-1.el7dsrv.noarch 389-ds-base-debuginfo-1.3.3.1-16.el7_1.x86_64 389-admin-console-1.1.10-1.el7dsrv.noarch 389-admin-debuginfo-1.1.40-1.el7dsrv.x86_64 389-adminutil-debuginfo-1.1.22-1.el7dsrv.x86_64 389-adminutil-1.1.22-1.el7dsrv.x86_64 389-console-1.1.8-1.el7dsrv.noarch Expected results: No error should be displayed since the value is already removed from the field. Additional info:
Created attachment 1029955 [details] Objectclass violation error 65
Is this a regression? Nothing has changed in this area of the Console, so I would be surprised if this was new behavior.
This is not a regression. Its reproducible with DS9.1 version on RHEL6.6 too. Package versions on RHEL6.6 machine. [root@newsankarlapy ~]# rpm -qa |egrep '389-|^idm ' 389-adminutil-1.1.22-1.el6dsrv.x86_64 389-ds-console-1.2.7-1.el6.noarch 389-ds-base-libs-1.2.11.15-47.el6.x86_64 389-ds-1.2.2-1.el6.noarch 389-ds-base-devel-1.2.11.15-47.el6.x86_64 389-adminutil-devel-1.1.22-1.el6dsrv.x86_64 389-console-1.1.7-1.el6.noarch 389-admin-1.1.35-1.el6.x86_64 389-ds-base-debuginfo-1.2.11.15-56.el6.x86_64 389-ds-base-1.2.11.15-47.el6.x86_64 389-admin-console-1.1.8-1.el6.noarch 389-dsgw-1.1.11-1.el6.x86_64 389-ds-console-doc-1.2.7-1.el6.noarch 389-admin-console-doc-1.1.8-1.el6.noarch
Upstream ticket: https://fedorahosted.org/389/ticket/48187
Fixed upstream
Tested with the newer build of idm-console-framework-1.1.14-1 and its not reproducible. I added an entry by adding/deleting values for alias attribute. Then, I edited the OU and then added/removed the alias from the entry and successfully saved it. Hence, marking the bug as Verified. [root@dhcp35-196 schema]# rpm -qa |egrep '389-|idm-' 389-ds-base-1.3.3.1-16.el7_1.x86_64 389-admin-console-1.1.10-1.el7dsrv.noarch 389-admin-debuginfo-1.1.41-1.el7dsrv.x86_64 389-adminutil-1.1.22-1.el7dsrv.x86_64 389-ds-console-1.2.12-1.el7dsrv.noarch 389-admin-console-doc-1.1.10-1.el7dsrv.noarch 389-admin-1.1.41-1.el7dsrv.x86_64 389-console-1.1.8-1.el7dsrv.noarch 389-adminutil-debuginfo-1.1.22-1.el7dsrv.x86_64 redhat-idm-console-10.0.0-3.el7dsrv.x86_64 389-ds-console-doc-1.2.12-1.el7dsrv.noarch redhat-idm-console-debuginfo-10.0.0-3.el7dsrv.x86_64 389-ds-base-libs-1.3.3.1-16.el7_1.x86_64 389-ds-base-debuginfo-1.3.3.1-16.el7_1.x86_64 idm-console-framework-1.1.14-1.el7dsrv.noarch
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2015:1094