After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 272391 - Autocompletion should show email addr if two email addrs with same name
Autocompletion should show email addr if two email addrs with same name
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Contacts
2.6.x (obsolete)
Other All
: Normal normal
: Future
Assigned To: Milan Crha
Evolution QA team
: 229384 270843 274376 501289 (view as bug list)
Depends on:
Blocks: 326692 327508 327510 347983
 
 
Reported: 2005-02-09 07:18 UTC by Luke Hutchison
Modified: 2008-09-23 11:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed eds patch (4.67 KB, patch)
2008-08-27 11:31 UTC, Milan Crha
committed Details | Review
proposed evo patch (5.48 KB, patch)
2008-08-27 13:32 UTC, Milan Crha
committed Details | Review
screen shot of new UI (43.83 KB, image/png)
2008-08-27 13:32 UTC, Milan Crha
  Details

Description Luke Hutchison 2005-02-09 07:18:21 UTC
I noticed a recent change to autocompletion causes only the name of the
recipient to be displayed after autocompletion.  This is much more in line
with what Outlook does.  However, Outlook's habit of hiding email addresses
at all costs (and using names instead) is a serious problem.  These days
most people have multiple email addresses, which can all be in the address
book under the same name.  I frequently have problems receiving email at my
home address that people intended to send to my work address, or vice
versa, because everyone I know uses Outlook, and it goes out of its way to
not tell you what the address of the person you're mailing is (unless you
right-click and go "Properties", although most people don't know that, or
don't want to bother).  Thus they choose the first instance of the intended
name that pops up in their list.  Or, more worryingly, they somehow figured
out (and try to remember) that "the second Joe Bloggs in the list is his
home email account, the first one is his work account, and the one that
says Joe J. Bloggs is his gmail account".

I think hiding email addresses is fine if it's an option, or if addresses
are not hidden when there is more than one address mapping to the same name
in the addressbook.

