Full_Name: Patrick Hemmer Version: 2.4.31 OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (98.211.220.204) The issue is that if the entry being dynamically added to the parent entry has the objectClass slapo-dynlist is configured to use (to determine expansion), that entry is not dynamically added to the parent. For example: ---- dn: olcOverlay={4}dynlist,olcDatabase={3}hdb,cn=config objectClass: olcDynamicList objectClass: olcOverlayConfig olcOverlay: {4}dynlist olcDlAttrSet: {0}labeledURIObject labeledURI ---- dn: cn=parent,dc=example,dc=com objectClass: groupOfNames objectClass: top objectClass: labeledURIObject cn: parent member: uid=foo,dc=example,dc=com labeledURI: ldap:///cn=child,dc=example,dc=com??base?(objectClass=*) dn: cn=child,dc=example,dc=com objectClass: groupOfNames objectClass: top objectClass: labeledURIObject member: uid=bar,dc=example,dc=com cn: child ---- In the above example, I would expect "member: uid=bar,dc=example,dc=com" to be added to cn=parent,dc=example,dc=com, but it isn't. Now the documentation clearly states recursion is not allowed, so if cn=child were to have a 'labeledURI', this labeledURI would not be expanded. But this is not what is being done here, cn=child has no labeledURI present. It also behaves perfectly fine if I pull the "objetClass: labeledURIObject" off cn=child. ldapsearch with objectClass labeledURIObject present on cn=child: ---- dn: cn=parent,dc=example,dc=com objectClass: groupOfNames objectClass: top objectClass: labeledURIObject cn: parent member: uid=foo,dc=example,dc=com labeledURI: ldap:///cn=child,dc=example,dc=com??base?(objectClass=*) ---- ldapsearch without objectClass labeledURIObject present on cn=child: ---- dn: cn=parent,dc=example,dc=com objectClass: groupOfNames objectClass: top objectClass: labeledURIObject cn: parent cn: child member: uid=foo,dc=example,dc=com member: uid=bar,dc=example,dc=com labeledURI: ldap:///cn=child,dc=example,dc=com??base?(objectClass=*) ----
moved from Incoming to Software Bugs
As documented recursion is not supported
I think you might have missed the second half of the issue. ======== Now the documentation clearly states recursion is not allowed, so if cn=child were to have a 'labeledURI', this labeledURI would not be expanded. But this is not what is being done here, cn=child has no labeledURI present. It also behaves perfectly fine if I pull the "objetClass: labeledURIObject" off cn=child. ldapsearch with objectClass labeledURIObject present on cn=child: ---- dn: cn=parent,dc=example,dc=com objectClass: groupOfNames objectClass: top objectClass: labeledURIObject cn: parent member: uid=foo,dc=example,dc=com labeledURI: ldap:///cn=child,dc=example,dc=com??base?(objectClass=*) ---- ldapsearch without objectClass labeledURIObject present on cn=child: ---- dn: cn=parent,dc=example,dc=com objectClass: groupOfNames objectClass: top objectClass: labeledURIObject cn: parent cn: child member: uid=foo,dc=example,dc=com member: uid=bar,dc=example,dc=com labeledURI: ldap:///cn=child,dc=example,dc=com??base?(objectClass=*) ----
(In reply to openldap@stormcloud9.net from comment #3) > I think you might have missed the second half of the issue. > > ======== > > Now the documentation clearly states recursion is not allowed, so if cn=child > were to have a 'labeledURI', this labeledURI would not be expanded. But this > is > not what is being done here, cn=child has no labeledURI present. Irrelevant. > It also > behaves > perfectly fine if I pull the "objetClass: labeledURIObject" off cn=child. Yes, because it is the objectClass: labeledURIobject that is checked to determine whether a recursive query is occurring or not.