Open
Bug 241220
Opened 20 years ago
Updated 2 years ago
Use displayName attribute instead of cn for addresses from LDAP server
Categories
(MailNews Core :: LDAP Integration, defect)
MailNews Core
LDAP Integration
Tracking
(Not tracked)
NEW
People
(Reporter: mozbugzilla, Unassigned)
References
Details
If you have an LDAP server configured and type something into the to/cc/bcc lines of the compose window, Thunderbird returns LDAP matches in the form "cn <mail>". This is inconsistent with using the address book to query an ldap server, in which matches are returned as "name <mail>". To see this inconsistency properly, type a surname into the "Name or Email contains" field, then right click a result and select Write. In our organisation, cns are userids. This means that typing a surname into the to line ends up giving something like "maxspicer <max@company.tld>". Going via the address book gets it right - you end up with "Max Spicer <max@company.tld>". Using name instead of cn is definitely the better way to go. Either way, we should at least be consistent between the autocompletion and the address book. Bug 236471 covers similar ground to this, but is not a dupe.
Reporter | ||
Comment 1•20 years ago
|
||
Bother, I mean displayName, not name. Currently cn is used, displayName would be much better.
Summary: Display name attribute instead of cn for addresses from LDAP server → Use displayName attribute instead of cn for addresses from LDAP server
Comment 2•20 years ago
|
||
displayName seems to be the non-standard attribute, but this is what MicroSoft's Active Directory servers output. Mozilla's "Address Book" is smart enough to use it over cn, but the mail module is not :-( FWIW, I have filed a similar PR with KDE: http://bugs.kde.org/show_bug.cgi?id=78417 There is a link to Active Directory's schema there too: http://www.unav.es/cti/ldap-smb/ldap-smb-AD-attributes.html I guess, the desired behavior would be to check for the presence of displayName and use it, if available. Otherwise, fall back to the standard cn.
Comment 3•19 years ago
|
||
-> Core:MailNews:LDAP Integration
Assignee: mscott → sspitzer
Component: Message Compose Window → MailNews: LDAP Integration
Product: Thunderbird → Core
QA Contact: grylchan
Version: unspecified → Trunk
Actually displayName is in the InetOrgPersonPerson schema. See RFC-2798 Section 2.3. The attribute is optional however. If absent you could just use sn and firstName to form a display name. But *never* use the cn. Actually using cn is a very bad idea because it merely serves as a unique identifier in LDAP (together with the rest of the dn) than as a human readable name. Two entries in the same LDAP branch can not have the same cn. For people that means that in many cases there will be numbers appended to the cn to ensure its uniqueness. At our site we have around 3.500 entries in one LDAP branch with a couple of duplicate names (because people just happen to have the same name) so we include a unique ID from another datasource in the cn. The addressbook uses displayName not always when it is present. It seems that it is dependend on which other LDAP attributes are present whether displayName is used or not.
*** Bug 297905 has been marked as a duplicate of this bug. ***
Comment 6•19 years ago
|
||
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050523 1. Ctrl-M, search ldap from "to:" field produce "cn <email>"; 2. Ctrl-F5, quick-search from "name or email contains", right-click on contact in list, click "compose" produce "displayName <email>" in "to:" field; 3. Ctrl-F5, quick-search from "name or email contains", click on email in card, produce "<email>" only in "to:" field; three different results for same task.
Comment 7•19 years ago
|
||
(In reply to comment #4) > Actually displayName is in the InetOrgPersonPerson schema. See RFC-2798 Section > 2.3. The attribute is optional however. If absent you could just use sn and > firstName to form a display name. But *never* use the cn. Actually using cn is a > very bad idea because it merely serves as a unique identifier in LDAP (together > with the rest of the dn) than as a human readable name. Two entries in the same > LDAP branch can not have the same cn. For people that means that in many cases > there will be numbers appended to the cn to ensure its uniqueness. At our site > we have around 3.500 entries in one LDAP branch with a couple of duplicate names > (because people just happen to have the same name) so we include a unique ID > from another datasource in the cn. > > The addressbook uses displayName not always when it is present. It seems that it > is dependend on which other LDAP attributes are present whether displayName is > used or not. Thats not entirely true. You *can* have the same cn for entries in a DIT. The dn *must* be unique - I agree - but as an example, with previous versions of thunderbird, I was using cn as a marker for "email lists". This allowed me to add a cn attribute (since you can have many cn's for a single entry" so I could search on a key value. For example, for a number of my entries I added a cn whicn had the value "jokes". If I had a funny email and I wanted to send it out to a number of people without having to look them up individually, then I could simply enter the keyword "jokes" and all my listings would be returned. Using the cn value allows for me to have people in multiple "lists" whereas having a singluar "displayName" does not. The other thing is, why not let the user choose? I have been playing with mail.addr_book.quicksearchquery.format and manually trying to add the cn attribute to the search string, but have been unable to. In searching futher, I noted that in nsIAddrDatabase there is no attribute to even search for cn. So even if I wanted to change the search string manually (now that I have a quite large LDAP DB with cn implemented as a quasi mailing list identifier) I can't. Is there any possibility of getting this attribute included so I can use it as a search identifier? Many thanks Darren
Comment 8•19 years ago
|
||
With previous versions of thunderbird, I was using cn as a marker for "email lists". This allowed me to add a cn attribute (since you can have many cn's for a single entry" so I could search on a key value. For example, for a number of my entries I added a cn whicn had the value "jokes". If I had a funny email and I wanted to send it out to a number of people without having to look them up individually, then I could simply enter the keyword "jokes" and all my listings would be returned. Using the cn value allows for me to have people in multiple "lists" whereas having a singluar "displayName" does not. The other thing is, why not let the user choose? I have been playing with mail.addr_book.quicksearchquery.format and manually trying to add the cn attribute to the search string, but have been unable to. In searching futher, I noted that in nsIAddrDatabase there is no attribute to even search for cn. So even if I wanted to change the search string manually (now that I have a quite large LDAP DB with cn implemented as a quasi mailing list identifier) I can't. Is there any possibility of getting this attribute included so I can use it as a search identifier?
Comment 9•18 years ago
|
||
displayName was tried in Thunderbird 1.5 and quickly reverted in 1.5.0.2 - see bug 323608 for details.
Comment 10•17 years ago
|
||
sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
Updated•16 years ago
|
QA Contact: grylchan → ldap-integration
Assignee | ||
Updated•16 years ago
|
Product: Core → MailNews Core
Comment 14•12 years ago
|
||
(In reply to James Andrewartha from comment #9) > displayName was tried in Thunderbird 1.5 and quickly reverted in 1.5.0.2 - > see bug 323608 for details. I read through that discussion and I'm not convinced that it's the same situation. That discussion was based upon the field used for the search itself, this is about the name that gets displayed. I feel that this should be included as an ldap_2.servers.default.attrmap setting.
Comment 15•10 years ago
|
||
Solution in config. Instead of SERVER put your LDAP account name: ldap_2.servers.SERVER.attrmap.DisplayName = displayName ldap_2.servers.SERVER.autoComplete.commentFormat = [displayName] ldap_2.servers.SERVER.autoComplete.nameFormat = [displayName] Optional: ldap_2.servers.SERVER.autoComplete.filterTemplate = (|(mail=*%v*)(displayName=*%v*)(givenName=*%v*)(sn=*%v*)(cn=*%v*))
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•