325314 - LDAP addrbook doesn't display results up to admin limit

Status: RESOLVED DUPLICATE of bug 297549

(MailNews Core :: LDAP Integration, defect)

Description

[Laurent Bauvens]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla Thunderbird 1.5 (20051201) FR_fr

User's view: In the PAB UI, when you make a query from a LDAP directory (ex:dupon), it will be select only few first records instead of a long list of records. You can change the number max of results in the ldap definition dialog, nothing change.
LAN's view: with Ethereal, I can see that ldap request abort with an "Administrative limit exceeded" error code.

** This behaviour is a regression because TB 1.0 works fine. **

Weird thing: address autocompletion works well in the new message UI!

Reproducible: Always

Steps to Reproduce:
1. Go to the Personal Address Book
2. Select a LDAP directory
3. Enter the first letters of a common name

Actual Results:  
Nothing happens or three or a little bit more first records were displayed on a possible list of records more wide

Expected Results:  
All the record list up to the limit must be displayed.

Remarks: 

A. The LDAP attribute list insert in a request is bigger than ever if i compare with attribute list of TB 1.0 or Communicator 4.7.

B. LDAP Directories are big components in the corporate IT environment and we aimed to deploy TB15 on 80.000 PC on 2006Q2 so it will be fine that this bug will be fixed in 1.5.1.

Thanks for your help

Comment 1

[Mark Banner (:standard8)]

Reporter,

This sounds like your problem could be a symptom of bug 323608, please have a read through that bug. Which ldap server do you use in your organisation?

Also it will probably help you if you tested out one of the latest branch builds. These have ldap logging enabled within them so you can see the transactions that are taking place and which searches are taking place. As we haven't yet changed much ldap wise on the branch since 1.5 was released, then you should be able to take any solutions back to 1.5 without any problems.

Information on where to find the builds and how to view the logging output may be found here:

http://wiki.mozilla.org/MailNews:LDAP_Address_Books#LDAP_Logging

Please comment here if you find a solution to your problem or your problem persists. Thanks.

Comment 2

[Laurent Bauvens]

