Open Bug 11040 Opened 25 years ago Updated 8 months ago

Allow filters to control biff UI (i.e. only notify me of "important" messages)

Categories

(MailNews Core :: Filters, enhancement, P3)

Product:
MailNews Core
Component:
Filters
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: sspitzer, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [delight])

Attachments

(1 obsolete file)

Whiteboard: HELP WANTED
Target Milestone: M15
Assignee: phil → bienvenu
I was thinking of doing this - it's just a matter of adding a filter action, and doing a folder notification. But if someone beats me to it, that's fine too.
Summary: Allow filters to control biff UI (i.e. only notify me of "important" messages) → [HELP WANTED]Allow filters to control biff UI (i.e. only notify me of "important" messages)
QA Contact: lchiang → laurel
Status: NEW → ASSIGNED
Bulk-resolving requests for enhancement as "later" to get them off the Seamonkey bug tracking radar. Even though these bugs are not "open" in bugzilla, we welcome fixes and improvements in these areas at any time. Mail/news RFEs continue to be tracked on http://www.mozilla.org/mailnews/jobs.html
Reopen mail/news HELP WANTED bugs and reassign to nobody@mozilla.org
Keywords: helpwanted
Summary: [HELP WANTED]Allow filters to control biff UI (i.e. only notify me of "important" messages) → Allow filters to control biff UI (i.e. only notify me of "important" messages)
Whiteboard: HELP WANTED
Target Milestone: M15
Summary: Allow filters to control biff UI (i.e. only notify me of "important" messages) → Allow filters to control biff UI (i.e. only noti.
mozillamail@myrealbox.com - when you added yourself to the cc: list, you cut off the summary. Restoring summary.
Summary: Allow filters to control biff UI (i.e. only noti. → Allow filters to control biff UI (i.e. only notify me of "important" msg)
Very odd. Nonetheless, sorry! I'll be more careful.
Blocks: 91498
*** Bug 184391 has been marked as a duplicate of this bug. ***
*** Bug 185016 has been marked as a duplicate of this bug. ***
Reassigning to correct component (I think) - maybe that way this might get some attention too...
Assignee: nobody → mscott
Component: Mail Back End → Mail Notification
QA Contact: laurel → stephend
Restoring old assignment, component and CC: fields.
Assignee: mscott → nobody
Component: Mail Notification → Mail Back End
QA Contact: stephend → laurel
Maybe this should be in mail notidication component anyway (I was responsible for the 185016 dupe, just because I was looking for this feature in the 'mail notification' component (which would make more sense from a user point of view)
*** Bug 162780 has been marked as a duplicate of this bug. ***
*** Bug 199697 has been marked as a duplicate of this bug. ***
*** Bug 206983 has been marked as a duplicate of this bug. ***
Nothing seems to be happening with this bug. The way I see it, although this is marked as enhancement, this is a major pain in the ass, whoever is using filters to weed out junk mail. Mozilla has an excellent Junk Mail Control right now, I am really really happy with it. Except now I keep getting these mail notifications, when I go check I don't see any mail, because it has been moved to Junk folder. It will be really really nice to have this
*** Bug 220461 has been marked as a duplicate of this bug. ***
Updating component, because I missed finding this when looking for the dupe of 220461.
Component: Mail Back End → Filters
As written, this strikes me as an overly complex solution to the problem. The problem as I see it is that when junk arrives, even if you have the Junk Mail Controls set to move it to a junk folder, you still get the same notification that you would if it weren't junk. If you want a whole extra feature that lets you finely control the relationship between filters, that's more complicated. But how about a simple change to notification that makes ti ignore messages that have been marked as junk? And add a checkbox to the Junk Mail Controls window that turns this behavior on or off.
Well, junk is one part, but mailinglists are, for me, just as big of a problem. I've got several mailinglist generating, in total, hundreds of messages a day (more than the amount of spam I receive). I don't want to be notified of those either.
*** Bug 226745 has been marked as a duplicate of this bug. ***
A suggestion (don't know if this is hard to imlpement or not) is to have the ability to mark a folder as "don't send biffnotifications for this folder". That way you could set up such a folder for your mailinglist or whatever you want to not be notified and create a filter to move messages to that folder. For me that would even allow me to not use filters at all since my imap server sorts messages for me. This could also solve bug 91498 since you could just mark the trashfolder with this flag.
as of bug 206050 this can be done with filters is this now fixed, wfm or wontfix?
no, this is separate from bug 206050 - you might want the filtered message to remain unread, but not trigger biff.
I special notification (sound f.e.) should be available for newsgroups, too.
This would solve bug 91052 , too, I think. Duplicate?!
This might not solve bug 91052, depending on the implementation. I suspect that this bug would be fixed by having the filter action reduce the count of "messages requiring notification" and after all messages were processed, Moz would only notify if the count were greater than zero. Since there is currently no notification for newsgroups, such an action wouldn't change the behavior there.
*** Bug 237938 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
I am surprised with 40+ votes this bug hasn't seen any bugzilla activity in several months. I am using 0.9, and this is the one thing about TB that irritates me right now. I am on a mailing list for school with a pop3 account. I have to be on this list, and I have to read this mail occssionally, so I can't just delete it. Currently, I mark it as junk and filter it to its own "listserv" folder (different than a general junk/spam folder). However, 90% of my new mail notifications are this dumb listserv, which doesn't need my attention but once every few days. I would expect that a message flagged as junk should *not* notify the user the email has arrived. It is, afterall, "junk".
I totally agree with orion. I also searched for bugs with as many votes as this one (46 today), and only found around 150 such bugs (in all of bugzilla) - so how can such a bug just lie there for over 5 years? (In reply to comment #26)
*** Bug 216624 has been marked as a duplicate of this bug. ***
After having users wait over 5 years for a solution, I'll take a stab at defining the problem and proposing a potential solution. This is all I can contribute since I know very little about coding stuff for T-bird. I keep revisiting the bug because the current notification system is worthless to me because of spam and mailing lists. Observations: First, it appears the notifications are simply a result of receiving any new messages -- this check apparently is done prior to any processing. In order to prevent unwanted notifications the check would have to be moved to after filtering stage. Also it appears the mail is first loaded into the Inbox, then filtered. One possible solution is: o Move notifications check to later stage o When new mail is available first note the old inbox size and/or time stamp. o Set alert flag to false o Add filtering options for disable alerts. o When processing filters, set flag to true as appropriate o Compare the inbox size and/or time stamp. If these have changed then set the alert flag to true. o Now if the alert flag is true then notify per the general preferences settings. Let's get feedback then hopefully someone is willing to pick-up the coding. -Noel
Change flag to counter, since I just realized the notification show the number of new messages. The counter would be increased for each new message in the filter stage and in the later inbox new message count stage. -Noel
*** Bug 283196 has been marked as a duplicate of this bug. ***
*** Bug 292087 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
No longer blocks: majorbugs
How is it possible to elevate the priority of this bug?
I was looking into writing an extension to do this but am having trouble understanding how the current biff system works. Any starting hints would be welcome: e.g. what are the variable names, function names, broadcasters associated with the new message indicators? I see lots of references to biff, but they lead lots of directions. Which js file should I be hunting in?
*** Bug 323758 has been marked as a duplicate of this bug. ***
No real helpful coding suggestion. I just want to add to the clamor begging someone knowledgable enough to take a stab at it. I turn notifications off entirely now because it's too irritating that they're frequently not my main inbox. I just don't need to read mailing list emails the second they come in, and I already know how to set up filters to sort them by folder. The notification suppression is just an obvious extension of that.
*** Bug 341777 has been marked as a duplicate of this bug. ***
My added two cents: I have 10 or 20 filters categorizing mail into various mailing list folders, and often automatically marking them as "read". Biff (moztraybiff.mozdev.org) often indicates I have new mail, and I'll take a look at the Thunderbird window, only to find an Inbox folder with no new messages, yet still has a star next to it indicating new mail. That's one issue. Ideally, biff would only be activated if my inbox folder has new mail, and none of that new mail was automatically marked as junk and/or scam. I don't know how much of that is configuration, how much of it is this bug, and how much of it is in other bugs (e.g. Bug 232104), but such a system would be perfect for me.
(In reply to comment #0) > I was thinking of doing this - it's just a matter of adding a filter action, > and doing a folder notification. Folder notification is bug 201420. This is a more important issue for IMAP (and maybe other mail types, but not POP) where the mail can be filtered into folders on the server. Suppression of notification when mail moved to certain folders is bug 224573; and suppression of notification for certain mail accounts is bug 104809. Both features could be handled via a filter suppressing notification on a per-message basis, altho I think a per-account setting would be a reasonable feature to implement above and beyond I think the primary aspect of this bug is a filter action to control notification. There are many aspects of this that could be implemented; perhaps the action could be: Notify as: None, Normal, Priority where Normal is the default action taken if no filters change the notification status. If *all* new items are filtered with Notify As, None, then no new notification occurs. If *any* new item is filtered with Notify As, Priority, then the priority alert would apply -- a different sound, a colored tray icon. This could obviously be much more complex, with individually configurable sounds, slide-up appearance, and tray-icon appearance, and there are many RFEs to that effect. Also note that TB has implemented a different alert popup (in Windows, anyway) that shows information about the new messages, and that could also be finetuned even further with filters, if these were allowed to grow to that level of complexity. I think in terms of maintainability and overall usefulness, a three-level scheme as I propose is a decent compromise; it would cover bug 190989, bug 219510, and possibly others I haven't found.
I was looking at how I organized my folders, and it occurred to me that it might be possible to simplify this feature, and yet retain the bulk of it's power. Suggestion: Instead of having sophisticated controls on a per-filter or per-folder basis, have a single flag which can be turned on and off. If this flag is active, then biff notifications are only displayed for mail messages which end up in the "Inbox" folder or one of it's children. This means that you can create child folders under the "Inbox" folder and use filters to route messages there, and still have notifications. Other messages can be routed to folders outside of the "Inbox" folder, and will then will then not result in biff notifications.
Severity: normal → enhancement
QA Contact: laurel → filters
I too think that the filter action would be the best. Noel, if you were using IMAP you would know that all folders are children of the Inbox folder. The flag solution would be useless with IMAP and busy Mailinglists.
Joao, that may be true of the IMAP data model, but that does not appear to be how Thunderbird organises it's data model.
So you are saying that a folder that is a children of the INBOX folder in the IMAP model isn't a children of the INBOX in the Thunderbird data model? I always leave all my mail on the server because I switch computer and OS a lot. Please configure an IMAP account in 2 thunderbird profiles and try to use it like I do. Then you will realize that your suggestion doesn't help me. The only thing I could accept as a compromise would be not to display biff notifications of any folder except the Inbox. But then all the important (as notification worthy) messages would end up in the Inbox.
I've attached a patch and tested it on my local build, both debug and optimized release. Please test and review it. mail/locales/en-US/chrome/messenger/folderProps.dtd appears to be the dtd that is used, but I added the ENTITY tags to mailnews/base/resources/locale/en-US/folderProps.dtd as well. Please also assign the bug to me.
Attachment #288816 - Flags: superreview?
Attachment #288816 - Flags: review?(bienvenu)
Attachment #288816 - Flags: superreview? → superreview?(mscott)
That doesn't seem to fix this bug, isn't it more bug 201420/bug 224573? (I don't really see what the difference between those is.)
Comment on attachment 288816 [details] [diff] [review] Proposed patch to add a folder flag for notification Yes, I agree. I think comment #19 confused me. Marking the attachment as obsolete and will post to bug 201420.
Attachment #288816 - Attachment is obsolete: true
Attachment #288816 - Flags: superreview?(mscott)
Attachment #288816 - Flags: review?(bienvenu)
Today is my birthday (23) and I'd like to see the Guinness world record attempt aborted and this enhancement enacted :D
Blocks: bifftones
Flags: wanted-thunderbird3?
Flags: wanted-thunderbird3? → wanted-thunderbird3+
Since I've been looking at this, I'll put my name on the assigned.
Status: NEW → ASSIGNED
Assignee: nobody → kent
Status: ASSIGNED → NEW
Here is a rough outline of some issues associated with this bug, and my proposed approach. The existing message flag MSG_FLAG_NEW conveys that a new message has been received since the last time the folder was viewed (but only as long as the application remains open - the flag is kept in memory and destroyed when exiting the application). MSG_FLAG_NEW is indirectly tied to BIFF notification and clearing. So what happens when we restrict the class of messages that do BIFF notification? Do we continue to tie this to MSG_FLAG_NEW? That would mean that the NEW flag would only occur on messages that have been filtered to perform BIFF notification. But I believe that the existing NEW flag on messages and folders is useful, and should be preserved even when BIFF notification is modified by a filter. So the approach that I propose is to introduce a new message flag MSG_FLAG_BIFF that would be used for BIFF control, and be the subject of this current bug. The existing MSG_FLAG_NEW flag will continue to operate in roughly the same way that it does currently (though I will probably propose in another bug that MSG_FLAG_NEW be preserved across mail sessions.) If this path is followed, then there may be a need to identify which folders and messages are the one that caused the BIFF notification. I propose that the existing folder and message decoration associated with MSG_FLAG_NEW and BIFF state be modified to show a subtle difference between NEW and BIFF messages. That might be a larger or bolder decoration for the BIFF messages. That change in folder and message decoration will not be part of this current bug however. Currently, message and folder BIFF state is spread between four variables: an array kept in the database, an array kept in the folder, a hasNewMessages boolean, and a count of new messages. The responsibility to maintain hasNewMessages and the new message count is separate from the flag, so each message editor has to set those independently. Prior to completing this bug, I want to simplify and consolidate that process somewhat, at the same time preparing for a possible MSG_FLAG_BIFF. That groundwork is being laid in bug 441932.
Status: NEW → ASSIGNED
Depends on: 441932
NEW and BIFF are strongly tied together, I would say, and I'm not convinced that we should separate them. If we leave them tied together, all the filter action would have to do is clear the NEW flag on the message. I believe when the user says they don't want to be notified about a new message, they don't want it to appear as a new message. If you introduce this new concept of BIFF, does the new message appear in the tooltip for the folder? Presumably not, since I think that should match the new mail alert...and the new message alert will only show messages that have the biff flag set, not the new flag. The folder containing the message will appear to have new messages, with the green flag, but hovering over it will potentially not show any messages... I'm also not convinced that new should persist across mail sessions. The reason we didn't persist it is that folders that you don't often check could potentially have the new flag set for a long time, which reduces the usefulness of that indicator. So I think this boils down to a UI/UE question, so I'm cc'ing Bryan. If we agree that we should change the way new and biff work, that's fine, but I'd like to have some sort of agreement that the change is an improvement.
(In reply to comment #55) > I believe when > the user says they don't want to be notified about a new message, they don't > want it to appear as a new message. That is the critical question. "Appear as a new message" in this context means "have the NEW decoration for the message appear in the message list, decorate the folder in the folder pane with the NEW decoration, and show the message summary in the folder tooltip" > If you introduce this new concept of BIFF, > does the new message appear in the tooltip for the folder? Presumably not ... I would say presumably yes. The folder tooltip should directly match the messages flagged NEW in the folder. > I'm also not convinced that new should persist across mail sessions. The reason > we didn't persist it is that folders that you don't often check could > potentially have the new flag set for a long time, which reduces the usefulness > of that indicator. > Well I would say that it increases the usefulness of the indicator. Whenever you open a folder, even days later, you will see all messages flagged that are new since the last time that you opened the folder. But as I said, this would be the subject of a different bug. > So I think this boils down to a UI/UE question, so I'm cc'ing Bryan. If we > agree that we should change the way new and biff work, that's fine, but I'd > like to have some sort of agreement that the change is an improvement. > I would encourage opinions from anyone else listening to this bug as well.
> I believe when > the user says they don't want to be notified about a new message, they don't > want it to appear as a new message. When I said that *I* didn't want to be notified about a new message, I meant that I want it to appear as an unread message (e.g. bold subject etc) when I open the mail client or restore it from the tasktray but just don't want the tasktray symbol to appear or sound to play.
no one's suggesting not showing it as unread; the question is whether it would show as "new".
> no one's suggesting not showing it as unread; the question is whether it would > show as "new". I should probably just keep out of it then. :)
I think it should still be marked new. New would indicate that the message is "unread and you've never even opened the folder to know what you haven't read" once you see the subject in the list, the message is not 'new'. just as once you see the body, it is not 'unread'. if a folder contains 'new' messages, it too is 'new', just as it "reverse inherits" it's 'unread' status too but Sean's comment was on money. If I may summarize it: "I want it to appear as an unread message .. but just don't want the tasktray symbol to appear or sound to play"
(In reply to comment #59) > > I should probably just keep out of it then. :) > :-) Well, that does bring up the point that many if not most users don't really know what "new" is, and how it's different from unread, which gives us some flexibility to change it (though users who know what it is find it very valuable, I think)
I know the difference, and I find the difference valuable, and I think persisting New across sessions would be beneficial. The new-this-session messages should be known about from the tray indicator and tooltip. However, several longstanding bugs -- the tray icon and account-New flag persisting when shouldn't (all new messages moved to a different account and read there), or clearing when shouldn't (explicit Get New Messages, or in the suite, opening a new mail window), and those several about erroneous New count display in the alert and the tooltip -- all make the distinction less useful than it could be.
(In reply to comment #62) > I know the difference, and I find the difference valuable, and I think > persisting New across sessions would be beneficial. The new-this-session > messages should be known about from the tray indicator and tooltip. > The preceding comment dealt with new versus unread, so I assume that is the "difference" that you know. I would appreciate though any comments you have on the more immediate issue, at least for this bug, of separating "New" from "Biff", allowing more direct control of Biff through filters (this bug) and possibly as a folder property (not this bug), while keeping New as the indicator of "You haven't seen this message yet in the message pane". The tray indicator would match BIFF. The tooltip per folder would match NEW. At the moment for this bug, NEW would not persist over sessions - though it would be more valuable if it did, and that's where I'm headed. It's particularly useful for large volume email lists, RSS feeds, and newsgroups where I want to see what's happened since the last time that I opened the message pane. > However, several longstanding bugs -- the tray icon and account-New flag > persisting when shouldn't (all new messages moved to a different account and > read there), or clearing when shouldn't (explicit Get New Messages, or in the > suite, opening a new mail window), and those several about erroneous New count > display in the alert and the tooltip -- all make the distinction less useful > than it could be. > My work-in-process patch for bug 441932 solves some of the issues involving NEW that I am aware of involving folder-level counts and flags. It does not address the server-level issues, that affect the tray icon and notifications. But those are coming. I'd really like to get to the point where we have precise control of when BIFF goes off - and have a virtual search folder that shows exactly what messages triggered the current notification. Which will bring up another point - when do you clear the BIFF flag? The existing code is inconsistent, which is why for example "explicit Get New Messages" clears NEW in some cases. That should always clear BIFF, but never clear NEW IMHO. Things get trickier with multiple servers all checking mail.
Some practical example. Hope this will help understanding the problem here. I have the "Inbox" and a "Junk" folder. It's a IMAP server and the server automatically sorts junk into the "Junk" folder. So new messages arrive in the Junk and in the Inbox folder in parallel (more in Junk than in Inbox). I would like to get notified only about the messages which are coming in the "Inbox" folder. So I just unchecked the option "Check for new messages" in the "Junk" folder. But every time if a message in the "Inbox" folder arrives, I not only see the Message from the "Inbox", I also see the latest "Junk" messages. Because they are flagged "New" as well. Sometimes the junk messages are newer (future dated) as the messages in the Inbox. So I just see four header lines of junk messages, but the message from the Inbox which triggered the notification isn't visible at all. So it's not just a matter of taste introducing a new "Biff" flag, it's just a must if you would like to allow exclude some messages from the notification. I would like to see which messages are "new" as well, but I don't want get a notification about it. And the "biff" flag can get cleared automatically as soon the notification was shown.
Blocks: 443749
Product: Core → MailNews Core
"Biff" versus "New" semantics do seem to have somewhat subtle interactions. I'd be particularly interested in hearing clarkbw's comments on the UX implications of all this, as well thoughts from Beckley on what the Eudora experience has been on this front...
any implications for calendar?
Keeping on the wanted‑thunderbird3+ list, target ms beta2. rkent tells me it (basically) it should be doable, if only bug 441932 lands.
Keywords: helpwanted
Target Milestone: --- → Thunderbird 3.0b2
Classic Eudora's approach on notifying users of new messages is different from Thunderbird's. Eudora doesn't have a separate message status of new. Instead it bolds mailbox names that have unread mail that are newer than 5 days (solves the old mail problem that bienvenu mentions above, and also persists across sessions), opens up mailboxes that get new mail put in them, and it automatically selects the first unread message at the end of a mailbox when its opened up. I've got these last two items mostly working in Penelope already. One common usage model is that new messages get filtered in to mailboxes, which are then automatically opened up. You then close the mailboxes when you are done dealing with the messages in them. So the open mailbox windows themselves act as the new mail notification system. Eudora also has a filter action to control whether the user gets notified about messages that match the filter criteria, similar to what this bug is suggesting. In addition to opening up mailboxes that get new messages that I mention above, you can also have it play a sound and/or put up a generic dialog saying that you have new mail. You can set the default to do these notifications (or not to) on all messages, and then the filters can override that on a per-message basis. As a filter action you can even open up messages in to their own separate windows so as to really highlight them. On Windows Eudora there is a system tray icon that will tell you how many new messages you have, but not any specific message info like TB's biff. In addition Eudora automatically does not notify the user (in any fashion: sound, new mail dialog, or opening mailboxes) on any messages that are marked as junk, or get transferred to the Trash mailbox by a filter.
Whiteboard: [delight]
Compare bug 272125: Ignore Junk mail in biff.
Now that custom filter actions are possible, I was able to add biff notification suppression as a custom action. My extension to provide this, which will be called FiltaQuilla, should be available soon after TB beta 1 is released (and will work with that version).
Kent, that rocks, very nice.
No longer blocks: bifftones
While this would be nice, we're now at the point in the cycle where we have to start focussing on only the most critical bugs/features. While this would be nice to have, I don't think it belongs in that category. Setting wanted-. That said, Kent, you're more than welcome to submit a patch anyway.
Flags: wanted-thunderbird3+ → wanted-thunderbird3-
Suppression of BIFF is working well for me in the FiltaQuilla extension, so I'm not sure it belongs in the main application anymore (or at least I don't have much motivation to put it there.) I do however wonder how the rest of the world gets along without suppression of BIFF from mailing lists, and the related custom sounds that ToneQuilla gives. Let me remove myself from assigned though to show that I am satisfied with the extension solution.
Assignee: kent → nobody
Status: ASSIGNED → NEW
I manage tbird BIFF by turning it off. It has been useless for me for years. It is useless otherwise. I'll try the extension.
Being able to setup notifications using filters should be part of the base install. Requiring us to use an extension to do this is a poor choice. It's something that MS Outlook does out of the box.
Summary: Allow filters to control biff UI (i.e. only notify me of "important" msg) → Allow filters to control biff UI (i.e. only notify me of "important" messages)
Target Milestone: Thunderbird 3.0b1 → ---
See Also: → 201420
See Also: → 479282
See Also: → 311640
Severity: normal → S3
Duplicate of this bug: 1883906
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: