Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

NEW
Unassigned

Status

MailNews Core
Filters
P3
enhancement
18 years ago
6 months ago

People

(Reporter: (not reading, please use seth@sspitzer.org instead), Unassigned)

Tracking

(Blocks: 1 bug)

Dependency tree / graph
Bug Flags:
wanted-thunderbird3 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [delight])

Attachments

(1 obsolete attachment)

Whiteboard: HELP WANTED
Target Milestone: M15

Updated

18 years ago
Assignee: phil → bienvenu

Description

18 years ago
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)

Updated

18 years ago
QA Contact: lchiang → laurel

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 1

18 years ago
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

Comment 2

18 years ago
Reopen mail/news HELP WANTED bugs and reassign to nobody@mozilla.org

Updated

18 years ago
Keywords: helpwanted

Updated

18 years ago
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

Updated

15 years ago
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.

Comment 3

15 years ago
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)

Comment 4

15 years ago
Very odd.  Nonetheless, sorry!  I'll be more careful.

Updated

15 years ago
Blocks: 91498

Comment 5

15 years ago
*** Bug 184391 has been marked as a duplicate of this bug. ***

Comment 6

15 years ago
*** Bug 185016 has been marked as a duplicate of this bug. ***

Comment 7

15 years ago
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

Comment 9

15 years ago
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)

Comment 10

15 years ago
*** Bug 162780 has been marked as a duplicate of this bug. ***

Comment 11

15 years ago
*** Bug 199697 has been marked as a duplicate of this bug. ***

Comment 12

14 years ago
*** Bug 206983 has been marked as a duplicate of this bug. ***

Comment 13

14 years ago
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

Comment 14

14 years ago
*** Bug 220461 has been marked as a duplicate of this bug. ***

Comment 15

14 years ago
Updating component, because I missed finding this when looking for the dupe of 
220461.
Component: Mail Back End → Filters

Comment 16

14 years ago
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.

Comment 17

14 years ago
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. 

Comment 18

14 years ago
*** 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.

Comment 20

14 years ago
as of bug 206050 this can be done with filters

is this now fixed, wfm or wontfix?

Comment 21

14 years ago
no, this is separate from  bug 206050 - you might want the filtered message to
remain unread, but not trigger biff.

Comment 22

14 years ago
I special notification (sound f.e.) should be available for newsgroups, too.

Comment 23

13 years ago
This would solve bug 91052 , too, I think. Duplicate?!

Comment 24

13 years ago
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.

Comment 25

13 years ago
*** Bug 237938 has been marked as a duplicate of this bug. ***
Product: MailNews → Core

Comment 26

13 years ago
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".

Comment 27

13 years ago
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)

Comment 28

13 years ago
*** Bug 216624 has been marked as a duplicate of this bug. ***

Comment 29

13 years ago
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

Comment 30

13 years ago
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

Comment 31

13 years ago
*** Bug 283196 has been marked as a duplicate of this bug. ***

Comment 32

12 years ago
*** Bug 292087 has been marked as a duplicate of this bug. ***

Updated

12 years ago
Blocks: 163993

Updated

12 years ago
No longer blocks: 163993

Comment 33

12 years ago
How is it possible to elevate the priority of this bug?

Comment 34

12 years ago
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?

Comment 35

12 years ago
*** Bug 323758 has been marked as a duplicate of this bug. ***

Comment 36

12 years ago
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.  

Comment 37

11 years ago
*** Bug 341777 has been marked as a duplicate of this bug. ***

Comment 38

11 years ago
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.

Comment 39

11 years ago
(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.

Updated

10 years ago
Duplicate of this bug: 249938

Updated

10 years ago
Duplicate of this bug: 378844

Comment 42

10 years ago
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

Comment 43

10 years ago
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.

Comment 44

10 years ago
Joao, that may be true of the IMAP data model, but that does not appear to be how Thunderbird organises it's data model.

Comment 45

10 years ago
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.

Comment 46

10 years ago
Created attachment 288816 [details] [diff] [review]
Proposed patch to add a folder flag for notification

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)

Updated

10 years ago
Attachment #288816 - Flags: superreview? → superreview?(mscott)

Comment 47

10 years ago
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 48

10 years ago
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)
Duplicate of this bug: 411074

Comment 50

10 years ago
Today is my birthday (23) and I'd like to see the Guinness world record attempt aborted and this enhancement enacted :D

Updated

10 years ago
Duplicate of this bug: 385772

Updated

9 years ago
Blocks: 438441

Updated

9 years ago
Flags: wanted-thunderbird3?

Updated

9 years ago
Flags: wanted-thunderbird3? → wanted-thunderbird3+

Comment 52

9 years ago
Since I've been looking at this, I'll put my name on the assigned.
Status: NEW → ASSIGNED

Updated

9 years ago
Assignee: nobody → kent
Status: ASSIGNED → NEW

Comment 53

9 years ago
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
Duplicate of this bug: 443110

Comment 55

9 years ago
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.

Comment 56

9 years ago
(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.

Comment 57

9 years ago
> 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.

Comment 58

9 years ago
no one's suggesting not showing it as unread; the question is whether it would show as "new".

Comment 59

9 years ago
> 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. :)

Comment 60

9 years ago
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"

Comment 61

9 years ago
(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)

Comment 62

9 years ago
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.

Comment 63

9 years ago
(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.

Comment 64

9 years ago
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.

Updated

9 years ago
Blocks: 443749
(Assignee)

Updated

9 years ago
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?

Comment 67

9 years ago
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

Comment 68

9 years ago
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]

Updated

9 years ago
Duplicate of this bug: 460279

Updated

9 years ago
Duplicate of this bug: 373182

Comment 71

9 years ago
Compare bug 272125: Ignore Junk mail in biff.

Comment 72

9 years ago
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).

Comment 73

9 years ago
Kent, that rocks, very nice.

Updated

9 years ago
No longer blocks: 438441
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-

Comment 75

9 years ago
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

Comment 76

9 years ago
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.

Updated

8 years ago
Duplicate of this bug: 264634

Comment 78

8 years ago
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.

Updated

6 years ago
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: → bug 201420
See Also: → bug 479282
You need to log in before you can comment on or make changes to this bug.