After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 223465 - Adding new filters to the end of the rules list is non-optimal
Adding new filters to the end of the rules list is non-optimal
Status: RESOLVED DUPLICATE of bug 205616
Product: evolution
Classification: Applications
Component: Mailer
pre-1.5 (obsolete)
Other other
: Normal minor
: Future
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2002-04-16 03:05 UTC by Russell Steinthal
Modified: 2004-07-26 23:14 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Russell Steinthal 2002-04-16 03:05:26 UTC
The current behavior of adding new filters to the end of the rules list is
OK in the simple case, but it interferes with more complicated filter
schemes which rely on a particular rule being last.

For example, I use two or three rules which move mail which doesn't contain
my userid (and which doesn't come from certain "good" domains) into my
"Spam" folder, but this only works if they execute after all of my mailing
list filter rules.  Ideally, when I add a new rule, it should go above my
"last" rules.

This could be fixed by:

1. Adding new filter rules to the top of the rules list, although this
would probably just shift the problem to other types of filter logic which
rely on a rule being first.

2. Allowing certain rules to be marked as "Keep at top" or "Keep at
bottom", and then adding new mails above the highest "Keep at bottom" or
below the lowest "Keep at top."

3. Allowing the user to define a specific "insertion point" for new rules
(in advance, since the "Create filter based on..." options don't show the
filter list to the user.)

#2 is probably the best of the 3 solutions, IMHO...
Comment 1 André Klapper 2004-07-26 23:14:27 UTC

*** This bug has been marked as a duplicate of 205616 ***