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)

defect

Tracking

(Not tracked)

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.
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
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.
-> 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. ***
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.
(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
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?
displayName was tried in Thunderbird 1.5 and quickly reverted in 1.5.0.2 - see bug 323608 for details.
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
QA Contact: grylchan → ldap-integration
Product: Core → MailNews Core
(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.
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*))
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.