Bug 429005 - Enhancement: ModifyDN with new superior feature
Summary: Enhancement: ModifyDN with new superior feature
Alias: None
Product: 389
Classification: Retired
Component: Directory Server
Version: 1.1.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
Depends On:
Blocks: 389_1.2.6 639035
TreeView+ depends on / blocked
Reported: 2008-01-16 18:57 UTC by Andrey Ivanov
Modified: 2015-12-07 16:45 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-12-07 16:45:27 UTC

Attachments (Terms of Use)

Description Andrey Ivanov 2008-01-16 18:57:37 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/20071127 Firefox/

Description of problem:
I was looking through the wishlist (http://directory.fedoraproject.org/wiki/Wishlist) and I haven't found in it the feature that would be rather useful: ModifyDN with new superior, in other words rename/move entry  outside the current ou.

It is necessary for  the management of  people entering and leaving  the organisation. For example, a student's entry during his studies is in the "ou=Students, ou=People,..." and when he/she leaves we need to move his/her entry to "ou=Alumni,ou=People,...". As for now, we have to make a script that reads all the attributes, deletes the original entry and then adds a new entry in the new "ou". So this feature would greatly simplify our life.

Version-Release number of selected component (if applicable):
Fedora Directory Server 1.1

How reproducible:

Steps to Reproduce:
N/A - enhancement request

Actual Results:
LdapModifyDNRequest to move entries, the answer is:

   Error: LDAPException: Unwilling To Perform (53) Unwilling To Perform
   LDAPException: Server Message: server does not support moving of entries
   LDAPException: Matched DN:

Expected Results:
LdapModifyDNRequest with new superior succesfully moves entries.

Additional info:
It is not a bug, it's a request for a feature.

Comment 1 Andrey Ivanov 2008-01-30 20:58:53 UTC
The thing that is really causing us troubles in using our remediating script
(the one that reads all the attributes, deletes the original entry and then adds
a new entry in the new "ou") is that it changes the nsUniqueId which is used in
turn as unique identifier for a person. So the feature "ModifyDN with new
superior" preserving the nsUniqueId is really important.

Comment 4 Andrew Bartlett 2008-05-09 11:11:42 UTC
We also need this (and full subtree renames) for Samba4.

Comment 5 François Beretti 2009-05-29 08:48:53 UTC
My company also needs this feature, as long as full subtree move/rename.
For the moment we use the displayName as the name of an entry in our GUI, which allows us to rename it (since it is not in the RDN) if it has subentries. But when using an LDAP browser and not our GUI, it's hard to identify our entries.

Comment 6 sliabat 2009-09-18 13:32:00 UTC
Why you don't implement this ldap V3 feature ?
It's a LDAP V3 feature, not a goodies.
OpenLDAP implement this feature and it's on road map of Fedora Directory server 1.3 ?

We need this ldap V3 functionnality.
Thanks in advance.

Comment 7 Noriko Hosoi 2010-01-22 23:46:57 UTC
Thanks to Andrey, Rich, and Nathan who reviewed and commented on the patch.

The change has been pushed to master.

I also put the latest patch here:
This patch includes
- replacing the entrydn index with the entryrdn index
- replacing a full DN in each entry in the DB with an RDN
- extending Slapi_Entry, entry2str, and str2entry to absorb the changes
  made on the entry
- adding DN/RDN helper functions
- adding DN cache
- adding a utility and a migration script to convert the DN format database
  to the RDN format
- extending a database dump utility dbscan to support the entryrdn
- slapi_dn_syntax_check by nkinder@redhat.com is added to check the dn before
  modify operations
- big fix for 171338 - Enhancement: winsync modrdn not synced

In addition to the above, compile warnings and memory leaks found in testing
the new feature are fixed.

For more details, see the feature design document at:

and bugzilla at:

Comment 8 Amita Sharma 2011-04-07 12:29:27 UTC
This is tested under subtree renaming test suit.
I am marking it as VERIFIED.

Note You need to log in before you can comment on or make changes to this bug.