Closed Bug 30057 Opened 24 years ago Closed 20 years ago

Add Option to use one Local Mail tree for all POP3 accounts

Categories

(SeaMonkey :: MailNews: Account Configuration, enhancement, P3)

enhancement

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: mozilla, Assigned: Bienvenu)

References

Details

(Keywords: fixed-aviary1.0, Whiteboard: fixed-aviary1.0)

Attachments

(11 files)

20.01 KB, patch
mscott
: superreview+
Details | Diff | Splinter Review
6.54 KB, patch
mscott
: superreview+
Details | Diff | Splinter Review
22.75 KB, patch
mscott
: superreview+
Details | Diff | Splinter Review
3.18 KB, patch
mscott
: superreview+
Details | Diff | Splinter Review
638 bytes, patch
Details | Diff | Splinter Review
14.47 KB, patch
mscott
: superreview+
Details | Diff | Splinter Review
889 bytes, patch
Details | Diff | Splinter Review
3.36 KB, patch
mscott
: superreview+
Details | Diff | Splinter Review
21.86 KB, patch
mscott
: superreview+
Details | Diff | Splinter Review
19.45 KB, patch
mscott
: superreview+
Details | Diff | Splinter Review
1.84 KB, patch
mscott
: superreview+
Details | Diff | Splinter Review
Having a seperate Inbox tree (Inbox, Sent, Unsent, etc.) for each account is 
going to get really hairy for users with for than about 5 accounts. It would be 
nice if Mozilla could just use one Inbox tree for all accounts. Using individual 
Inboxes is not necessary to track which From: header to use on replies, just 
compare the To: or CC: header to known addresses in the account manager. If it 
exists, use that address as the From: and if it does not exist, use the default 
account.
reassign to Phil if he wants to put on helpwanted list
Assignee: mscott → phil
Sure, we could do that. I can certainly agree that if you have a slew of
accounts, one hierarchy might be nice. We don't really have time to do that
*and* a separate hierarchy per account for Seamonkey, and given that we can only
do one, I think we picked the right one.

I'm a little nervous about using the To and CC headers to guess the right
identity on the reply. That's pretty easy to break with BCC, mailing lists, etc.
Assignee: phil → nobody
Keywords: helpwanted
That's why if you cannot determine it with absolute certainty you default to the 
default account. Users can use the From: dropdown to change it anyway.
*** Bug 58380 has been marked as a duplicate of this bug. ***
My bug was marked as a dup. All you need to know is the account the mail was 
sent to and then have it send the reply out from that account. Try outlook. I 
think that you should be able to select which inbox to store the recieved mail 
in for each account just like you can for templates. Then you could store it in 
local folders.
Blocks: 58380
No longer blocks: 58380
OS: Windows 2000 → All
Hardware: PC → All
*** Bug 95752 has been marked as a duplicate of this bug. ***
Whats the status on this bug?
Last real comment was on 2000-10-29 11:32.
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
*** Bug 165183 has been marked as a duplicate of this bug. ***
I have several accounts, and would not want to mix e-mails between them.  A
single inbox would cause me no end of problems and I would have to find another
e-mail client.
Don't even bother talking about filters.  I can barely get rid of the spam that
I get now, without compounding the issue by combining all of my accounts into one.
If this is going to be implemented, it needs to be an option, and not the
default one.
If the Inbox folder was specified in Mail and NewsGroup Account Settings, for
each mail account,(just like Sent, Drafts, and Template folders are now) then by
default it could be the way it is, each with own Inbox.   But I could easily set
each account to receive all email into the LocalFolders/Inbox.  Other
combinations are possible also, so you could direct any email from non-SPAM
generating accounts to one, but keep the others individually specified, etc.

My experience is that I have several accounts and minimal unfilterable spam, so
its a hassle having to switch between Inboxes all day.
Sorry, one more comment.  To emulate the behavior of Outlook Express, which new
many users will likely be familiar with, I would also suggest, in addition, a
simple option (checkbox per account or even a global one to apply to all mail
accounts) to not even display the folder hierarchy of any individual account. 
On OE, everything went by default into the Local Folders/Inbox, including Sent,
Drafts, etc, even if I had several accounts.  (Im not saying that this is a good
default behavior, but allowing users a way to use familiar paradigms is usually
a good idea.)
Pardon the bugspam, but should not the summary indicate that this is to apply to
POP3 accounts?  I'm assuming everyone's clear on this, but it's not been specified.
Summary: [RFE] Use one Local Mail tree for all accounts → [RFE] Use one Local Mail tree for all POP3 accounts
Summary: [RFE] Use one Local Mail tree for all POP3 accounts → Use one Local Mail tree for all POP3 accounts
*** Bug 176980 has been marked as a duplicate of this bug. ***
I would really like to see this implemented. I would love to use Mozilla mail, but I hate the multiple trees for different accounts thing since I'm used to Eudora. I only use 2 accounts (sometimes 3 if I'm working from home) but even at that level I find it unweildy. Perhaps an option to just send everything to local folders (Drafts, Sent, Inbox, etc) and to hide all of the rest of the folder trees or one of the other ways already mentioned to easily combine all your accounts and keep things easy to look at. 
There seem to be several related bugs -- Bug 11051, Bug 46041, and Bug 58380 at
the least -- that deal with (POP) mail and its relation to virtual folders of
some kind.

One thing that has become clear to me by way of postings in the n.p.m.* and
n.m.u.* groups is that the inability to have POP mail dumped into a universal
Inbox (from whence it is filtered as desired) is a show-stopper for a lot of
people that may prevent the further adoption of Mozilla and its distributions
(Netscape /et al./).  The flip side is that there are people who do seem to
prefer the current tree set-up.

It would seem to follow from this that users should be given the option to make
use of a universal Inbox on a per-account basis (much as Bug 141531 would give
the user a per-account choice of bottom- or top-quoting, which would be useful
since NG etiquette still favours bottom-posting, whereas top-posting is
increasingly accepted as a business practice).

Further, I would suggest that users who favour the current tree set-up should
still be given the option to make use of the ('universal') Drafts, Templates,
Sent, and Trash folders under Local Folders as they wish (on a per-account
basis); this would seem to be appropriate for IMAP accounts as well.

Some of these comments may seem more /Ă  propos/ elsewhere, and for that I
apologise; it just seemed that this was as appropriate a bug as I could, and
opening a new bug somehow didn't seem appropriate.  (If it is appropriate, one
should, of course, be filed.)  My apologies, too, if these comments merely
re-iterate some made in another bug. . . .
Good summary, Brian Heinrich.

This is the *one* thing that keeps me using Outlook Express. Clearly it needs 
to be an option, as some people like it how it is, though.
I definitely have been wanting this for a while - and it keeps me using OE for
some of my mail needs.  Vote +1.
*** Bug 194641 has been marked as a duplicate of this bug. ***
I agree. This is an important feature to add as it's the only thing currently
keeping me from using the mail client as well. I have too many email accounts
(because of my business) for the current format to be efficient. Shared folders
would be awesome! I'd be a convert.
Blocks: eudora
For me this is the major point to stay with OE ..

My proposol is to extend the options in "Copies & Folders" so that every folder,
not just sent, draft and template can be located somewhere else. This and the
ability to delete unused Folders may give a good compromise :)
CCing myself.

Just to add my voice, this feature is also the one big thing that stops me
migrating from Outlook Express.  A few points:

- I can't stand having a seperate Inbox/Outbox/Trash/etc for each account.  It
just looks messy, and I far prefer the Outlook Express system of Universal folders.
- I think that guessing what account the e-mail had been sent to by looking at
To: and CC: would be a nasty hack.  It'd be far better simply to do what Outlook
Express does, and record an extra piece of data for each e-mail - the account
which it was received from.  Then, you could display the name of that account as
a field in the folder list, making it easy to see which account each e-mail was
sent to, and also select that account by default when replying to the e-mail.
- It'd be nice to have a single option which just toggled between Universal
folders and a seperate folder tree for each account.  I wouldn't like the hack
of 'redirecting' mail for all accounts into one Inbox, but still showing all the
seperate folders for seperate accounts - it'd just look messy.  If this is going
to be implemented, it should be done properly and there should only be one
Inbox, Outbox, Trash, Sent Items, etc displayed, with all e-mails going into
those folders.
Moving to Account Manager, having this in Networking seems nonsensical .

Also, I don't mean to be discouraging, but the number of "me too" comments does
not generally influence developers into fixing a bug. If anything, some of them
are irritated by it. Please see
http://bugzilla.mozilla.org/page.cgi?id=etiquette.html for some words on what
makes a "helpful" Bugzilla comment.
Assignee: nobody → sspitzer
QA Contact: lchiang → gchan
Component: Networking: MailNews General → Account Manager
User-end Workaround:

1) Create new folder in Local Folders, marked, say, Inbox.
2) Put the following filter on all account inboxes: 
 Subject doesn't contain FOO
 Move to folder Inbox on Local Folders.
3) Put the following filter on all account inboxes: 
 Subject contains FOO
 Move to folder Inbox on Local Folders.

Your incoming mail will now all be filtered to Inbox on Local Groups when you
Get All New Messages.  Although the other trees will still exist, you can ignore
them in favor of the Local Folders set.  You will have to manually decide which
account to reply from, I think.
And you can't put the "Local Folders" account on top either (Bug 61078). Not
much better.
> User-end Workaround:

Not good enough.  And believe me, most of us already know full well that we can
do this.  It's an ugly hack.  You'll still get about 25 folders displayed if you
have 5 POP accounts, which looks ugly, and whatsmore it will only apply to
Inbox... all sent mail will be put into different Sent folders, and different
Outboxes will continue to be used.
I see a large number of people who want a single inbox.  However I definitely am
NOT one of them.  I have several accounts and under no circumstances would want
my inboxes mixed.  Personal preference but a strong one.  If this is implemented
it should definitely be optional, and probably not the default.  
There is already a copies and folders tab for each account under mail and
newsgroups account settings, where users can specify the sent, drafts and
templates folders for each account. The obvious extension is to add an extra
choice to this tab so that users can specify the inbox for each account. In fact
it seems a strange omission that these less important folders can be specified
here but the most important one cannot.
There is already a copies and folders tab for each account under mail and
newsgroups account settings, where users can specify the sent, drafts and
templates folders for each account. The obvious extension is to add an extra
choice to this tab so that users can specify the inbox for each account. In fact
it seems a strange omission that these less important folders can be specified
here but the most important one cannot.
Perhaps because that would take away the point of having seperate mail trees for
different accounts?  If you were able to deselect all folders for that account,
and use a generic inbox, what would happen to that account's tree... would it
just be there, empty?  The inbox is kinda the anchor directory for each account,
so presumably that's why it has to stay, under a multiple account-tree system.
(In reply to comment #31)
> ...  The inbox is kinda the anchor directory for each account,
> so presumably that's why it has to stay, under a multiple account-tree system.

Well, for many of us this kind of anchor is not required, and it should be at
least an option to raise it and allow the folder set to float away - or at least
to be hidden.

PS sorry for accidentally posting my previous comments twice.
This "anchor" has caused me to miss many an email way down the list of my
accounts.  I want to be able to take one look in an Inbox to see if I have any
new mail, not sit there looking thru 5 of them each time I want to see if I have
new mail. (The bold number of unread messages doesnt help, because hey, when
does that *ever* go down to zero?  Never.)   This is the single feature that
sometimes makes me long for Outlook Express....  Although I believe this is the
default behavior in Outlook Express (I cant remember if there is any other) it
doesnt have to be here.  We just want to set the Inbox in the same way we set
the Drafts, Sent, etc folders, as a previous reporter mentioned. 
Since people seem to want to spam this bug, I might as well do so as well ;-) :

Those of us who prefer to keep our e-mail accounts in separate trees obviously
have no problems with Moz' current behaviour in this regard, and there are those
of us who use Moz /because/ of this behaviour.  So the first point to note is
that any resolution to this bug should not alienate those of us who prefer the
existing mail tree structure.

It would follow from this that those of you who do not prefer the current set-up
need to find a way in which this could be resolved (or some similar solution
involving virtual folders could be implemented) w/o changing the existing behaviour.

So far, I'm not seeing comments to this effect in this bug; rather, I'm seeing a
lot of 'Me, too' comments.  If you have a way in which to resolve this bug, post
it; if have you are able to write the code to implement the resolution, even
better; but please please please please please don't post more 'Me, too'
comments or comments that do nothing more than indicate your dislike or loathing
of what for many of us is an appropriate approach to e-mail.

The obvious place to locate a universal Inbox would be Local Folders, which is
where the rest of the universal folders are.  That much seems clear.  But you
also need to allow people the flexibility to choose which POP3 accounts (and
which folders associated with those accounts) make use of the universal folders.
 So you'd need something whereby, if Account\Folder is sent to a universal
folder, that folder is hidden -- something like that, anyway.

That still leaves open the whole matter of how messy this is going to make each
account's settings under Edit | Mail & Newsgroups Account Settings, but that
should be workable; after all, an appropriate solution was found for Bug 62429,
altho' it required a fair amount of UI finnagling.

Then there is the matter of how this is to be set up in prefs.js.  Since any
such change from individual mail trees to a universal mail tree should also be
undoable, the mbox files for each account would have to remain in place, which
would suggest that what we're actually looking at is some kind of implementation
of virtual folders.

My apologies if I've not been entirely clear; I'm still in the process of
caffeinating myself. ;-)

Basically, what those of you who are interested in this bug being resolved need
is to be able to move beyond the current level of discussion and on to actually
discussing implementation and then getting a patch done (with appropriate review
and superreview).