(In reply to comment #1)

> This sounds like your problem could be a symptom of bug 323608, please have a
> read through that bug.

After being discussed with our internal support team, you're right, this bug must be linked with 323608.

> Which ldap server do you use in your organisation?

Netscape Directory Server 3.5 and Sun Directory Server 5.1.
And our LDAP trees doesn't contain any 'displayName' attribute.

Thanks


*** This bug has been marked as a duplicate of 323608 ***

Comment 3

[OOO until Apr 20; Dan Mosedale (:dmosedale, :dmose)]

While this behavior may have been triggered by the schema change, it looks to me as though this bug describes at least one completely separate issue: the addressbook code isn't smart enough to display results up to the limit.  

Additionally, it sounds as though it's also possible that the addressbook isn't sending the "max hits" parameter while searching.  If you could take a look with Ethereal, and file another bug if the addressbook is failing to send that, it would be very helpful.

Comment 4

[Laurent Bauvens]

(In reply to comment #3)
> While this behavior may have been triggered by the schema change, it looks to
> me as though this bug describes at least one completely separate issue: the
> addressbook code isn't smart enough to display results up to the limit. 

The request works well if, as says in bug 323608 comment #21, i replace "displayName,cn,commonname" by "cn,commonname" in the pref key.

> Additionally, it sounds as though it's also possible that the addressbook isn't
> sending the "max hits" parameter while searching.  If you could take a look
> with Ethereal, and file another bug if the addressbook is failing to send that,
> it would be very helpful.

Here below a frame which contains TB15 LDAP request aiming a Netscape Directory 4.0. The capture had been done before I change the pref key value. 

I suppose that "max hits" parameter is the "size limit" parameter in the request.

-----------------------------------------------------------------
Frame 8 (995 bytes on wire, 995 bytes captured)
Ethernet II, Src: 00:0b:db:cb:ff:c7, Dst: 00:09:6b:9a:20:58
Internet Protocol, Src Addr: xx.xx.xx.xx (xx.xx.xx.xx), Dst Addr: xx.xx.xx.xx (xx.xx.xx.xx)
Transmission Control Protocol, Src Port: 1254 (1254), Dst Port: xxx (xxx), Seq: 15, Ack: 15, Len: 941
Lightweight Directory Access Protocol
    LDAP Message, Search Request
        Message Id: 2
        Message Type: Search Request (0x03)
        Message Length: 930
        Response In: 10
        Base DN: o=cnamts,c=fr
        Scope: Subtree (0x02)
        Dereference: Never (0x00)
        Size Limit: 100
        Time Limit: 0
        Attributes Only: False
        Filter: (|(mail=*dupon*)(displayName=*dupon*)(givenName=*dupon*)(sn=*dupon*))
        Attribute: company
        Attribute: o
        Attribute: mail
        Attribute: street
        Attribute: streetaddress
        Attribute: postOfficeBox
        Attribute: mozillaUseHtmlMail
        Attribute: xmozillausehtmlmail
        Attribute: mozillaCustom2
        Attribute: custom2
        Attribute: mozillaHomeCountryName
        Attribute: department
        Attribute: departmentnumber
        Attribute: ou
        Attribute: orgunit
        Attribute: mobile
        Attribute: cellphone
        Attribute: carphone
        Attribute: telephoneNumber
        Attribute: title
        Attribute: mozillaCustom1
        Attribute: custom1
        Attribute: mozillaNickname
        Attribute: xmozillanickname
        Attribute: mozillaWorkUrl
        Attribute: workurl
        Attribute: fax
        Attribute: facsimiletelephonenumber
        Attribute: mozillaCustom4
        Attribute: custom4
        Attribute: nsAIMid
        Attribute: nscpaimscreenname
        Attribute: givenName
        Attribute: l
        Attribute: locality
        Attribute: homePhone
        Attribute: mozillaHomeUrl
        Attribute: homeurl
        Attribute: mozillaHomeStreet
        Attribute: st
        Attribute: region
        Attribute: mozillaHomePostalCode
        Attribute: mozillaHomeLocalityName
        Attribute: mozillaCustom3
        Attribute: custom3
        Attribute: birthyear
        Attribute: mozillaWorkStreet2
        Attribute: mozillaSecondEmail
        Attribute: xmozillasecondemail
        Attribute: mozillaHomeStreet2
        Attribute: postalCode
        Attribute: zip
        Attribute: c
        Attribute: countryname
        Attribute: pager
        Attribute: pagerphone
        Attribute: sn
        Attribute: surname
        Attribute: mozillaHomeState
        Attribute: description
        Attribute: notes
        Attribute: modifytimestamp
        Attribute: displayName
        Attribute: cn
        Attribute: commonname
-----------------------------------------------------------------

Comment 5

[Mark Banner (:standard8)]

> User's view: In the PAB UI, when you make a query from a LDAP directory
> (ex:dupon), it will be select only few first records instead of a long list of
> records. You can change the number max of results in the ldap definition
> dialog, nothing change.

Did you try restarting thunderbird in between changing the number of maximum results to return? There is a known bug where we don't update the connection if items in the ldap directory properites dialog are changed - we only will update the connection on a restart.

Comment 6

[Mark Banner (:standard8)]

(In reply to comment #5)
> > User's view: In the PAB UI, when you make a query from a LDAP directory
> > (ex:dupon), it will be select only few first records instead of a long list of
> > records. You can change the number max of results in the ldap definition
> > dialog, nothing change.
> Did you try restarting thunderbird in between changing the number of maximum
> results to return? There is a known bug where we don't update the connection if
> items in the ldap directory properites dialog are changed - we only will update
> the connection on a restart.

Nothing heard back about this, but I believe this is a duplicate of bug 297549