Closed Bug 343011 Opened 16 years ago Closed 16 years ago

Searching Organization from LDAP address book yields no results


(MailNews Core :: LDAP Integration, defect)

Not set


(Not tracked)



(Reporter: atbrotman, Assigned: standard8)


(Keywords: fixed1.8.1.2)


(1 file)

User-Agent:       Opera/9.00 (Windows NT 5.1; U; en)
Build Identifier: version (20060516)

Using the Advanced Search of the address book in thunderbird, in the list of fields there is "Organization", but searching on this field does not work.  I've only tested this with an LDAP address book.  Assume you have "Abrotman, LLC" for the Organization name and you go to Edit->Search Addresses, and in the drop down and choose "Organization", and "contains" and type in "abr" and then hit the search button.  There are no results, and there should be at least one.

Reproducible: Always

Steps to Reproduce:
1. Create LDAP entry with an Organization (i used organizationName)
2. Use the advanced find to search for it
3. Watch very carefully as it displays no results

Actual Results:  
there are none, that's the problem.

Expected Results:  
It should display the entry which uses "Abrotman, LLC" and any others containing "abr".
If you go into the preferences, and find the Advanced Configuration Editor, change the preference ldap_2.servers.default.attrmap.Company from "company,o" to "o,company". Then restart Thunderbird and try again - does that fix it?

If so, then we either need to change the default (because the standard attribute to use for organizations according to core.schema in openLDAP and rfc2256 is 'o' rather than 'company') or to fix bug 310103 - LDAP search should use all attributes, or both.

Dan - comments?
Ever confirmed: true
Yes, altering the order does work.  If you alter the order/search all, would this be a fix in the next major release?
Looking at this the following two preferences:

pref("ldap_2.servers.default.attrmap.Department", "department,departmentnumber,ou,orgunit");
pref("ldap_2.servers.default.attrmap.Company", "company,o");

Don't match the schema we've published at

As "o" and "ou" are both defined in core.schema, and the others aren't I think we should be putting them first in the list so that we use them by default.

I'd have liked Dan's input on this but he's away for a couple of weeks. I'm reasonably happy to put a patch in without asking Dan (but would prefer to). Scott - what's the timeframe for getting this in before thunderbird 2? Would we be able to grab Dan before he gets back?
Assignee: mscott → bugzilla
Flags: blocking-thunderbird2?
OS: Windows XP → All
Hardware: PC → All
Dan agrees that we should change the preferences from:

pref("ldap_2.servers.default.attrmap.Company", "company,o");


pref("ldap_2.servers.default.attrmap.Company", "o,company");

So that the default preference would mean that we look up (and possibly store when that's implemented) against the attribute name given in our ldap schema first (which is based on core.schema which defines o and ou). cc'ing Mark and Rich in case they have any comments.
Component: Address Book → MailNews: LDAP Integration
Product: Thunderbird → Core
QA Contact: address-book → ldap-integration
Version: unspecified → Trunk
I agree that favoring o and ou makes sense, since those are commonly used attributes.  TBird should try to use the most common schema "out of the box" and be configurable to accommodate whatever schema people are using.
The cn attribute is used for this as well, especially in MS Active Directory:
cn=Users,dc=domain,dc=com instead of the usual ou=People.
Fixes the company and organization default prefs as per the above comments.
Attachment #246708 - Flags: superreview?(bienvenu)
Attachment #246708 - Flags: review?(bienvenu)
Comment on attachment 246708 [details] [diff] [review]
Patch v1 (checked in on trunk and 1.8 branch)

thx,  Mark
Attachment #246708 - Flags: superreview?(bienvenu)
Attachment #246708 - Flags: superreview+
Attachment #246708 - Flags: review?(bienvenu)
Attachment #246708 - Flags: review+
(In reply to comment #6)
> The cn attribute is used for this as well, especially in MS Active Directory:
> cn=Users,dc=domain,dc=com instead of the usual ou=People.
I think we'd need to deal with that separately. Possibly adding cn to the department pref. The users can always override the prefs on a per-directory basis anyway. 
Comment on attachment 246708 [details] [diff] [review]
Patch v1 (checked in on trunk and 1.8 branch)

Requesting approval on this patch. Simple low risk patch that corrects the search order preferences so that those that are normally used in schemas are defined first and therefore we search correctly for company & department especially when using our alpha schema.
Attachment #246708 - Flags: approval-thunderbird2?
Attachment #246708 - Attachment description: Patch v1 → Patch v1 (checked in on trunk)
Attachment #246708 - Flags: approval-thunderbird2? → approval-thunderbird2+
Flags: blocking-thunderbird2? → blocking-thunderbird2+
Fixed on 1.8 branch as well as trunk now.
Closed: 16 years ago
Keywords: fixed1.8.1.2
Resolution: --- → FIXED
Attachment #246708 - Attachment description: Patch v1 (checked in on trunk) → Patch v1 (checked in on trunk and 1.8 branch)
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.