User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 Hi. I would like some kind of system where there is a correlation between the address book, mail filters, and local folders. I mean, typically, I have one contact per folder, and I would like to have a streamlined way to: 1) create new folders for contacts that I select; 2) create filters for contacts based on their email addresses; 3) be able to filter all messages from a given contact into their folder based on the list of address in their contact properties sheet; 4) generate filters to move sent messages to the same persons folder. Right now, it all involves a whole bunch of typing whereas foreseeably I could do it with just a few clicks and no typing at all (the folder name would just be the contact's name). I think this would be a very useful system and save the whole headache with filters in the first place ... many people decide not to create them just because they're so awkward to set up and if you have 1000+ contacts it's no fun. I'm submitting this as a database bug because basically I don't think there's any tangible sort of relationship between addresses, contacts, folders, and filters and that there should be. Then again, how much do other people want this? Who knows. Reproducible: Always Steps to Reproduce: 1. 2. 3.
really, this is not a Mail DB problem - the mail db category is for the summary db kept for each mail folder, not for a global db of information about address books, mail filters, and local folders. I'll change the component to mail window front end since you're really looking for a UI that allows you to add a folder for a given user in your AB and set up a mail filter to move mail from that user into the folder. There's no backend required for this; all the backend support is there; we'd need a front end command to hook this all together.
Assignee: bienvenu → nobody
Status: UNCONFIRMED → NEW
Component: Mail Database → Mail Window Front End
Ever confirmed: true
Summary: correlation between address book, folders, and filters → RFE correlation between address book, folders, and filters
I suppose I'll give a more concrete example of what I mean. The most basic functionality would let me do this: 1. Create some contact with multiple email addresses (currently only 2 are supported, we need a list just like Outlook Express, with a default address) 2. Create folder for contact, or associate existing folder with a contact. The folder name can be anything, but I'm mainly thinking of cases where the folder name and contact name are the same. This means you also need some field for each folder saying which contact it is associated with, and a field for each contact saying which folder it is associated with. 3. Create filters that move all messages from that contact (any email address) and to me (any email address -- I should also be in the address book I suppose) into the folder. Additionally create filters that move all messages from me to the contact into the folder. This is the minimum that I'm looking for. However, I think a lot more can be done with this idea. For example: I have a folder called friends (which contains no messages), with the folders of all my friends as subfolders. I want to send a mail to all my friends, but I don't feel like creating a mailing list. I can simply select "friends" and the context menu will give me an option to send a new mail to all subfolders, and then go and pick the default address for each friend from the address book. You could even do something fancy like create a new filter that then moves this message from "sent" to "friends". You could also try to guess which message should go where by looking up the contact in the address book, and if they exist, then trying to find a close match to that person's name in the list of folders. If it exists, ask the user if they want to create filters for this person to go to that folder, else ask if they want a new folder for that person. In the future, you could even get everything integrated with an IM client, so that conversations got saved as messages in a persons folder. The correlation between contacts and folders would be optional, because surely there exist cases where you don't want the above behaviour, but this would be helpful for me in the majority of cases. Cheers.
Does anybody actually *care* about this? Is there somewhere else I should post RFE's? I think it's a REALLY useful enhancement that I haven't seen on other mail programs. It seems that all RFE's that I've ever posted have been ignored. It makes me not want to post them anymore. It's not like just because one person comes up with an idea that nobody else has thought of means it's no good -- in fact, in my experience, that tends to suggest it *is* a good idea. Whatever. You can do what you want with it I suppose since I'm just a user and you're the developers.
we have a lot of people with good ideas and way too few people to implement them. So just because we don't implement your idea doesn't mean it's not a good idea.
Okay, I can understand that. I suppose it would just be nice if there was some actively maintained database of just RFE's so that they didn't get all mixed up with Bugzilla. I mean, most open source projects have bug trackers as well as feature trackers. If I want to learn how to implement this particular RFE on my own, where can I start? It doesn't seem like that much work to me and it might be interesting. I can handle the programming, I just don't know where to start (I've never looked at the Mozilla code base and I would really just like to know which specific parts I would need to change). I would also like to know if I did something like this, would you accept it? So can you help me?
To see the list of open RFE's, you just need to query open bugs with Severity enhancement. I personally think this would be a neat feature set - there are people who arrange their mail this way and this would facilitate that. It's not completely up to me to accept this feature or not; it's up to me and the other module owners to decide if the code is done well enough to accept, and it's up to our UI person (Jennifer Glick) to decide if the UI is acceptable. To me, the main challenges here are UI challenges - we need to make this reasonably accessible without making our already somewhat complicated UI more complicated. I believe there has been some talk of having a contact manager, but I haven't been involved in those discussions. I think the best way to start is probably small, get your feet wet with the code base before diving deep into the feature area. The ideas you described in your first comment are mostly implementable in js, w/o extending the backend code much if at all. Some of the more expansive ideas would involve more backend changes (like adding a list of e-mail addresses instead of just two email addresses per contact). Or associating a folder with a contact. So I'd pick something like adding a menu item to create a filter and folder for a particular contact from a user name/e-mail address and work on that. Note that this is similar to the existing feature of creating a filter from a message, with the added idea of offering to create a new folder for messages from that user. www.mozilla.org has instructions for pulling and building the code. Once you have that working, you'd need to look through the mailnews code, which is in mozilla/mailnews. There are subdirectories for various components, e.g., addressbook, news, imap, etc. base/search contains the filter stuff. base/src contains the core backend code. base/resources/content contains a lot of the front end js and xul code. Let me know when you have questions.
I can't work on this yet (too busy! just like you!) so I'm not assigning it to myself. I'm marking this dependency because I need real boolean logic in filters to get it working in the best way. For example, for a given contact, I want to associate that contact to a folder and then have a set of filters. The most minimal set for contactA would be: if (((sender == contactA) && (to == me)) || ((sender == me) && (to == contactA))) then move_to_folder(); Because otherwise (as is the case with my current filters), some mail (typically non-ML mail that is sent to a bunch of people) gets directed into the wrong folder. I don't know if there's a bug for this, but I'm sure Bug 59821 would take care of the problems . . . There's another filter meta bug I noticed (Bug 66425) ... should this be added to that?
Depends on: 59821
Please see my comments here... Bug 166842 - [RFE] Ability to import and export message filters http://bugzilla.mozilla.org/show_bug.cgi?id=166842#c14
Summary: RFE correlation between address book, folders, and filters → correlation between address book, folders, and filters
*** Bug 242359 has been marked as a duplicate of this bug. ***
As noted at the dupe: Automatically file reply with original message (item 4 in the original report) is bug 177040. I think the better implementation of this would not require an explicit filter; instead, it would require an entry in the address book for "folder" (similar to bug 65135). There would be a built-in filter (perhaps visible/disable-able in the filters list) for "If Sender in address book AND address book specifies folder, THEN move message to that folder". But that *would* require new back-end work in the address book and filter criteria.
Bug 285929 is specifically about adding a 'Folder' field to the Address Book entry. The rest of this is specific to filtering.
Component: MailNews: Main Mail Window → MailNews: Filters
Depends on: 285929
OS: Windows 2000 → All
Product: Mozilla Application Suite → Core
QA Contact: laurel → filters
Hardware: PC → All
*** Bug 363579 has been marked as a duplicate of this bug. ***
I look back and feel I should apologize for whinyness in my initial comments on this bug. So I do. That is all.
possible to do as an extension?
Summary: correlation between address book, folders, and filters → filter to folder specified in address/address book
You need to log in before you can comment on or make changes to this bug.