339330 - LDAP "directory server properties -> Advanced" doesn't work

Status: RESOLVED DUPLICATE of bug 124553

(Thunderbird :: Address Book, defect)

Description

[Jon Warbrick]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3
Build Identifier: version 1.5.0.2 (20060308)

None of the settings in the Advanced tab of Directory server properties seem to do anything. In particular the search filter (default '(ObjectClass=*)') doesn't seem to be used in constructing the query sent to the LDAP server.

This makes some useful custon configurations impossible to specify.

Reproducible: Always

Steps to Reproduce:
1. Configure an LDAP addressbook; check this works
2. Reconfigure the directory by going to the 'Advanced' configuration tab and change any of the values - e.g. specify (ObjectClass=teapot) as a search filter

Actual Results:  
Subsequent searches are unaffected by any and all such changes

Expected Results:  
In the case of (ObjectClass=teapot) you'd probably expect no results (unless your LDAP directory really contains teapot objects :-). Setting 'Don't return more than' to 1 doesn't prevent multiple entries being returned. Etc.

The LDAP server logs confirm that the seartch filter isn't being used.

Comment 1

[Mark Banner (:standard8)]

(In reply to comment #0)
> Steps to Reproduce:
> 1. Configure an LDAP addressbook; check this works
> 2. Reconfigure the directory by going to the 'Advanced' configuration tab and
> change any of the values - e.g. specify (ObjectClass=teapot) as a search filter
> 
> Actual Results:  
> Subsequent searches are unaffected by any and all such changes

Have you tried restarting Thunderbird between changing the values and doing a new search? Currently Thunderbird tends to not pick up changes without a restart.

Comment 2

[Jon Warbrick]

Ah! Ok, restarting Thunderbird does indeed cause Thunderbird to take note of the values in 'Search filter' (yippi!). Thanks for the hint.

It's still a bug, of course, just not the one I reported.

Comment 3

[Mark Banner (:standard8)]

This has been fixed for the next major versions of Thunderbird (3.x) by bug 124553, therefore marking as duplicate.