286815 - LDAP addrbook search string should be configurable

Status: NEW

(MailNews Core :: LDAP Integration, defect)

Description

[Quanah Gibson-Mount]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1

Please read the above website.  Thunderbird's addressbook would be an amazing
and useful feature if it could be designed to actually integrate with a
directory server properly.

Reproducible: Always

Steps to Reproduce:
Start the address book
create access to a directory server with a custom schema, requiring SASL mechs,
and where you want data besides "cn" and "mail" to be populated into the
Addressbook.  Better yet, where you want the person's name to come from the
"displayName" attribute rather than CN.
Actual Results:  
It won't work, of course.  The LDAP support is minimal.

Expected Results:  
See the web page listed.

Feel free to email me if you have questions.

Comment 1

[Richard L. Goerwitz III]

Quick addendum, re handling of the 'cn' attribute in LDAP.

Please note RFC 2256.  Here's an excerpt:

   5.4. cn

   This is the X.500 commonName attribute, which contains a name of an
   object.  If the object corresponds to a person, it is typically the
   person's full name.

    ( 2.5.4.3 NAME 'cn' SUP name )

It's difficult to understand why searches generated by Thunderbird make
no use of the 'cn' or 'commonName' attribute.

There are some LDAP services (mainly network OS back ends) that make use
of 'cn' for other purposes (e.g., as a UID), but it's hard to see why
these implementations should essentially ruin name searches for sites that
have things set up by the book.

Anyway, as noted by the person who started this thread, a lot of these
sorts of problems would be fixed if Thunderbird was more flexible and
not reliant on a fixed schema.

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

As far as I can tell, this describes three different bugs.  The fixed schema problem is no longer present as of Thunderbird 1.5, since preferences can be used to map attributes.  I propose we use this bug to track the search filter issue, and that another bug be filed for SASL support.  Sound reasonable?  I suspect that bug 308118 should be made to depend on the SASL bug.

Comment 3

[Quanah Gibson-Mount]

Yes, an additoinal bug to track the SASL issue sounds good to me.

--Quanah

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #1)
> It's difficult to understand why searches generated by Thunderbird make
> no use of the 'cn' or 'commonName' attribute.
> 
> There are some LDAP services (mainly network OS back ends) that make use
> of 'cn' for other purposes (e.g., as a UID), but it's hard to see why
> these implementations should essentially ruin name searches for sites that
> have things set up by the book.

This is being discussed in bug 323608.

SASL auth has been spun off into bug 325396.

Quanah, given that we now support configurable attributes, how about upgrading us from an F?

Comment 5

[Mark Banner (:standard8)]

(In reply to comment #2)
> I propose we use this bug to track the search filter
> issue, and that another bug be filed for SASL support.

Given that this bug is being used to track the search filter issue, it certainly isn't a critical issue downgrading to normal based on the descriptions at https://bugzilla.mozilla.org/page.cgi?id=fields.html#bug_severity

Comment 6

[:aceman]

What is missing in this bug?
I read in another bug that the Ab search on LDAP uses the mail.addr_book.quicksearchquery.format search query. And adapts the field names to LDAP fields using some LDAP translation also in prefs.