LDAP autocomplete doesn't show pretty name

VERIFIED FIXED in mozilla0.9.2

Status

MailNews Core
Composition
P2
normal
VERIFIED FIXED
17 years ago
10 years ago

People

(Reporter: Hong Kwon, Assigned: dmose)

Tracking

(Blocks: 1 bug)

Trunk
mozilla0.9.2
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

17 years ago
LDAP autocomplete/autocompletion doesn't show the pretty name when doing
typedown.  This makes the feature difficult to use.  Consider typing in the name
"Steve" - instead of being able to find the Steve you want you merely see a list
of valid Steve email addresses.  For example:

stevec@test.com
stevecm@test.com
stever@test.com
steve@test.com

Something much more useable would be the following types of results:

stevec@test.com <Steve Chang>
stevecm@test.com <Steven C. Murray>
stever@test.com <Steve Roswell>
steve@test.com <Stephen Doe>


Steps to reproduce
1. Set up LDAP typedown addressing to point to your LDAP server
2. Open mail compose.
3. Type in a few characters.. e.g. 'ste'

Expected Results:

Autocomplete results in the form:
email@host.com <real name>

Actual Results:

Autocomplete results in the form:
email@host.com
(Reporter)

Updated

17 years ago
Depends on: 77384
QA Contact: esther → yulian
(Assignee)

Updated

17 years ago
No longer depends on: 77384
(Assignee)

Comment 1

17 years ago
*** Bug 77384 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 2

17 years ago
For this to work, nsLDAPAutoCompleteSession.cpp needs to be able to parse it's
outputFormat attribute, which is on my plate.
Assignee: srilatha → dmose
Blocks: 17880
Depends on: 74896
Priority: -- → P2
Target Milestone: --- → mozilla0.9.1

Comment 3

17 years ago
Setting target milestone to 0.9.2 (check it in anytime, even before, when the
tree is open for). Per PDT triage.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
(Assignee)

Updated

17 years ago
No longer depends on: 74896
(Assignee)

Comment 4

17 years ago
OK, here's my current game plan for this: outputFormat will be specified as a
string, and inside that string, attributes will be quoted by a pair of |
characters (or maybe { } or whatever; suggestions invited). All other characters
other than the quote character(s) will be considered literals.

If the addressing widget finds a .autoComplete.outputFormat hidden pref for the
LDAP server in question, it'll pass that to the autocomplete session. Otherwise,
the LDAP session will use its internal default of:

|cn| <|mail|>

This allows for more flexibility than with the 4.5 ".autoComplete.attributes"
scheme (see <http://docs.iplanet.com/docs/manuals/communicator/ldap45.htm>),
because arbitrary text can be included. This may be handy once it's possible to
autocomplete from multiple directories, so that one can easily visually
differentiate between instances of identical names completed from different
directories, eg

John Smith (CompuServe) <42342das@cs.com>
John Smith (Beer Googles) <smith43@bg.com>

Still need to figure out whether this means I should store outputFormat as a
CharPref or UnicodePref; also need to check the mail RFCs to understand what
sort of i18n info is allowed in addrspecs (ie From, To, CC, ...).

Status: NEW → ASSIGNED
(Assignee)

Comment 5

17 years ago
I talked this over with Leif last night, and he pointed out that | could be a
bit confusing, since it already has special semantics in LDAP search filters.

Additionally, I grovelled through RFC 2822 for a while, and found that if you
quote it, pretty much anything (US-ASCII at the very least) can be in these headers.

So, new theory goes like this: attributes are delimited by curly braces, and \
can be used to escape (ie make literal) anything including itself.  The default,
then, looks like this:

cn <{mail}>

I'll probably be implementing today, so if you've got any comments, now would be
a great time to chime in.  :-)
(Assignee)

Comment 6

17 years ago
I meant 

{cn} <{mail}>

of course.
(Assignee)

Comment 7

17 years ago
Created attachment 35095 [details] [diff] [review]
patch, v1
(Assignee)

Comment 8

17 years ago
I've attached a basic patch that does this.  I still need to do a certain amount
of cleanup before it's ready to be reviewed, but it's a start.  I think I may
need to introduce another type of attribute; perhaps [foo].  This would mean
that the token is required for an entry; {foo} would mean that it's optional. 
So the default string would become:

{cn} <[mail]>

Since not having a cn (pretty name) is no big deal, but not having an email addr
makes an entry not worth displaying in the UI.
(Assignee)

Comment 9

17 years ago
Created attachment 35435 [details] [diff] [review]
patch v2
(Assignee)

Comment 10

17 years ago
OK, I think this is ready for review; any volunteers?  :-)

Here's the documentation for outputFormat, cribbed from the interface file.

     * Required attributes are delimited by curly braces, and optional 
     * attributes are determined by brackets.  Backslash escapes any 
     * character, including itself.  The default template is
     * "[cn] <{mail}>", without the quotes.  This will generate autocomplete
     * items of the form "John Doe <john.doe@foo.com>", or, if the cn is not
     * found, " <john.doe@foo.com>".  This latter form is suboptimal, in that
     * the space and angle brackets are a bit ugly, but should work.  See
     * bug 81961.
looks good. R=ducarroz
(Assignee)

Comment 12

17 years ago
Created attachment 35516 [details] [diff] [review]
patch2, version 1
(Assignee)

Comment 13

17 years ago
Doh!  Forgot to attach the second part of the patch, which is a minor tweak to
the JS in the compose window.
R=ducarroz for patch 2

Comment 15

17 years ago
I reviewed 05/21/01 11:53 and 05/21/01 17:42. If those are the only patches you
needed a super review on, then they both looked correct and safe to me. sr=mscott
(Assignee)

Comment 16

17 years ago
Yup, those were the two.  Thanks!
a=dbaron for trunk checkin
(Assignee)

Comment 18

17 years ago
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Updated

17 years ago
Blocks: 83989

Comment 19

17 years ago
2001061304 winds trunk build
Verified
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.