Personally, I would like to disable the hiding of email addresses entirely
(even after autocompletion when a full name is available), but I know not
everyone wants to see email addresses, so perhaps an option is the best
idea?  (I looked for an option, and couldn't find one anywhere.)

Thanks!
Comment 1 Sivaiah 2005-02-19 14:05:51 UTC
you are talking about not showing email in the autocomplete pop down
window ? It is no longer the case. We show now both email and name.
After selecting entry we show only the name.If this is not waht you
meant please reopen. 
Comment 2 Sivaiah 2005-02-19 15:06:55 UTC
*** bug 270843 has been marked as a duplicate of this bug. ***
Comment 3 Luke Hutchison 2005-02-23 08:01:45 UTC
Is this a change that was made between 2.1.5 and 2.1.6?  It's not
quite what I meant.  I have 2.1.5 and it shows all email addresses in
the drop-down list, as you describe (if I'm reading it right).  The
problem is that the email address is not shown in the "To:" line.  If
you type a name, e.g. "Luke", it autocompletes to "Luke Hutchison",
then shows all email addresses for Luke Hutchison.  However, if you
have 4 email addresses for that name, it doesn't show you which of
these is the actual one that was autocompleted.  So you have to go
down and choose the one you want anyway, because you don't know where
you're sending the message to.  This renders autocompletion useless.

The change I was requesting was to have the email address always shown
in the "To:"/"CC:"/etc. line, if there are two names in the address
book that are the same but have different email addresses. 
Unfortunately that won't always work if the two name representations
are almost, but not exactly, the same (e.g. one has a middle initial).
 An even better solution, just always show the email address next to
the name, in angle brackets ("Luke Hutchison <luke@domain.com>").  As
far as I remember this is much more in line with what Evo 1.2 did.

Hiding the email address is not a useful thing.  As I mentioned,
outlook does it, and I get email all the time to the wrong account
because several people I deal with have two addresses for me under the
same name.  You can't lose showing email addresses, but you can if you
hide them.  I don't think this is a case of "needing to simplify the
interface for the general public" -- even the general public has to
deal with actual email addresses, and will always have to.

Please see Luis Villa's comment in the dup.  I think he's referring to
the same thing I am.

Thanks!
Comment 4 Luke Hutchison 2005-02-23 08:19:25 UTC
Sorry, I mean Luis' comment in the dup of the dup :)  bug 271215.
Comment 5 Devashish Sharma 2005-08-24 05:30:55 UTC
*** Bug 274376 has been marked as a duplicate of this bug. ***
Comment 6 Sushma Rai 2005-08-29 08:09:23 UTC
*** Bug 252165 has been marked as a duplicate of this bug. ***
Comment 7 Sushma Rai 2005-08-29 08:11:59 UTC
*** Bug 229384 has been marked as a duplicate of this bug. ***
Comment 8 Sushma Rai 2005-08-29 08:20:06 UTC
We need to show name and e-mail address, but if it is a problem 
as we have a single text filed, if showing the long string per address
causes the problem (see 231751), then we need to show which address is
selected while autocompletion by marking the selected email address
in the right click menu, and also showing the name and address on
mouse pointer focus. 
Comment 9 Sushma Rai 2005-08-29 08:27:54 UTC
Also we need to see if we can exclude some ids form the autocompleted
contact list. See 220570.
Comment 10 Luke Hutchison 2005-08-29 16:18:46 UTC
Re. Comment 8: Yes, but you also need to always show the email address if the
name is not a unique identifier of the email address.  i.e. if there is one or
more other email addresses corresponding to the display name that is shown for
an address in the field, then the email address should always be shown.  This
stops people sending email to a co-worker's home address rather than their work
address, etc.
Comment 11 André Klapper 2005-09-23 02:14:46 UTC
well, name *and* mail address are shown it the dropdown menu in 2.4.0, is that
ok? (seems that i don't get the bug at all, sigh)
Comment 12 Luke Hutchison 2005-09-23 02:57:29 UTC
The point is you shouldn't have to right-click on every email address in the
list to make sure you're sending the email where you think you're sending it.

A partial solution is to append the email location designation to the end of the
email address if the contact has more than one email address, e.g. "John Smith
(Home)", "John Smith (Work)" etc.  A better solution is to simply display the
name and the email address together if there is more than one email address
across all addressbooks for the given name.
Comment 13 Stanislav Brabec 2005-09-23 11:31:10 UTC
It would be ideal to have this configurable - either short display (comment #12)
or full display.

Even in drop down menu of 2.4.0 it is not OK. If recipient has more e-mail
addresses, you see all these addresses in the drop-down menu, but you have no
evidence, which of these addresses is actually used in the mail. I guess it is
known as bug 274376.
Comment 14 André Klapper 2005-09-27 20:48:08 UTC
ok, so retargetting this to 2.5 since it is not fixed in 2.4.0.
Comment 15 André Klapper 2005-09-27 20:48:37 UTC
ok, so retargetting this to 2.5 since it is not fixed in 2.4.0.
Comment 16 André Klapper 2006-07-06 20:18:34 UTC
removing old target milestone.
Comment 17 Milan Crha 2008-08-27 11:31:48 UTC
Created attachment 117444 [details] [review]
proposed eds patch

for evolution-data-server;

The emails are shown in case the contact contains more than one email, or user forces to show them in bool option /apps/evolution/addressbook/completion/show_address
Even if forced, no emails are shown for contact lists.
Comment 18 Milan Crha 2008-08-27 13:32:08 UTC
Created attachment 117455 [details] [review]
proposed evo patch

for evolution;

UI part with new strings, scheme entry and quite big UI change for Edit->Preferences->Autocompletion. This patch is not necessary to let the eds part work, thus I think we can commit the eds patch even to actual trunk before this one.
Comment 19 Milan Crha 2008-08-27 13:32:40 UTC
Created attachment 117456 [details]
screen shot of new UI
Comment 20 Milan Crha 2008-08-29 10:05:12 UTC
*** Bug 501289 has been marked as a duplicate of this bug. ***
Comment 21 Srinivasa Ragavan 2008-08-31 13:03:38 UTC
Milan, it seems fine for me. But UI freeze. So commit after freeze. (I haven't tested it, but seems fine for me.).

Just another thought, can we avoid the need for an UI. Any alternate way of showing the email? Currently, when you r-click on the contact, the email is shown. Can we think of tooltips or something like that, which can be more intuitive.. just a thought. 
Comment 22 Milan Crha 2008-09-01 07:39:47 UTC
(In reply to comment #21)
> Milan, it seems fine for me. But UI freeze. So commit after freeze. (I haven't
> tested it, but seems fine for me.).

What about committing at least eds part? There is no UI change there, but quite good functionality change, which someone can prefer.

> Just another thought, can we avoid the need for an UI. Any alternate way of
> showing the email? Currently, when you r-click on the contact, the email is
> shown. Can we think of tooltips or something like that, which can be more
> intuitive.. just a thought. 

Tooltips. Hmm. I do not like them much. The widget has a tooltip already, showing all addresses in there (for cases that there are too many addresses and you want to see all of them).
Comment 23 Suman Manjunath 2008-09-01 08:42:26 UTC
Following discussions on IRC, the e-d-s patch was committed to trunk as r9460
http://svn.gnome.org/viewvc/evolution-data-server?view=revision&revision=9460
Comment 24 Milan Crha 2008-09-23 11:03:21 UTC
evo part committed to trunk. Committed revision 36431.