271764 - default to same Inbox is *wrong* (breaks old behavior) for IMAP based setups

Status: VERIFIED WORKSFORME

(Thunderbird :: Mail Window Front End, defect)

Description

[L A Walsh]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Build Identifier: version 0.9 (20041103)

The default to set email to an account to be delivered to a default Inbox is 
just plain "wrong" when a user using all IMAP accounts and their main Inbox is
in one of the IMAP folders.  This may be nice for POP users, but my email is 
presorted into IMAP folders before it reaches the web browser.  

Since some like it turned on -- why not just "remember" the last setting of 
this (including if it pointed to a different IMAP inbox) and default to using 
the user's last choice.

This is another "gotcha" in .9, since I have to now scroll down in the account
creation box to uncheck that box

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[David :Bienvenu]

if you pick your server type as IMAP, the global inbox option is not shown. Is
that what you mean, the global inbox?

Comment 2

[Mike Cowperthwaite]

No response from reporter   => Invalid
Reporter, feel free to reopen this bug if you can better explain your problem;
but the global inbox does not apply to IMAP accounts at all, by default or 
otherwise.

Comment 3

[L A Walsh]

Ah....missed your original question.

My default email account is IMAP.

In order to work around the bug of not being able to specify alternate
"from" addresses (as Outlook allows), or "From" addresses to use with a
specific folder (as Kmail allows), I have to create bogus POP accounts
for each "from" email I want to send email from.

This is a complex and difficult enough setup (have about 30 from addrs that
each require a separate and manually setup "POP" account).  It used to be
the case that after creation, I would have to re-edit the account properties
and set the "Sent", Drafts and Template folders all to point to my default
email account.

Now, if I don't scroll down on one of the account creation pages (the question
of storing email for a POP account that defaults to the unused-legacy POP 
account is scrolled off the bottom of the setup window it is on), I end up
with no separate account to set the rest of the folders to my _default_ email
account.

In other words -- my default email account is an IMAP account -- but each time
I create a new POP account, it sets the default folder settings to the unused
"Local Folders".  

_If_ a newly created account is set to some default folder -- it should be
set to the user's actual _default_ account.  Not an unused "local folder"
account.  The account creation is using wrong defaults for new accounts.

Am I clear about the problem now?  It's more of a case of using the default
email's settings when creating a new account rather than an unused local
folder account (which I'd rather just delete).

Thanks,
-linda

Comment 4

[David :Bienvenu]

unless I'm not understanding something, you can create multiple identities,
i.e., from addresses, w/o creating all those bogus pop3 accounts.

Comment 5

[L A Walsh]

For the completely "clue-impaired" (me), when was this added and where do
I find directions on how to access this feature?
Many thanks if this solves "my", well, solves _this_ problem...:-)

Comment 6

[David :Bienvenu]

The "Manage Identities" button on the account settings pane for the account in
question (lower right hand corner of the window). So, select the account in the
folder pane, e.g., [e-mail], then click the "view settings for this account"
link and you should see the manage identities button.

Comment 7

[L A Walsh]

Yeah, I think the multi-identity feature works to work around this,
but it would still be nice if, when setting up a new account, it 
defaulted to the user's default inbox rather than the local folders.

Comment 8

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 9

[L A Walsh]

I think this is fixed for the most part...
occasionally run into odd cases of newly created identities defaulting
to the wrong values, but these might have been cases where I reused
one of the "blank/empty" deleted entries that get left behind when you
delete an identity...:-/

But I haven't been running into this problem on a regular basis --
especially, I think, since I started using alternate "identities"
rather than having to create fresh accounts....so this "works for me...:-)"