The fix to ITS#4556 broke this test: modifying objectClass was forbidden

for anyone, and since LDAP additions now check for attribute write access,
the addition now fails.

Allowing objectClass write access for the user that performs the LDAP
addtition fixes the problem.

Approved by ando@

diff --git a/tests/data/slapd-acl.conf b/tests/data/slapd-acl.conf
index bfcabfc491e925741006cb83619712432f62bd0a..64cde948c73521677ea45d1c0cbe403cce2d69ee 100644 (file)
--- a/tests/data/slapd-acl.conf
+++ b/tests/data/slapd-acl.conf
@@ -55,6 +55,7 @@ rootpw                secret
 
 #access                to attrs=objectclass dn.subtree="dc=example,dc=com"
 access         to attrs=objectclass
+               by dn.exact="cn=Bjorn Jensen,ou=Information Technology Division,ou=People,dc=example,dc=com" add
                by * =rsc stop
 
 #access                to filter="(objectclass=person)" attrs=userpassword dn.subtree="dc=example,dc=com"