Since there has been no activity on this bug since it was first opened four
years ago, those of you who ardently desire a resolution to it may wish to
discuss putting a bounty on the bug; it has worked in other cases, and may work
here as well.
*** Bug 190087 has been marked as a duplicate of this bug. ***
*** Bug 237679 has been marked as a duplicate of this bug. ***
I'm italian (sorry for my English) and I'm not a developer. This is partially a
deprecated 'me too' comment.
I'm using TB and not Mozilla, but I think it's the same.
TB 0.5 implemented Multiple Identity Support
(http://www.mozilla.org/projects/thunderbird/identities.html) and I think this
is a great feature. TB answers using the right identity (according to To and Cc
headers, I think).

I study how prefs.js works, and I think this can be the way to implement this bug:
prefs.js has 3 'things':
- accounts = means set of folder
- identities = settings about name, sign...
- servers = settings about server, userid, password, directory where store
messagges...
Now is it possible to associate multipe id to one account, with a line like that:
user_pref("mail.account.account1.identities", "id1,id5");
There is no GUI yet, but this can come later.
My suggestion is to just make possible to associate multiple server to one
account; something like that:
user_pref("mail.account.account1.server", "server1,server5");
This way, everyone can choose multiple tree or just one (or more) set of
folders. Totally flexible. The mbox files would still be associated with server,
and mixed into accounts. 

Brian, I dont understand the exact meaning of your comment, but I hope mine can
be usefull. I ardently desire a resolution, but I cant help so much.
(In reply to comment #37):

Trouble is, you still need to implement some meta-information that stores which
POP account the e-mail was downloaded from (like Outlook Express does).  Some
header showing 'Account' for each e-mail.  Dumping all mail into one Inbox is
one step, indicating which account each e-mail was from is the other.
My English is not good, but I will try to explain my idea anyway, with an example.

I have an account with despammed.com, that redirect emails to another account,
let's say settolo@something.com.
So, I get all mails in inbox of something.com  but I need to answer with both
identities.
to do that, before multiple id implementation in ThunderBird, I needed to have 2
accounts, and 2 sets of folder, even if no mails go to the inbox of
despammed.com. I also needed to choose manually the right identity in the From:
box for everymail I write.
Now, I can have 2 indenties and just one set of folder, and TB is able to choose
the right identity when replying. I dont know how this is implemented, maybe
just checking to: and cc:, but it works quite good. Maybe not the best, but it
works.

So, I'm not a developer, but I think the problem Jeremy Morton is talking about
is already solved.

I think the easyest way to solve this bug, is to let MozillaMail and TB to
"redirect" mails.
I already talk about prefs.js. If there is more than one server associate with
one account, some lines in prefs.js like this:
user_pref("mail.account.account1.identities", "id1,id2");
user_pref("mail.account.account1.server", "server1,server2");
TB and MM should just "redirect" mails from server2, into the first one.
TB already knows how to choose the right identity to use in replying, so I think
this is not a problem to implement.
Moreover, using multiple smtp is associated with identities, with this line:
user_pref("mail.identity.id2.smtpServer", "smtp2");
and not with server. So, this wont be a problem too.
Of course, I have lots of others account, let's say settolo@somethingother.com.
Now I use filters to move everything coming into the inbox of somethingother.com
to something.com, and this is very similar to what MM and TB should do, imho.
BUT with 2 differences: filtering, we must see in the panel every set of
folders, even if we dont use, and this is not good.
filtering, return recipient and junk controls doesn't work properly.

Imho, the way to solve this bug is making possible to "redirect" mails letting
return recipient and junk control work.
*** Bug 208332 has been marked as a duplicate of this bug. ***
(In reply to comment #11)
> I have several accounts, and would not want to mix e-mails between them.  A
> single inbox would cause me no end of problems and I would have to find >
another e-mail client.

Just use message filters to file your incoming messages from different accounts
to different custom subfolders respectively.

> Don't even bother talking about filters.  I can barely get rid of the spam that
> I get now, without compounding the issue by combining all of my accounts into one.
> If this is going to be implemented, it needs to be an option, and not the
> default one.

Message filters are not the adequate method to filter out Spam nowadays. Use an
external (proxy) Spam-Filter instead which is much more efficient.
The most flexible concept would be ...

- User1
  Inbox
  Drafts
  Templates
  Sent
  Trash
  Any Custom Folders
- User2
  Inbox
  Drafts
  Templates
  Sent
  Trash
  Any Custom Folders

etc. etc. etc.

... where every User node in its properties can have any number of email accounts! 

This would accomodate BOTH opinions:

1. People who want to have a separate folder-tree for every account just create
several User nodes and ONE POP account for every User node. This method
practically recreates the same situation as it is now.

2. People who want to have to have all their messages from different POP
accounts filed into a single Inbox just create one User node and specify
different POP accounts in this Users properties.

3. Families with different Users (Mom, Dad, Ken, Dog) can create for example the
following configuration:

- Mom
  Inbox
  Drafts
  Templates
  Sent
  Trash
  Any Custom Folders
- Dad
  Inbox
  Drafts
  Templates
  Sent
  Trash
  Any Custom Folders
- Ken
  Inbox
  Drafts
  Templates
  Sent
  Trash
  Any Custom Folders
- Dog
  Inbox
  Drafts
  Templates
  Sent
  Trash
  Any Custom Folders

Mom has only one POP account and is happy because she gets all her email from
this account filed into her own Inbox (and with filters then to different custom
subfolders like Recipes, Mail from Maggie etc.).

Dad has several POP accounts (from his company, an other one from his private
website, etc.) and is also happy because he gets all his mail from different
accounts filed to his Inbox (and then with filters ...).

Ken has two POP accounts and doesn't want his parents to read his mail he
exchanges with friends which contains secret plans on how to build a suitcase
neutron bomb. So he locks his user node with a password only he knows and only
he can expand.

The only one who is not happy is Dog: He still cannot read and must wait for any
of the other family members to read his mail for him.
(In reply to comment #42)
> The most flexible concept would be ...

Agreed.

...
> 
> The only one who is not happy is Dog: He still cannot read and must wait for any
> of the other family members to read his mail for him.

Perhaps Dog's incoming e-mail could be redirected automatically to a speech
synthesizer program. (Are there any accessibility options of this kind in
Mozilla?) He would probably soon learn to recognise the message "Walk". ;-)

One inbox for all accounts would truely simplify reading all messages. 
Nevertheless, I would not like to loose the benefit of different accounts. For 
professional and private accounts I would like to keep my different signatures 
and sending-servers.

Therefore each message in this unified inbox should keep its information  from 
which account it came and initialize a reply with these global informations 
(unique reply address, unique smtp-server, unique favorite signature, unique 
crypting algorithm and settings).

An option to easily change these informations (and therefore swith a message 
from one in another account) would be perfect, of course.
This option would be important for creating new messages from scratch, too.

Such a general distinction between mails of different accounts seems to be 
essential to me because of security and privaty reasons. In case of using 
crypting technologies for specific accounts, such a preservation of settings 
for each mail seems to be of crucial importance.

What do you think?

Yours sincerely,
Pirmin Schmid
pirmin_schmid@web.de
(In reply to comment #44)

> Therefore each message in this unified inbox should keep its information  from 
> which account it came

I agree the message should keep this information, along with other information
like Flags, a short Memo, Color Label, etc. ...
(In reply to comment #34)
> Since people seem to want to spam this bug, I might as well do so as well ;-) :
> 
> Those of us who prefer to keep our e-mail accounts in separate trees obviously
> have no problems with Moz' current behaviour in this regard, and there are those
> of us who use Moz /because/ of this behaviour.  So the first point to note is
> that any resolution to this bug should not alienate those of us who prefer the
> existing mail tree structure.
> 
> It would follow from this that those of you who do not prefer the current set-up
> need to find a way in which this could be resolved (or some similar solution
> involving virtual folders could be implemented) w/o changing the existing
behaviour.
> 
> So far, I'm not seeing comments to this effect in this bug; rather, I'm seeing a
> lot of 'Me, too' comments.  If you have a way in which to resolve this bug, post
> it; if have you are able to write the code to implement the resolution, even
> better; but please please please please please don't post more 'Me, too'
> comments or comments that do nothing more than indicate your dislike or loathing
> of what for many of us is an appropriate approach to e-mail.
> 
> The obvious place to locate a universal Inbox would be Local Folders, which is
> where the rest of the universal folders are.  That much seems clear.  But you
> also need to allow people the flexibility to choose which POP3 accounts (and
> which folders associated with those accounts) make use of the universal folders.
>  So you'd need something whereby, if Account\Folder is sent to a universal
> folder, that folder is hidden -- something like that, anyway.
> 
> That still leaves open the whole matter of how messy this is going to make each
> account's settings under Edit | Mail & Newsgroups Account Settings, but that
> should be workable; after all, an appropriate solution was found for Bug 62429,
> altho' it required a fair amount of UI finnagling.
> 
> Then there is the matter of how this is to be set up in prefs.js.  Since any
> such change from individual mail trees to a universal mail tree should also be
> undoable, the mbox files for each account would have to remain in place, which
> would suggest that what we're actually looking at is some kind of implementation
> of virtual folders.
> 
> My apologies if I've not been entirely clear; I'm still in the process of
> caffeinating myself. ;-)
> 
> Basically, what those of you who are interested in this bug being resolved need
> is to be able to move beyond the current level of discussion and on to actually
> discussing implementation and then getting a patch done (with appropriate review
> and superreview).
> 
> Since there has been no activity on this bug since it was first opened four
> years ago, those of you who ardently desire a resolution to it may wish to
> discuss putting a bounty on the bug; it has worked in other cases, and may work
> here as well.

Just my 2 cents.  Not even sure if this is possible.  For those who like
multiple Inbox's --> Just keep Mozilla working the same as it does now.  For
those who wish to have a single tree structure..... How about allowing for ZERO
or NONE accounts?  This would be similar to the way it was done in Communicator
4.7X with a single account.  Mozilla could then allow a single folder (ie. Inbox
in the Local Folders directory) to be associated with a POP3 Incoming mail
server.  The hard part (and potentially impossible part) is to allow for
multiple POP3 Incoming mail servers to be associated with this same single Inbox
folder (ie. C:\Mail\Inbox).  NOTE: This enhancement was NOT allowed in
Communicater 4.7X (so not sure if implementation is possible).  Perhaps having
multiple shortcut folders with different names all pointing back to
"C:\Mail\Inbox" (or whatever user picks) would work out?  Another idea would be
to have Mozilla cycle through all N different incoming mail servers every 5
minutes (or user customized cycle timer).....  Thus during any given point of
time only a single POP3 incoming mail server (with appropriate user name and
password) would point to "C:\Mail\Inbox".....  But 5 minutes later a different
POP3 incoming mail server would automatically set up and begin downloading
e-mail to your local computer.  For this idea to work, the requirement to exit
Mozilla and re-launch Mozilla with the new server info, would have to be
overcome (not sure if this is even possible).

-John Shumaker
(In reply to comment #46)
... The hard part (and potentially impossible part) is to allow for
> multiple POP3 Incoming mail servers to be associated with this same single Inbox
> folder (ie. C:\Mail\Inbox).  NOTE: This enhancement was NOT allowed in
> Communicater 4.7X (so not sure if implementation is possible). ...

There is already a problem in Mozilla when messages are being received
simultaneously on more than one account and are being filtered to the same
folder, or incoming messages on one account are being filtered to the inbox of
another account. There is obviously some kind of locking which blocks the
filtering. This problem will have to be overcome somehow if this bug is ever to
be fixed.
Personally, I find it amazing that no progress has been made on this problem.  I
am certain that if MS can implement this functionality, than Moz/TB can as well.
 Also, I for one am not requesting that 1 inbox be the only option.  So everyone
defending the current setup needs to be less defensive, IMHO.  At a minimum,
perhaps until a permenant solution is put in, I believe that users should at
least be allowed to remove the folders which they don't actively use.  Sent
Items, Drafts, and Templates on Local Folders, or even the Local Folders
"account" entirely, is a prime example.  If the user has their prefs such that
nothing gets directed to these folders, why are they forced to have them?  In
the end, I think what we are all asking for is flexibility, rather than being
locked into doing it one way.  The tricky part of a full solution to this issue
will be coming up with a decent UI to control it all.  But unfortunately, none
of the willings seem able and none of the ables seem willing.  How many more
have to spam here and vote until something is done?
In re. commment #48:  Er, you have this backwards, do you not?  If you have a
single mail tree for multiple POP3 acc'ts, the logical place for such a tree
would be under Local Folders.

There are two issues that seem to get missed in all of the 'Me, too!' comments:

1. AFAICT, this feature is predicated on virtual folders; /i.e./, support for
virtual folders would allow for the contents of the various folders of multiple
acc'ts (Inbox, Drafts, Sent, Templates from Acct-1, Acct-2 . . . Acct-/n/) to
appear under (/e.g./) Local Folders.  At that point, you're looking at a way in
which to control the (non-)appearance of Acct-1, Acct-2 . . . Acct-/n/ in the
UI, while allowing for this (non-)appeareance to be toggled in Edit | Mail and
Newsgroups Account Settings | [account].

2. Indicating that 'OE can do this, so why can't Moz?' is pretty pointless:  M$
made a fundamental design decision that all POP3 acc'ts would be lumped together
in a single universal mail tree for POP3 acc'ts; m.o/Netscape made an equally
fundamental design decision that all POP3 acc'ts would appear separately.  Each
approach has its strengths and weaknesses.  But I do at times, when I encounter
'Me, too!' comments, wonder to what extent the preference for the M$ approach is
simply a matter of familiarity and comfort with that approach.

Assuming that what we're actually looking at is virtual folders with a UI
control, wouldn't it be appropriate to indicate that this bug depends on Bug
11051?  Perhaps the reporter or current owner might wish to consider adding the
dependency?
(In reply to comment #49)
> 1. AFAICT, this feature is predicated on virtual folders; /i.e./, support for
> virtual folders would allow for the contents of the various folders of
> multiple acc'ts (Inbox, Drafts, Sent, Templates from Acct-1, Acct-2 . . .
> Acct-/n/) to appear under (/e.g./) Local Folders.  At that point, you're
> looking at a way in which to control the (non-)appearance of Acct-1, Acct-2 .
> . . Acct-/n/ in the UI, while allowing for this (non-)appeareance to be
> toggled in Edit | Mail and Newsgroups Account Settings | [account].

Frankly, I don't want it to be based on virtual folders. I want there to be some
flag on the message (say, X-Mozilla-Account) that indicates the account from
which the message was downloaded (and if that can't be matched, used the
default), and then I want to download everything into a single hierarchy. My
mails get sorted by topic, not by account, and I don't want it because "that's
the way that OE does it", but because I can't think of anything sillier than
having to go with a completely separate tree simply because the mail is
downloaded from a different location. Choosing to do that, perhaps, but not by
default.

As an example, I have a Bugzilla alternative; all of my mail for that account
goes into Development/Bug Traction, unless it's an actual bug report from the
live instance, in which case it goes into Development/Bug Traction/Issues. I
also have Development/Ruby (which has Development/Ruby/Lists,
Development/Ruby/ruby-talk, etc.). Anything that isn't filtered into my topical
tree (or prefiltered as spam) is put into a single inbox for review. Obviously,
because of this design decision, I cannot be using Thunderbird to do this --
which absolutely sucks because I'd switch in a moment if Thunderbird supported this.

I don't want the switch to be reversible at any time; if I was hit over the head
and somehow decided that I like the account-based tree abomination, I would
expect to make the conversion myself. This means that the presence of
X-Mozilla-Account (and perhaps X-Mozilla-Identity) would be very useful in being
able to do such a manual conversion.

I do not believe that this has a dependency on virtual folders. It has a
dependency on being able to hide the other account trees and have them go to a
single Inbox.
In re. comment #49:

I would respectfully disagree, and do so in part because you would impose your
specific e-mail usage on all (l')users; you're also making assumptions that I'm
not sure can be extended to users in general.  (Referring to the current set-up
as an 'abomination' doesn't much help your argument either, I'm afraid. ;-) Bear
in mind, too, that there are those who consider Local Folders as much an
abomination as you consider multiple acc't trees.)

Can we agree that the current set-up is a bit silly for those who have a single
POP3 acc't? -- That is, if there is a single POP3 acc't, it should likely appear
(in the UI) under Local Folders; whether the actual mbox files do so or not is
another matter.

As one adds (POP3) acc'ts, there may be a point at which the universal Inbox
(and mail tree) no longer suits one's needs -- or doesn't suit one's needs for a
given acc't.  That you may not see this happening for yourself barring a boot to
the head is another matter.  In that event, having a simple way in which to back
out a given acc't from the universal tree may not be a bad thing (tho' I would
suggest that one have the option of just which folders -- default or otherwise
-- to back out).

Hang out in the n.m.u.* fora for a while and you'll understand why I feel there
should be a simple, UI-driven way in which to accomplish this. ;-)

Your reference to filtring is a quasi-red herring, since the universal mail tree
primarily concerns the default folders Mozilla creates.  You could, in fact, do
such filtring as is w/o having to fall back on a universal tree.

That said, filtring does raise a good point, since those folders would by
default be associated with Local Folders rather than with any actual POP3 acc't.
 If one were to wish to back out an acc't, what does one do in re. folders in to
which mail has been filtred?  I honestly don't know, and suspect that,
realistically, it's irrelevant, since those folders can just be moved about on
the local disk. 

I do believe that virtual folders is a more sane way in which to accomplish this
functionality -- and to make it flexible -- than is your suggestion, complete
with flags, &c.  (Bear in mind that most users wouldn't have the slightest clue
as to how to perform the kind of manual conversion to which you refer, and would
consider the need to do so a serious flaw on the part of Mozilla.)  While
virtual folders might not be /ideal/, they do strike me as the best solution
available to us.
It seems like the cleanest (UI) solution to this problem may simply be to
address it at the presentation layer.  I _think_ this is what is being
recommended with the Virtual Folders concept, but there are so many varied ideas
I think I'll just take a stab at explaining my understanding.  To reduce
confusion I'll call it Merged Folder view.

Under the hood, TB continues to track each folder and account separately as it
does now, but for this view it just merges/unifies the folders based on like
names.  Every 'Inbox' gets displayed merged together as one (this will likely
require a separate layer that merges them on the fly, which could get hairy). So
if you have a folder 'Family' on accountA, as well as accountC, you would see a
single 'Family' folder in the unified view.  If you want to keep folders
seperate, you name it uniquely (or don't use the unified view).  The individual
emails should remain in their original locations, and not be migrated anywhere.
 Infact, you could even just have a pivot-link along side each of the accounts
labeled Merged Folder View.  Somebody who prefers to browse that way could pivot
it open, and pivot closed all of the others (so no checkbox), and those who
prefer to keep the accounts separate could stay with the individual accounts.

The requirement of having each email recall its origin sounds like a good idea
anyway, and would certainally make responses easier to manage.  Perhaps also
have new emails start with _no_ from pre-selected, if there is more than one
account (this is probably the one thing that has bitten me the most, having it
default to the wrong source address and I didn't notice).
1) Comment #50 contains something useful: Adding a meta header
X-Mozilla-Identity (example). Actually, Eudora does the same, it adds
X-Personality, so it knows which e-mail came through which account/identity.

2) On locking: Maybe same as Eudora, but it requires some programming work: When
checking the POP3 accounts, *DO* save everything in it's own
(cache/hidden/private) file, *then* queue everything to have it moved to the
right Inbox. Maybe using internal filters (based on the option if you want one
Inbox, or multiple). This way you don't get a file locking problem, plus you can
filter all the messages in one go. This is also most systematic. So:

* check pop3 mail
* add X-Mozilla-Identity [name] to the header
* save in an internal file (each account has it's own "cache" file)
* [when all pop3 accounts are checked:]
* filter/move all to the designated inbox(es)

3) On all other operations, use the X-Mozilla-Identity header to check what
preferences go with what identity (outgoing name, reply-to, etc).

Right now, everything is saved in its own Inbox anyway, so maybe that can be
changed to an internal/temp file, after which it filters. Any other suggestions
are welcome :)
(In reply to comment #53)
> 1) Comment #50 contains something useful: Adding a meta header
> X-Mozilla-Identity (example). Actually, Eudora does the same, it adds
> X-Personality, so it knows which e-mail came through which account/identity.

Just a small comment; this suggestion for an extra header rather stuck out at
me.  If you add a header into the stored e-mail, it will show up if you forward
that e-mail to someone... right?  If so, wouldn't it be more sensible to wrap
the stored e-mails in a custom format (exportable of course) that saves this
kind of information, rather than cluttering the e-mail with it?  It'd be nice to
have a stored version of the e-mail exactly how it was downloaded off the server.
Comment 2 says it all. No further comments needed, only volunteers.
taking.
Assignee: sspitzer → bienvenu
This patch remembers at download time which account a message was downloaded
from, and writes it into the message. We use this value when a local message is
deleted to delete the message from the right pop3 server. I also changed some
code to not use nsFileSpec readLine but rather, nsILineInputStream, because
it's much more efficient.
Attachment #147944 - Flags: superreview?(mscott)
Attachment #147944 - Flags: superreview?(mscott) → superreview+
(In reply to comment #57)
> Created an attachment (id=147944)
> step one - remember which account a message came from, and use it when deleting
> msgs from pop3 server

The way I understand POP e-mail, the idea is to delete the mail from the server
once it has been downloaded to the local machine.  Is this not how Mozilla Mail
works?
Also, why are these changes being done for Moz Mail instead of Thunderbird? 
Wouldn't it make more sense to do this for the planned future mail client?
<< Also, why are these changes being done for Moz Mail instead of Thunderbird? 
Wouldn't it make more sense to do this for the planned future mail client? >>

One would assume that the underlying code associated with these actions is
common to both applications.
You can configure pop3 to either leave mail on the server after downloading it,
or to delete it from he server when downloading it.

Mozilla Mail and Thunderbird share an enormous amount of code, including this
code. This feature will be implemented for both.
Attachment #148009 - Flags: superreview?(mscott)
Attachment #148009 - Flags: superreview?(mscott) → superreview+
checked in step 1 and 2 - now you can set the "deferred_to_account" pop3 server
pref attribute to the account key of the account you want to download new mail
into (e.g., your local folders account). For example, if your local folders
account is account2, and server1 is your pop3 server, you'd set this pref:

user_pref("mail.server.server1.deferred_to_account", "account2");

I'm not recommending anyone try this with real e-mail since I'm still shaking
out all the issues, but it does work for me...

Next steps:

1. Make reply use the identity for the account specified by x-account-key, if any.
2. Remove deferred accounts from folder pane and move/copy menus, but make sure
they appear in the mail account settings.
3. Get someone to work on new account wizard and account settings.
In comment 57 is:
> This patch remembers at download time which account a message was downloaded
> from, and writes it into the message.

David, could you please continue the example of comment 62 and spell out
what that added header would look like (if I am correct in assuming that
it is written into the message as a header)?    Thanks.
X-Account-Key, which is the same header that unsent messages use, so it should
already be stripped off before sending...
So the header name is X-Account-Key.  But I'm also interested in 
what the value would be.   I'm guessing that in the example here it 
would be "account1" . Is that right?

(But I'm confused:  you say it's "the same header that unsent messages use".
Does that mean in the Drafts folder? 
The closest header in my Drafts messages is "X-Identity-Key: id2"   )

What I'm driving at is to see how useful this header is going to be 
for helping users to filter the messages.  Part of the above discussion is
that users want to be able to funnel the messages through one visible 
Inbox, but still be able to separate them out from there.
For that purpose, an internal key is not very "user friendly".
I would much rather see the Account NAME, since that's the only handle
the user has on the account without digging into prefs.js (and it's not
clear that would help all that much.)

Since the internal key is useful for processing purposes, I would think
that two headers should be added, X-Account-Key and X-Account-Name .
(I'm calling this "Account-Name" because that is what it is called
in the Account Settings UI, but in the prefs.js it seems to be more
like "Server Name".)

Sorry this message is so confused, but that's because I'm confused.
I hope you can straighten this out a bit.

Thanks for your patience, and for tackling this long-suffering problem.
David:
Is this patch redirecting mail into one *existing* Inbox?  Does that existing
tree have the name of an existing account on it?  Or is there a new 'local
folders' tree created?  I'm not sure it's a good idea to simply redirect the
mail to an existing tree, which would need to have its own account settings (POP
server, custom name, etc)

Len:
Is it not possible to obtain the account name from the account key?  I agree
that displaying the account name is almost mandatory.  As for how it's
displayed, I would favour the same method as Outlook Express - an additional
column in the e-mails list 'account', giving each respective e-mail's 'recieved
from' account.
this patch won't redirect any mail anywhere, unless you set the pref. Once you
set the pref, you can redirect it to any pop3 or local folders account - the
local folders account always exists, so my guess is that's going to end up being
the most common way to configure this feature - redirecting pop3 servers mail to
the local folders account.

We use the x-account-key because that's the unique identifier for the account.
It is possible for us to go from the account key to the account name, so we can
display it in the UI if we decide to do so (that's a good idea). But the account
name, the pretty name, as it were, is not guaranteed to be unique, so we can't
use it.

Re filtering on that header, since you still have per-server filters, and not
global filters, you don't need to filter on that header, if that makes
sense...it might be useful for search. We could probably just add a new filter
criteria, original account, where you could pick from an account drop down, and
not have to know the account key, but underneath, we'd use the account key...
Thanks for your reply.

You wrote:
> Re filtering on that header, since you still have per-server filters, and not
> global filters, you don't need to filter on that header, if that makes
> sense

Sorry, I don't understand what you mean.  Are you saying that even though
the messages are in the deferred-to account, the filtering would be done
based on the Original account?  That seems both mysterious and awkward.

BTW, in my Message Filters screen, the "Filters for:" drop-down has no 
entry for "Local Folders"
------------

Having the filter UI present original account name to the user
and translate it internally to account key sounds like a good idea,
but I don't think that's the simplest or best solution.

For one thing, as you point out, search may be a different matter.  

Also, is it possible that the account key could change, if the user
shuffles accounts around, or perhaps moves a mailbox from one profile
to another?

All in all, I still think that a straightforward X-Original-Account-Name
header would be more useful and simpler for the user to deal with.
Of course, this would be in addition to the X-Account-Key, which is
needed for internal processing purposes.

And I don't think non-uniqueness of the account-name would be a problem
for the user's purposes if it is documented that if accounts are deferred
and filtered this way, they need to have distinct names.
That's the natural way of setting it up anyway.  I really think that if
this header were provided, you needn't bother with the fancy filter 
translation.

(And notice that I sneaked a name change in there for my proposed header:
X-Account-Name (and for that matter X-Account-Key) seem ambiguous to me,
since there are two accounts in the picture.

------------

And, BTW, I very much like that with this implementation it's not 
all-or-nothing:  some folders can be combined, while others are kept
separate.

(Again, my comment is all over the map.  How did this get so complicated? :)
really, REALLY thanks for taking this bug and working on it.
I like the way it is going to be implemented.

I would like to know if these patches work also for TB and if they will be
included into the "weekly" precompiled release of TB.
Or should I apply them to the source code to make some test?

(sorry for english)
yes, currently the filtering is based on the original incoming server - I think
which server the mail is coming from is likely to be important for filters, and
if the filters belong to the original incoming server, then you automatically
have that as a criteria, if that makes sense. All that we're deferring is the
disk storage, not anything else.

The account key never changes; the account name can change, which is another
reason to use the account key in the mail folder, the persistent storage. Adding
an x-original-account-name is possible, but I'm not convinced of the need for it
yet...

This will all be in thunderbird builds as well - nothing I've done yet is
specific to either Tbird or Seamonkey.
The 'Local Folders' account doesn't seem to have its own Inbox.  How can you
filter incoming mail into that?

Also, will the UI be updated so that an additional 'Account' column will be
available for the e-mail list?
My Local Folders most certainly does have its own Inbox.  David already stated 
that he thinks it's a good idea to show which account a message is associated 
with in the list.  I would also like to thank David for his work on this bug.  
It's a very often requested feature that prior to now has gotten very little 
attention.  I'm thrilled that he is spending some of his valuable time on it.
Thx, we'll create an INBOX under local folders, if one is needed. It's good you
pointed that out, because I would have thought we already did that, but we
don't, so I have to make that happen.

And yes, I think we will add that column, off by default. It will be one of the
last things I do, however...
Comment on attachment 147944 [details] [diff] [review]
step one - remember which account a message came from, and use it when deleting msgs from pop3 server

This fix caused bustage on Solaris + Forte compiler. Error message is:

"nsLocalMailFolder.cpp", line 3032: Error: Cannot assign const char* to char*.
"nsLocalMailFolder.cpp", line 3055: Error: Cannot assign const char* to char*.

Change strstr to PL_strstr will fix them.
thx to Seth for the xul help - this patch adds an IsDeferred attribute to the
folder datasource, and hides deferred accounts in folder pane, while showing
them elsewhere. Also cleaned up some of the other ds code...
Attachment #148083 - Flags: superreview?(mscott)
> thx to Seth for the xul help

Did you intend to attach XUL changes, too? I can't find any. Or is that
implemented completely in the DS? Would make sense (it's app logic, not FE), but
it's hard to see in the long patch.
Attachment #148209 - Flags: superreview?(mscott)
Attachment #148083 - Flags: superreview?(mscott) → superreview+
Attachment #148209 - Flags: superreview?(mscott) → superreview+
David can you fix folerpane.xul for thunderbird too please? Thanks!
David, can you fix the Solaris bustage I mentioned in comment 74 in your next
checkin?
Kyle, I'm pretty sure I already did...
this makes it so deferred to accounts will automatically create an inbox, if
needed, gets rid of a lot of duplicate code for creating mailboxes, and makes
picking a deferred account from the get new messages drop down work. I'll
attach the thunderbird patch next.
Attached patch tbird changes — — Splinter Review
Attachment #148387 - Flags: superreview?(mscott)
Comment on attachment 148387 [details] [diff] [review]
make get new messages on deferred account work

can you make the corresponding thunderbird changes to mailCommands.js and
mailWindowOverlay.js?
Attachment #148387 - Flags: superreview?(mscott) → superreview+
(In reply to comment #62)
> ...
> 
> 1. Make reply use the identity for the account specified by x-account-key, if any.
> ...

I am very happy to see movement on this bug. But I am not sure that the above is
actually the desired behaviour, at least in every case. I have a number of
nearly dormant accounts which I continue to check, because some people don't
have my most recent e-mail addresses. But when I reply to them I want to use my
current address, not the old address on which the message was received. On the
other hand, by default I do want to reply to messages to my private account on
my private account, and to messages on my work account on my work account. So
perhaps there is a need for a setting in the UI here. Or perhaps the account of
the reply should depend, as now, on the account in which the message is
currently filed.
(In reply to comment #85):

I think the default reply identity should be the one associated with the
original server from wich email comes. So, no problem with the "private account"
and "work account". For "dormant accounts", you can always choose manually the
right identity to use for each email you write.
Maybe, a "setting in the UI" for the default reply identity is a good idea, but
I think it can come later.
you can change the identity in the compose window easily. Also, for the dormant
accounts, you should edit the identity to change the reply-to address to be to
whatever account you want...
(In reply to comment #87)
> you can change the identity in the compose window easily. Also, for the dormant
> accounts, you should edit the identity to change the reply-to address to be to
> whatever account you want...

Why not just make the From dropdown user-editable?
In this context, why does it need to be editable? You can just pick the identity
you want from the dropdown.
whoops, last patch made get new mail half run in the selected folder...
(In reply to comment #90)
> In this context, why does it need to be editable? You can just pick the identity
> you want from the dropdown.

I only suggested it because an editable From field is highly desired by many
users. It seemed to me to go through all the trouble you are going through to
keep track of invisible accounts, etc. and not just make the field editable
would be a lot more work.
Attachment #148450 - Flags: superreview?(mscott)
Attachment #148450 - Flags: superreview?(mscott) → superreview+
(In reply to comment #92)
> 
> I only suggested it because an editable From field is highly desired by many
> users. It seemed to me to go through all the trouble you are going through to
> keep track of invisible accounts, etc. and not just make the field editable
> would be a lot more work.

I'm not sure if you're saying that the email's "from" field should be editable
or if the new "x-account-key" field should be editable.  In either case, these
fields contain information about the mail transaction, and should not be edited
or editable.

Mozilla's behavior based on those fields should be editable, but not the fields
themselves.
>  ..an editable From field is highly desired by many users.

I think that's highly doubtful. A pull-down field is adequate.

A general comment: this is a tricky fix that attempts to incorporate a lot of
the design/functionality of OE as well as the many branched tree approach of the
existing TB/Moz mail client. I think that it should be carefully thought out,
and programmed solidly, not as a mere add-on patch to satisfy a fringe element.
I see no clear description above of the specs for this change. It gives the
impression of being fixed /on the fly/ by David (and thank you, David).

OE has evolved, through many iterations, into quite an elegant program, and
should be carefully looked at. Leaving OE's well-thought-out interface is a
*showstopper* for many, many users. I use OE in M$, and Kmail in Linux. Kmail
apes OE quite well (but with inferior keyboard assignations). David should study
OE to make sure switchover users are adequately seduced. This is a critical
turning point for Thunderbird. Don't fluff it. I'd hazard a guess that over 80%
of users will elect to have the Universal Inbox/Outbox/Sent design, and that
should therefore be the default.
This has been thought out and designed fairly carefully, as far as the backend
is concerned, before the implementation was started.  The backend was designed
to give the front end a fair amount of flexibility in what it wants to expose
(just global pop3 inbox, or per account deferral). The front end for setting
this up has not been specified, but there aren't that many choices - allow
deferral to any pop3 or local folder account, only allow deferral to a global
inbox account, and whether that should be the default (I doubt it will be the
default, however). The implementation is being done in phases to keep the
patches small, and hopefully avoid serious regressions. Bear in mind we can't
copy everything OE does because they *only* support a global inbox, which makes
their ui simpler, but at the cost of not allowing users to send pop3 mail to
different inboxes.
(In reply to comment #94)
> >  ..an editable From field is highly desired by many users.
> 
> I think that's highly doubtful. A pull-down field is adequate.

Adequate for you. I do not fancy creating a new account for every single time I
give out an email address. Since I have my own domain, each time I give out my
email address, it is a unique value. This allows me to track just who is giving
out my email address. Responding to mail from these people with the correct From
address requires me to add an account for each address. That is a lot of work. I
don't want to have several dozen accounts just to have the names in a dropdown.
What's the resistance to allowing someone to edit the From field? You can do it
in the account settings, why not just move that function to the compose window?
(In reply to comment #96)
> (In reply to comment #94)
> > >  ..an editable From field is highly desired by many users.
> > 
> > I think that's highly doubtful. A pull-down field is adequate.
> 
> Adequate for you. I do not fancy creating a new
> account for every single time I give out an email
> address. Since I have my own domain, each time I
> give out my email address, it is a unique value.
> This allows me to track [snip]

I would describe your actions above as unusual, and certainly not something
mainstream or worthy of the Mozilla project's limited resources. Sorry, Jerry,
that's my opinion. You're the first person I've ever heard of who does that.
(In reply to comment #95)

<snip>

> Bear in mind we can't copy everything OE does because they *only*
> support a global inbox, which makes their ui simpler, but at the
> cost of not allowing users to send pop3 mail to different inboxes.

Actually, OE allows you to create rules based on the account a message came
from, so you could conceivably set up separate inboxes for each account. 
Perhaps OE uses something similar to x-account-key?

Thank you for your efforts, btw :)
(In reply to comment #97)

> > Adequate for you. I do not fancy creating a new
> > account for every single time I give out an email
> > address. Since I have my own domain, each time I
> > give out my email address, it is a unique value.
> > This allows me to track [snip]
> 
> I would describe your actions above as unusual, and certainly not something
> mainstream or worthy of the Mozilla project's limited resources. Sorry, Jerry,
> that's my opinion. You're the first person I've ever heard of who does that.

Sorry to reply here, but I do the same - and by the looks of things, so do a few
people who commented on Bug 87987.  Maybe this discussion should go there instead?
(In reply to comment #93)
> 
> I'm not sure if you're saying that the email's "from" field should be editable
> or if the new "x-account-key" field should be editable.  In either case, these
> fields contain information about the mail transaction, and should not be edited
> or editable.
> 

My mistake, didn't realize you were talking about editing the From field on
outgoing mail.
This is how I think this problem should be solved:

1) It should be possible to set multiple POP3 accounts for an account (like you
can set multiple identities for an account). In pref.js it could be like this:

user_pref("mail.account.account1.servers", "server1, server2, server3");

I'm not sure how it would be in the UI. Maybe there could be a tab in the
"Advanced Account Settings" dialog, or a separate "Advanced POP3 Settings"
dialog. It could work like the "Advanced Outgoing Server (SMTP) Settings" dialog.

2) There should be something like a "Keep all messages on Local Folders"
checkbox under "Copies & Folders".

I think this way all users could be satisfied.
David, is it the desired behaviour that I can't view the filters for an account
that's hidden?
I.e. if user_pref("mail.server.server1.deferred_to_account", "account2"); is
set, the filter list of the account with server1 is empty though the filters are
active.

Or is it just work in progress?
Something I just thought of after reading a forum post.  Should the "Get All
Messages" extension not finally be put back in conjunction with these changes? 
It  could be potentially annoying for a user to have to use 2 clicks (Get
Messages | Account Name) to get their mail.  Since the deferred accounts will be
hidden from view, the context sensitive nature of the Get Messages button can't
be utilized.  Or could you just make it such that clicking Get Messages while in
your Local Folders or what have you checks all accounts that have been deferred
to them?
As in Outlook Express, when you defer an account, you can also say that get new
mail in the deferred to account also gets new mail in the deferred account. In
the "global inbox" case of deferring all your pop3 accounts to the local folders
account, then get new mail in the local folders account gets new mail for all
your pop3 servers, if you say you want to defer get new mail as well for each of
those servers. Support for a hidden pref to implement that is what I'm working
on now.

Christian, you should be able to see the filters for the deferred account - I
can, at least. So you must be running into a bug. When you do get new mail with
server1, it should use account1's filters, and editing account1's filters should
work...
nsPop3IncomingServer::CreateDefaultMailboxes was left looking a bit fishy after
attachment 148387 [details] [diff] [review]: "Drafts" is touched twice, and "Templates" creation return
value is not checked. (I'd like to see the latter half of it blown to bits or
something anyway, cf bug 197228, but I digress)
this implements deferring of get new mail for an account to either another pop3
account, or the local folders account. If the per server pref
defer_get_new_mail is set to true, and the server defers to another account.
getting new mail on the deferred to account will get new mail on the deferring
account. This also makes it so doing get new mail with a local folder selected
will get new mail on all the accounts that defer storage to the local folders
account, if they defer get new mail as well.
Attachment #148629 - Flags: superreview?(mscott)
Attachment #148629 - Flags: superreview?(mscott) → superreview+
the latest patch broke balsa tinderbox (gcc34)
/builds/tinderbox/SeaMonkey-gcc3.4/Linux_2.4.7-10_Depend/mozilla/mailnews/local/src/nsPop3IncomingServer.cpp:133:
error: extra `;'
Attached patch add account name to thread pane — — Splinter Review
adds the account name to the thread pane. Ideally, I'd like to *not* store the
account key in the db if the message is in the account it came from, but that's
an optimization I can make later.
Attachment #148898 - Flags: superreview?(mscott)
Attachment #148898 - Flags: superreview?(mscott) → superreview+
Comment on attachment 149052 [details] [diff] [review]
make reply/forward use the hdr's account key to ghet the correct server to determine identity from

this wraps up the major backend work for this feature. Now I need to change the
new account wizard and the account settings so the user can set this up.
Attachment #149052 - Flags: superreview?(mscott)
Attachment #149052 - Flags: superreview?(mscott) → superreview+
Resolution of this enhancement bug would mark a significant fork in the road of
Mozilla development.  As such, any "fixes" for this functionality should not be
hastily implemented.  Extreme care should be taken to ensure that this
enhancement bug does not become the starting point for a holy war between the
single inbox and multiple inbox camps.

I am a long-time member of the later camp, but I recognize the need to embrace
the single inbox folks as well.  With this in mind, I'd like to throw strong
support behind the resolution idea mentioned in comment #42 and comment #101. 
Such a resolution will allow much greater flexibility with account management in
general, and has (by far) the greatest chance of making both single/multiple
inbox camps happy, in my opinion.

I am not sure if this is the direction in which the current patch development is
proceeding, but I'd propose at least exploring this avenue in parallel with
development work so that perhaps we will have two possible implementations from
which to select the superior.  Yes, this would entail much more coding work than
just spurting out whatever comes first, but I'd argue that this single/multiple
inbox issue is important enough to warrant the extra effort in making sure the
absolute best possible solution (one that will appeal to both sides) is the one
implemented.
as I've said before, the backend implementation allows you to defer any pop3
account's storage to any other pop3 account, or the local mail folders. Or you
can not defer any accounts. I believe that's sufficiently flexible.

I'm not sure what the UI will be for setting this up. I suspect the account
wizard will just let you pick per account storage, or "global inbox", meaning
the Local Folders account. The account settings might let you pick an account to
defer storage to - it depends on how confusing it becomes...
(In reply to comment #112)
> as I've said before, the backend implementation allows you to defer any pop3
> account's storage to any other pop3 account, or the local mail folders. Or you
> can not defer any accounts. I believe that's sufficiently flexible.

Hasn't this already been possible using the
user_pref("mail.server.serverX.directory",".....") hack combined with the
multiple identities feature?  Granted, no UI for it, but that functionality has
already been there in terms of backend implementation, right?  All that would be
missing is hiding accounts you no longer need listed in the left-hand pane of
the main Thunderbird window (which I see a couple of your first patches deal with).

What's different between this and what your patches do?
(I don't mean to sound critical... just confused.)

I do still think the other way would be cleaner and more flexible.  But if this
is what people want to run with... I don't really plan to use any single inbox
feature, so I suspect I won't be among those terribly affected anyway.
>Hasn't this already been possible using the
>user_pref("mail.server.serverX.directory",".....") hack combined with the
>multiple identities feature?  

Good question. That hack can cause all sorts of data corruption. It's a bug that
it's even allowed.

I considered the multiple servers per account approach initially, but rejected
it because it's more likely that users will have a different identity for each
account and the ui for setting that up is much more natural than the multiple
servers per account approach, i.e., setting up separate servers and separate
identities, and then associating them...that's also a much more dramatic and
risky change in the backend than the approach I took. I think functionally they
both allow you to do the same thing.
(In reply to comment #106)
> Created an attachment (id=148629)
> allow servers to defer get new mail to other account
>
> This also makes it so doing get new mail with a local folder selected
> will get new mail on all the accounts that defer storage to the local folders
> account, if they defer get new mail as well.

Will Local Mail have it's own filters? (please say yes :) )

Alternatively, say I have pop accounts account1 and account2. Then say I defer
account1 to account2. When I run 'Get mail' on account2, will it use account2's
filters for *all* mail that it retrieves (from account1&2)? Along with a 'from
account#' condition in the filters, this would cut out the manual
synchronisation of filters between accounts, which is *very* irritating to maintain.

So I very much hope this is the way it works. But if not, how will the filters
on account1 know that the folders I choose are associated with account3 due to
deferral? For instance, if I later alter account1 to defer to a new account
(account4), will account1's filters still be pointing to the folders on account3?

Anyhoo, thanks for your efforts on this.
> I considered the multiple servers per account approach initially, but rejected
> it because it's more likely that users will have a different identity for each
> account and the ui for setting that up is much more natural than the multiple
> servers per account approach, i.e., setting up separate servers and separate
> identities, and then associating them...that's also a much more dramatic and
> risky change in the backend than the approach I took.

I don't agree. If I want to have a private, a public and an account for my 
organisation, and each of them will use two POP3 servers, it's more natural to 
setup three accounts and then add an additinal POP3 server for each one of 
them, than to setup six accounts (three additional accounts which uses the same 
settings as the existing ones) and defer three of them. I just want to have 
three identities (name, email, signature etc), one for each one of the three 
accounts but multiple servers, not six identities. Especially in pref.js, it 
would be much more natural to setup different servers with different accounts, 
it would work like the multiple identities support.

For users who just want to use the Local Mail tree for all accounts, they could 
setup as many accounts as they want and use the "Keep all messages on Local 
Folders" checkbox I mentioned in my previous comment. I think your patches is 
enabling this in some way.

A much more common scenario is just a public and a private pop3 server, which do
require two separate accounts, even in your example...
In OS X with a clean profile, I created a new account (global inbox).

I then created a new account, but unchecked global inbox.

It appears in the prefs (so I know the account was setup, or so it appears), but
I don't have a separate inbox.

If it's all or nothing, there should be a prompt (and disable the UI after the
global inbox is enabled).  Otherwise... this is a bug.  I should have a separate
tree for my new separate account.

Not sure if this is W32 as well, only tested on my OS X system.
definitely a bug - it's not all or nothing.  Did the second account get created
as deferred, or did we just not create a folder tree for it for some reason?
never mind, fix checked in bug 243837..., thx, Robert.
marking fixed - will open new bugs for new/remaining issues.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
np

I'll confirm if it's fixed or not tomorrow.
so sad.
i hope this bug never to be fixed.
seperate accounts are the reason i still use mozilla.
And? Bozhan, you're free to decide if Mozilla should use one account or various.
The only thing I don't like is that the default for new accounts in the wizard
is the "merged style".
I tend to think that for the sake of evangelism, the default choice should be
the OE-like behaviour. Us "techies" can always tweak it whatever way we like.
Sorry if this might be a newbie question, but what is the next stable branch
that will be having this implemented?  I suppose Mozilla 1.7 is out of question,
but what about TB 0.7?  Great work, TIA, Lucian
Change summary - this feature is OPTIONAL. I went back and forth about the
default. Personally, I want and have separate accounts, but I think for newbies,
as xave points out, the default should be a global Inbox - the most likely case
is just one POP3 server, and we should default to using the Local Folders Inbox
for that.
Summary: Use one Local Mail tree for all POP3 accounts → Add Option to use one Local Mail tree for all POP3 accounts
TB .8 should have this - it's not impossible that this would be back-ported to
the 1.7 branch after 1.7 ships, so it might be in a 1.7 point release, but that
depends on demand...
New mail notification is now broken: new mail is notified as arriving in "Local
Folders" rather than by the account name.
I'll file a new bug for that...
That's why it's an option. Not to mention that it's already fixed. If you don't
want others to have this option use Outlook.
Whiteboard: fixed-aviary1.0
(In reply to comment #128)
> TB .8 should have this - it's not impossible that this would be back-ported to
> the 1.7 branch after 1.7 ships, so it might be in a 1.7 point release, but that
> depends on demand...

Just downloaded 1.8a hoping to be able to use this feature (global inbox) but
couldn't see it. Am I missing something?
I don't know if 1.8a had this, but nightly trunk builds of seamonkey and tbird
both have the feature, as well as today's aviary branch builds. - but you'll
only see it if you set up a new account, or edit your existing pop3 advanced
server settings to switch to using the global inbox.
*** Bug 46041 has been marked as a duplicate of this bug. ***
(In reply to comment #133)
> I don't know if 1.8a had this, but nightly trunk builds of seamonkey and tbird

Moz 1.8a2 has it, and it's a GREAT enhancement! I'm ditching OE after over a
decade of use. Very happy. Thanks.

Tip: I have 6 different accounts all feeding into and out of the Local
Inbox/Outbox/Sent folders. In order to see what's coming in and going out, I
always set my columns in the messages window to show the "Account" column, so
that I can see it a glance that the emails are for this or that account.
*** Bug 254372 has been marked as a duplicate of this bug. ***
*** Bug 215883 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
Blocks: majorbugs
No longer blocks: majorbugs
*** Bug 159083 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.