470587 - multiple identities need better naming

Status: RESOLVED DUPLICATE of bug 318495

(Thunderbird :: General, enhancement)

Description

[Phil Lacy]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081217 Shredder/3.0b1pre

name is using 'your name' setting which may be the same.
it should be 'your name' <email address>
often same name is used but different addresses

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Magnus Melin [:mkmelin]]

Where do you mean?

Comment 2

[Phil Lacy]

Yes that was sketchy.

If you have an account called
account name: x
name: Magnus
email: [e-mail]

and another identity with what many have as throwaway address from their isp
it may be
name: Magnus
email; [e-mail]

when you write an email you can't pick out the difference because they both say Magnus.

in NG is it shows as name <emailaddr@x.x>

This would be nice. In fact this would be expected since that is the way it is in the 'From:' header

Also if the name is ever changed it is not changed in email compose window nor in the manage identities pick box.

Not sure if this clears it up yet. Let me know

Comment 3

[Magnus Melin [:mkmelin]]

I still don't see where in the UI you mean. 
The From: address selection picker? That has it listed like you'd want. 

This isn't something an extension is adding for you is it?

Comment 4

[Phil Lacy]

I've been testing another patch. I will start new copy and try again.

Comment 5

[Phil Lacy]

in my oexpress import patch I have been setting the the IdentityName and that is what shows up in compose window and also the 'manage identity' window.  This pref is not in place for normally hand entered account identities.  I'm not sure what it is for but I'll take that out of my patch.

actual function is in nsMsgIdentity.cpp
nsresult nsMsgIdentity::SetIdentityName(const nsAString& idName)
I'll resolve this here.

Comment 6

[Phil Lacy]

I'm going back in.  This is lame.
Steps to reproduce:
1. config editor: new string value
         mail.identity.idN.identityName
         value= veryLame
         N = a valid identity number
2. open compose window instead of 'Name <email.address> you get this value.

currently it is only in the import settings, eudora, etc. The user can't enter it in the account manager.
I say neuter nsMsgIdentity.cpp.

Comment 7

[Magnus Melin [:mkmelin]]

http://mxr.mozilla.org/comm-central/source/mailnews/base/public/nsIMsgIdentity.idl#58

http://mxr.mozilla.org/comm-central/source/mailnews/base/util/nsMsgIdentity.cpp#104

I assume the question is, is there any reason to allow it to be read from a pref?

Comment 8

[Phil Lacy]

Excellent. I was thinking using a hatchet to the function but you are correct, the caller needs the fix. I can try a fix if it can wait till this weekend.

Comment 9

[Phil Lacy]

I don't think changing a backend function will fly. Would we consider changing 
http://mxr.mozilla.org/mailnews/source/mailnews/compose/resources/content/MsgComposeCommands.js#2284 to simulte the name+email composed string that does the same
identity.fullName + " <" + identity.email + ">"

Comment 10

[Magnus Melin [:mkmelin]]

Why? Either there's a reason for the pref possibility (i didn't check cvs archeology back long enough to know why it was done that way), or you simply shouldn't be setting the pref to unsutiable things during import :)

Comment 11

[Phil Lacy]

Maybe at one time the thought was this 'From: ' field in the compose window should show an identity name.
In reality TB users see the name/email pair.  This is the way it is in OExpress also.  I took it out of my patch on OE import settings because OE users are use to the name/email pair and TB code doesn't do that(only as a fall through condition).
That's my reasoning on making the js code listfillin the correct name/email info (not identityname).
I'm gonna submit a patch and it can be decided on.  I haven't used Eudora or other imports but maybe those compose windows show an identity name.

Comment 12

[Phil Lacy]

http://mxr.mozilla.org/comm-central/source/mail/components/compose/content/MsgComposeCommands.js#1252
as a reminder to this bug. This code is also fooled by prefs with an identityName.
I recommend the getIdentityName code be changed to return the name/email pair.
I can't find reference to setting this except in import code for Outlook and Eudora. OE has it but I got rid of it when my patch goes through.

Comment 13

[:aceman]

Is this still a problem?
You may want to check bug 318495 where reworking the naming of identities is discussed too.

Comment 14

[Wayne Mery (:wsmwk)]

(In reply to :aceman from comment #13)
> Is this still a problem?
> You may want to check bug 318495 where reworking the naming of identities is
> discussed too.

Phil, do  you think bug 318495 will handle your issue?

Comment 15

[Phil Lacy]

Looks like a dupe.you know Wayne, OT, when they started messing with the addon's UI for a longtime and having it in the tree as a workinprogress i give up on keeping my build uptodate as i needed that. But this bug appears to be a dupe now.