Full_Name: Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (79.223.44.49) I thought about this: http://www.openldap.org/lists/openldap-technical/201507/msg00035.html => slapo-constraint should not trigger the constraint if the old and valid RDN value is not changed with MODRDN operation with delold=0 when moving the entry beneath a new superior.
List message: When bulk-renaming entries in web2ldap I do *not* alter the RDN of the entry but also send delold: 0 in the MODRDN operation. IMO this is most minimal invasive approach. This works ok in most setups. But in a more strict setup (release 2.4.41) with slapo-constraint and constraints on the RDN's characteristic attribute those MODRDN requests trigger a constraint and fails with 'Constraint violation' although the RDN value is not changed. I can't tell whether this was different with older OpenLDAP releases. Even more strange: It works with delold: 1. So I could easily alter web2ldap's behaviour to send delold: 1. But I'm not sure whether that's the right general approach especially when thinking about all the other LDAP servers out there. So the question is: Is this an overzealous misbehaviour of slapo-constraint and should it be fixed therein?
Need information on what constraint(s) have been implemented that trigger the issue.