Searching Organization from LDAP address book yields no results

RESOLVED FIXED

Status

MailNews Core
LDAP Integration
RESOLVED FIXED
11 years ago
9 years ago

People

(Reporter: Alex Brotman, Assigned: standard8)

Tracking

({fixed1.8.1.2})

Trunk
fixed1.8.1.2
Bug Flags:
blocking-thunderbird2 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
User-Agent:       Opera/9.00 (Windows NT 5.1; U; en)
Build Identifier: version 1.5.0.4 (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".
(Assignee)

Comment 1

11 years ago
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 2

11 years ago
Yes, altering the order does work.  If you alter the order/search all, would this be a fix in the next major release?
(Assignee)

Comment 3

11 years ago
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 http://wiki.mozilla.org/MailNews:LDAP_Address_Books

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
(Assignee)

Comment 4

11 years ago
Dan agrees that we should change the preferences from:

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

to:

pref("ldap_2.servers.default.attrmap.Department",
"ou,department,departmentnumber,orgunit");
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.
Status: NEW → ASSIGNED
Component: Address Book → MailNews: LDAP Integration
Product: Thunderbird → Core
QA Contact: address-book → ldap-integration
Version: unspecified → Trunk

Comment 5

11 years ago
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.

Comment 6

11 years ago
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.
(Assignee)

Comment 7

11 years ago
Created attachment 246708 [details] [diff] [review]
Patch v1 (checked in on trunk and 1.8 branch)

Fixes the company and organization default prefs as per the above comments.
Attachment #246708 - Flags: superreview?(bienvenu)
Attachment #246708 - Flags: review?(bienvenu)

Comment 8

11 years ago
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+
(Assignee)

Comment 9

11 years ago
(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. 
(Assignee)

Comment 10

11 years ago
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?
(Assignee)

Updated

11 years ago
Attachment #246708 - Attachment description: Patch v1 → Patch v1 (checked in on trunk)

Updated

11 years ago
Attachment #246708 - Flags: approval-thunderbird2? → approval-thunderbird2+

Updated

11 years ago
Flags: blocking-thunderbird2? → blocking-thunderbird2+
(Assignee)

Comment 11

11 years ago
Fixed on 1.8 branch as well as trunk now.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Keywords: fixed1.8.1.2
Resolution: --- → FIXED
(Assignee)

Updated

11 years ago
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.