Closed
Bug 343011
Opened 18 years ago
Closed 18 years ago
Searching Organization from LDAP address book yields no results
Categories
(MailNews Core :: LDAP Integration, defect)
MailNews Core
LDAP Integration
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: atbrotman, Assigned: standard8)
Details
(Keywords: fixed1.8.1.2)
Attachments
(1 file)
1.10 KB,
patch
|
Bienvenu
:
review+
Bienvenu
:
superreview+
mscott
:
approval-thunderbird2+
|
Details | Diff | Splinter Review |
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•18 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•18 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•18 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•18 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•18 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•18 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•18 years ago
|
||
Fixes the company and organization default prefs as per the above comments.
Attachment #246708 -
Flags: superreview?(bienvenu)
Attachment #246708 -
Flags: review?(bienvenu)
Comment 8•18 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•18 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•18 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•18 years ago
|
Attachment #246708 -
Attachment description: Patch v1 → Patch v1 (checked in on trunk)
Updated•18 years ago
|
Attachment #246708 -
Flags: approval-thunderbird2? → approval-thunderbird2+
Updated•18 years ago
|
Flags: blocking-thunderbird2? → blocking-thunderbird2+
Assignee | ||
Comment 11•18 years ago
|
||
Fixed on 1.8 branch as well as trunk now.
Assignee | ||
Updated•18 years ago
|
Attachment #246708 -
Attachment description: Patch v1 (checked in on trunk) → Patch v1 (checked in on trunk and 1.8 branch)
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•