246744 - Missing identity attributes for multiple identities UI

Status: RESOLVED FIXED

(Thunderbird :: Account Manager, defect)

Description

[Scott MacGregor]

Today, if you create an additional identity for an account using the new UI, we
clone the attributes of the account's default identity.

That identity doesn't get the following attributes set on it:

SmtpServerKey
Fcc_Folder

As a result when you use that identity for outgoing mail we end up using
identity.default.fccFolder (which is Local Folders / Sent) and the default smtp
server for all accounts.

Oops.

The short term problem is that nsMsgIdentity::Copy doesn't copy these two fields.

In the long term, what I really want is for these additional identities to
inherit values indirectly through the default identity for the account they are
bound to. That way if a user changes the Sent folder for the default identity in
that account via the UI, all of the extra identities recognize the same change.
Such a change is probably too risky for 0.7 right now.

Comment 1

[Scott MacGregor]

Attachment: the quick fix

Comment 2

[Scott MacGregor]

Comment on attachment 150773 [details] [diff] [review]
the quick fix

This is the quick fix which is to make sure nsMsgIdentity::Copy copies the fcc
and the SmtpServerKey attributes.

After .7 we'll need to figure out how to make these new identities indirectly
look at values of the first identity such that all the identities tied to an
account have the same value for certain properties (such as the folder values
and the smtp key).

Unfortunately the identity attributes are all macro based so it's hard to
hardwire specific cases.

Maybe we can just remove the macros for the fcc, stationary, drafts and the
smtp server key. For those specific values we could do our check against the
first identity in the account.

Comment 3

[Scott MacGregor]

fixed trunk and branch

Comment 4

[Sven Grull]

Does this checkin also fix the problem in Seamonkey as described in bug 235762?

Comment 5

[Lorenzo Colitti]

(In reply to comment #0)
> In the long term, what I really want is for these additional identities to
> inherit values indirectly through the default identity for the account they are
> bound to. That way if a user changes the Sent folder for the default identity in
> that account via the UI, all of the extra identities recognize the same change.
> Such a change is probably too risky for 0.7 right now.

Is there already a bug open on this? This has bitten me more than once, with
drafts and sent mail "disappearing", and it's not obvious what the problem is
until you look a t prefs.js by hand...

Comment 6

[Mike Cowperthwaite]

(In reply to comment #0)
> In the long term, what I really want is for these additional identities to
> inherit values indirectly through the default identity for the account they
> are bound to. That way if a user changes the Sent folder for the default
> identity in that account via the UI, all of the extra identities recognize
> the same change.

As described, this is really klugey.  If the preference should *always* be tied 
to the the default identity's, then it shouldn't *be* an identity preference, it 
should be an account preference.

And if it should *not* always be tied to the default's, then it needs to have an 
accessible UI.

I've a little research on the identity preferences.  Some are set according to 
the Add Identity dialog, some are inherited from the default identity (or from 
mail.identity.default, for the first identity created for a new account), and 
some are not set at all.  All of these preferences are rife with potential 
problems, because *somebody* is going to want them always the same, and 
*somebody* is going to want them different between identities.

bug 246024 -- compose_html (in reply to msg to 2nd identity) -- is inherited
bug 259034 -- reply_on_top (in reply to msg to 2nd identity) -- is inherited
bug 259618 -- fcc -- is not inherited
bug 260805 -- doBcc and/or doBccList -- are not inherited

Comment 7

[Scott MacGregor]

no easy answers for those unless we blow up the new identity dialog for multiple
identites and try to list every field in it instead of the select ones we do now...

Comment 8

[Mike Cowperthwaite]

*** Bug 259618 has been marked as a duplicate of this bug. ***

Comment 9

[mp]

(In reply to comment #6)
> As described, this is really klugey.  If the preference should *always* be tied 
> to the the default identity's, then it shouldn't *be* an identity preference, it 
> should be an account preference.
> 
> And if it should *not* always be tied to the default's, then it needs to have an 
> accessible UI.
> 
> I've a little research on the identity preferences.  Some are set according to 
> the Add Identity dialog, some are inherited from the default identity (or from 
> mail.identity.default, for the first identity created for a new account), and 
> some are not set at all.  All of these preferences are rife with potential 
> problems, because *somebody* is going to want them always the same, and 
> *somebody* is going to want them different between identities.
> 
> bug 246024 -- compose_html (in reply to msg to 2nd identity) -- is inherited
> bug 259034 -- reply_on_top (in reply to msg to 2nd identity) -- is inherited
> bug 259618 -- fcc -- is not inherited
> bug 260805 -- doBcc and/or doBccList -- are not inherited

i have not looked at the source code on this, so i may be speaking from
ignorance here... but it seems to me that from an object oriented perspective,
each account has a collection of identities (with the first being the default).
 upon the addition of an identity, the code should clone the first (thus
automatically copying all values).  once this is done, then a gui simply takes
an identity and creates inputs for all its fields, regardless of whether that
identity is the default.

an even more elegant solution would be to have the values of identities stored
as references, so that identity values an have a "default" value, and changes
made to these "default" values, would affect all other identies as well

Comment 10

[Mike Cowperthwaite]

(In reply to comment #7)
> no easy answers for those unless we blow up the new identity dialog for
> multiple identites and try to list every field in it instead of the select
> ones we do now...

Bug 262300.

Comment 11

[Stuart Grimshaw]

*** Bug 268397 has been marked as a duplicate of this bug. ***