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)
SeaMonkey
MailNews: Account Configuration
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
Comment 2•24 years ago
|
||
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
Reporter | ||
Comment 3•24 years ago
|
||
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.
Comment 5•24 years ago
|
||
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.
Updated•24 years ago
|
OS: Windows 2000 → All
Hardware: PC → All
Comment 7•23 years ago
|
||
Whats the status on this bug? Last real comment was on 2000-10-29 11:32.
Reporter | ||
Comment 8•22 years ago
|
||
Mass removing self from CC list.
Reporter | ||
Comment 9•22 years ago
|
||
Now I feel sumb because I have to add back. Sorry for the spam.
Comment 10•22 years ago
|
||
*** Bug 165183 has been marked as a duplicate of this bug. ***
Comment 11•22 years ago
|
||
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.
Comment 12•22 years ago
|
||
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.
Comment 13•22 years ago
|
||
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.)
Comment 14•22 years ago
|
||
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.
Updated•22 years ago
|
Summary: [RFE] Use one Local Mail tree for all accounts → [RFE] Use one Local Mail tree for all POP3 accounts
Updated•22 years ago
|
Summary: [RFE] Use one Local Mail tree for all POP3 accounts → Use one Local Mail tree for all POP3 accounts
Comment 15•22 years ago
|
||
*** Bug 176980 has been marked as a duplicate of this bug. ***
Comment 16•22 years ago
|
||
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.
Comment 17•22 years ago
|
||
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. . . .
Comment 18•22 years ago
|
||
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.
Comment 19•21 years ago
|
||
I definitely have been wanting this for a while - and it keeps me using OE for some of my mail needs. Vote +1.
Comment 20•21 years ago
|
||
*** Bug 194641 has been marked as a duplicate of this bug. ***
Comment 21•21 years ago
|
||
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.
Comment 22•21 years ago
|
||
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 :)
Comment 23•21 years ago
|
||
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.
Comment 24•21 years ago
|
||
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
Comment 25•21 years ago
|
||
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.
Reporter | ||
Comment 26•21 years ago
|
||
And you can't put the "Local Folders" account on top either (Bug 61078). Not much better.
Comment 27•21 years ago
|
||
> 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.
Comment 28•20 years ago
|
||
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.
Comment 29•20 years ago
|
||
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.
Comment 30•20 years ago
|
||
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.
Comment 31•20 years ago
|
||
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.
Comment 32•20 years ago
|
||
(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.
Comment 33•20 years ago
|
||
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.
Comment 34•20 years ago
|
||
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.
Comment 35•20 years ago
|
||
*** Bug 190087 has been marked as a duplicate of this bug. ***
Comment 36•20 years ago
|
||
*** Bug 237679 has been marked as a duplicate of this bug. ***
Comment 37•20 years ago
|
||
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.
Comment 38•20 years ago
|
||
(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.
Comment 39•20 years ago
|
||
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.
Comment 40•20 years ago
|
||
*** Bug 208332 has been marked as a duplicate of this bug. ***
Comment 41•20 years ago
|
||
(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.
Comment 42•20 years ago
|
||
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.
Comment 43•20 years ago
|
||
(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". ;-)
Comment 44•20 years ago
|
||
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
Comment 45•20 years ago
|
||
(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. ...
Comment 46•20 years ago
|
||
(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
Comment 47•20 years ago
|
||
(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.
Comment 48•20 years ago
|
||
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?
Comment 49•20 years ago
|
||
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?
Comment 50•20 years ago
|
||
(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.
Comment 51•20 years ago
|
||
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.
Comment 52•20 years ago
|
||
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).
Comment 53•20 years ago
|
||
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 :)
Comment 54•20 years ago
|
||
(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 55•20 years ago
|
||
Comment 2 says it all. No further comments needed, only volunteers.
Assignee | ||
Comment 57•20 years ago
|
||
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.
Assignee | ||
Updated•20 years ago
|
Attachment #147944 -
Flags: superreview?(mscott)
Updated•20 years ago
|
Attachment #147944 -
Flags: superreview?(mscott) → superreview+
Comment 58•20 years ago
|
||
(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?
Comment 59•20 years ago
|
||
<< 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.
Assignee | ||
Comment 60•20 years ago
|
||
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.
Assignee | ||
Comment 61•20 years ago
|
||
Assignee | ||
Updated•20 years ago
|
Attachment #148009 -
Flags: superreview?(mscott)
Updated•20 years ago
|
Attachment #148009 -
Flags: superreview?(mscott) → superreview+
Assignee | ||
Comment 62•20 years ago
|
||
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.
Comment 63•20 years ago
|
||
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.
Assignee | ||
Comment 64•20 years ago
|
||
X-Account-Key, which is the same header that unsent messages use, so it should already be stripped off before sending...
Comment 65•20 years ago
|
||
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.
Comment 66•20 years ago
|
||
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.
Assignee | ||
Comment 67•20 years ago
|
||
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...
Comment 68•20 years ago
|
||
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? :)
Comment 69•20 years ago
|
||
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)
Assignee | ||
Comment 70•20 years ago
|
||
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.
Comment 71•20 years ago
|
||
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?
Comment 72•20 years ago
|
||
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.
Assignee | ||
Comment 73•20 years ago
|
||
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 74•20 years ago
|
||
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.
Assignee | ||
Comment 75•20 years ago
|
||
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...
Assignee | ||
Updated•20 years ago
|
Attachment #148083 -
Flags: superreview?(mscott)
Comment 76•20 years ago
|
||
> 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.
Assignee | ||
Comment 77•20 years ago
|
||
Assignee | ||
Updated•20 years ago
|
Attachment #148209 -
Flags: superreview?(mscott)
Updated•20 years ago
|
Attachment #148083 -
Flags: superreview?(mscott) → superreview+
Updated•20 years ago
|
Attachment #148209 -
Flags: superreview?(mscott) → superreview+
Comment 78•20 years ago
|
||
David can you fix folerpane.xul for thunderbird too please? Thanks!
Comment 79•20 years ago
|
||
David, can you fix the Solaris bustage I mentioned in comment 74 in your next checkin?
Assignee | ||
Comment 80•20 years ago
|
||
Kyle, I'm pretty sure I already did...
Assignee | ||
Comment 81•20 years ago
|
||
Assignee | ||
Comment 82•20 years ago
|
||
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.
Assignee | ||
Comment 83•20 years ago
|
||
Assignee | ||
Updated•20 years ago
|
Attachment #148387 -
Flags: superreview?(mscott)
Comment 84•20 years ago
|
||
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+
Comment 85•20 years ago
|
||
(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.
Comment 86•20 years ago
|
||
(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.
Assignee | ||
Comment 87•20 years ago
|
||
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...
Reporter | ||
Comment 88•20 years ago
|
||
(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?
Jerry, that's bug 87987.
Assignee | ||
Comment 90•20 years ago
|
||
In this context, why does it need to be editable? You can just pick the identity you want from the dropdown.
Assignee | ||
Comment 91•20 years ago
|
||
whoops, last patch made get new mail half run in the selected folder...
Reporter | ||
Comment 92•20 years ago
|
||
(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.
Assignee | ||
Updated•20 years ago
|
Attachment #148450 -
Flags: superreview?(mscott)
Updated•20 years ago
|
Attachment #148450 -
Flags: superreview?(mscott) → superreview+
Comment 93•20 years ago
|
||
(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.
Comment 94•20 years ago
|
||
> ..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.
Assignee | ||
Comment 95•20 years ago
|
||
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.
Reporter | ||
Comment 96•20 years ago
|
||
(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?
Comment 97•20 years ago
|
||
(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.
Comment 98•20 years ago
|
||
(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 :)
Comment 99•20 years ago
|
||
(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?
Comment 100•20 years ago
|
||
(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.
Comment 101•20 years ago
|
||
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.
Comment 102•20 years ago
|
||
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?
Comment 103•20 years ago
|
||
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?
Assignee | ||
Comment 104•20 years ago
|
||
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...
Comment 105•20 years ago
|
||
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)
Assignee | ||
Comment 106•20 years ago
|
||
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.
Assignee | ||
Updated•20 years ago
|
Attachment #148629 -
Flags: superreview?(mscott)
Updated•20 years ago
|
Attachment #148629 -
Flags: superreview?(mscott) → superreview+
Comment 107•20 years ago
|
||
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 `;'
Assignee | ||
Comment 108•20 years ago
|
||
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.
Assignee | ||
Updated•20 years ago
|
Attachment #148898 -
Flags: superreview?(mscott)
Updated•20 years ago
|
Attachment #148898 -
Flags: superreview?(mscott) → superreview+
Assignee | ||
Comment 109•20 years ago
|
||
Assignee | ||
Comment 110•20 years ago
|
||
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)
Updated•20 years ago
|
Attachment #149052 -
Flags: superreview?(mscott) → superreview+
Comment 111•20 years ago
|
||
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.
Assignee | ||
Comment 112•20 years ago
|
||
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...
Comment 113•20 years ago
|
||
(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.
Assignee | ||
Comment 114•20 years ago
|
||
>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.
Comment 115•20 years ago
|
||
(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.
Comment 116•20 years ago
|
||
> 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.
Assignee | ||
Comment 117•20 years ago
|
||
A much more common scenario is just a public and a private pop3 server, which do require two separate accounts, even in your example...
Comment 118•20 years ago
|
||
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.
Assignee | ||
Comment 119•20 years ago
|
||
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?
Assignee | ||
Comment 120•20 years ago
|
||
never mind, fix checked in bug 243837..., thx, Robert.
Assignee | ||
Comment 121•20 years ago
|
||
marking fixed - will open new bugs for new/remaining issues.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 122•20 years ago
|
||
np I'll confirm if it's fixed or not tomorrow.
Comment 123•20 years ago
|
||
so sad. i hope this bug never to be fixed. seperate accounts are the reason i still use mozilla.
Comment 124•20 years ago
|
||
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".
Comment 125•20 years ago
|
||
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.
Comment 126•20 years ago
|
||
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
Assignee | ||
Comment 127•20 years ago
|
||
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
Assignee | ||
Comment 128•20 years ago
|
||
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...
Comment 129•20 years ago
|
||
New mail notification is now broken: new mail is notified as arriving in "Local Folders" rather than by the account name.
Assignee | ||
Comment 130•20 years ago
|
||
I'll file a new bug for that...
Reporter | ||
Comment 131•20 years ago
|
||
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.
Assignee | ||
Updated•20 years ago
|
Whiteboard: fixed-aviary1.0
Comment 132•20 years ago
|
||
(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?
Assignee | ||
Comment 133•20 years ago
|
||
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.
Assignee | ||
Comment 134•20 years ago
|
||
*** Bug 46041 has been marked as a duplicate of this bug. ***
Comment 135•20 years ago
|
||
(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.
Assignee | ||
Comment 136•20 years ago
|
||
*** Bug 254372 has been marked as a duplicate of this bug. ***
Comment 137•20 years ago
|
||
*** Bug 215883 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•20 years ago
|
Keywords: helpwanted → fixed-aviary1.0
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 138•18 years ago
|
||
*** Bug 159083 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•