Delayed filters to be applied after a message is read/replied

RESOLVED EXPIRED

Status

MailNews Core
Filters
--
enhancement
RESOLVED EXPIRED
15 years ago
10 years ago

People

(Reporter: Bogdan Stancescu, Assigned: Navin Gupta)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210

A very nice added feature of filters would be for them to be triggered not by
mail coming in but rather by a predefined action on the e-mail - for instance
being read or replied. I find myself not using filters on some messages because
I want to read them once, and if they end up in some folder I'm almost sure to
never read them -- but not using filters at all means I have to move them to the
respective folder manually, which is obviously tedious. I generally have this
problem with "announce" type e-mails: I want to browse through each e-mail to
see what's new, but I don't want them to end up populating my Inbox.

The way it would work would be for Mozilla to check if a message is marked as
"read" or "replied" whenever the user *defocuses* any e-mail, and check for
matching filters. I'm sure this is not incredibly difficult to implement -- I
just hope someone will find this idea useful enough to take the time to actually
implement it.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
(Reporter)

Updated

15 years ago
Severity: normal → enhancement
(Reporter)

Comment 1

15 years ago
P.S. One very good example of a situation where I'd use these filters is the
very bugzilla notification system -- I want to read all e-mail from bugzilla,
but I don't want them to stay in my Inbox after being read.
Product: MailNews → Core

Comment 2

13 years ago
As a practical matter I don't think a delayed filter this likely to be
implmented as suggested

1. By definition (at least currently), filters are invoked when the mail is
slurped or when manually run.
2. What you're saying is ... moz keep track of which message I've just focused
on and it's prior state "read or undread", and when I move away from it apply a
filter. Sounds modestly complicated to me. 

Further, does it only apply to the inbox, or to any unread message in any folder?

I understand your reason. But the idea needs further refinement or a complete
change in approach.  [BTW, I'm not sure many will sympathize with the notion
that you don't want to visit another folder to check unread mail.]
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → EXPIRED
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.