Hi Noriko, Thank you for your patch. The patch you provided does take into account the modRDN with new superior but it does not seem to take care of subtree renames (smth like rename "ou=users" to "ou=utilisateurs" with child entries). For subtree renames all the entries in the renamed subtree change their DNs so for each of these renamed entries we have to make the search "slapi_search_internal_set_pb(search_result_pb, search_base, LDAP_SCOPE_SUBTREE, filter, attrs..." with a different filter. So for each modrdn we should verify if the renamed entry has any child entries and if it is the case then treat them either directly or recursively... As for the modrdn with newsuperior part i have a question : if newsuperior=NULL you take the parent of the original entry slapi_dn_find_parent(origDN) (btw, i haven't found this function in RHDS plug-in documentation). What does this function return for the base suffix? Or any rename/move operations are forbidden for the suffix? 2010/1/26 Noriko Hosoi <nhosoi@xxxxxxxxxx>: > https://bugzilla.redhat.com/show_bug.cgi?id=557224 > > Description of problem: > Analysis by andrey.ivanov@xxxxxxxxxxxxxxxx >> I'm pretty sure the referential integrity plug-in will not work for >> modrdn operations with a new superior. Looking more thoroughly through >> the code ( ldap / servers / plugins / referint / referint.c) confirms >> my suspicion that new rdn superior is not taken into account. The >> function referint_postop_modrdn extracts from the parameter block >> only SLAPI_MODRDN_TARGET and SLAPI_MODRDN_NEWRDN, it does not extract >> SLAPI_MODRDN_NEWSUPERIOR neither passes it further down the utility >> functions - update_integrity(argv, dn, newrdn, logChanges) and >> writeintegritylog(argv[1],dn, newrdn). The same applies to the delayed >> referint operations (the plug-in writes to the special integrity log >> file only the old DN and the new RDN, but never the new superior : >> writeintegritylog(argv[1],dn, newrdn);) > > Another thought on the subject of referential integrity plug-in - in > the previous mail i have only mentioned one-entry renames with a new > superior. The things get even worse when we rename a whole non-empty > sub-tree. It means that the referential integrity plug-in should > change to the new DNs all the references to all the entries of the > whole sub-tree, not only for one entry. > > And what if we rename a sub-tree containing both the referenced entry > and the entry referencing the first one's DN in one of its "integrity" > attributes? It actually means that we need at first make the rename > and then all the searches and replacements. Though it seems it's > already the case as it's a post-op(?) plug-in... > > Fix Description: The referential integrity plugin has not supported > the subtree rename (modrdn with newsuperior). This patch is adding > the support. > > Created an attachment (id=386896) > git patch for ldap/servers/plugins/referint/referint.c > > -- > 389-devel mailing list > 389-devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/389-devel > -- 389-devel mailing list 389-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-devel