Re: [Evolution] feature request: filters management

[Not Zed <notzed ximian com>]

On Wed, 2002-06-19 at 23:52, Not Zed wrote:
> sounds like you should be using procmail, which was designed for this
> type of thing.

But having said that ...

> On Thu, 2002-06-20 at 11:22, Florin Andrei wrote:
> > I would like to see two butons in the Filters utility: "Move all the way
> > up" and "Move all the way down".

This would probably solve some filter management problems, and is
certainly easy enough to implement, but it doesn't seem like a generally
useful solution to the problem of managing large lists, as you allude to
later in this mail.

> > Also, it would be nice to be able to define "filter categories" and
> > configure the order of the categories.
> > This way, if i define a filter in the category that's at the beginning
> > of the chain, i'm sure it goes before many others, and i only have to
> > tweak the order of the filters inside that category.
> > Same for categories at the end of the chain.

Do you think this would map, for example, to a tree (as mentioned
elssewhere)?  Where the priority order is still determined by the
vertical order of a fully expanded tree, but it would let you hide a lot
of rules.  I'm not sure how you would easily represent order and
multiple categories without a tree.

> > Example:
> >
> > I usually create four types of filters. All of them have "stop
> > processing" as the last action. Except for the first category, the only
> > other action of the filters is usually "move to some folder".
> >
> > 1. anti-spam, anti-stoopid, anti-kaka. These are right at the beginning,
> > and their default action is "delete, then stop processing"

Why aren't these just one rule?

> > 2. cronjobs: these are messages sent by automated processes. I want to
> > filter them out into their own folders, no matter how they reach me (via
> > mailing lists or directly)
> > 3. mailing lists

One of the ximian guys had an idea, i think for filters (it may have
been for vfolders) where you have a single meta-rule that automagically
maps a bunch of mails to different mailing list folders, without having
to have a separate rule for each.  I'm still not fond of it because the
mailing list detection code is sketchy, so you probably need specific
rule matching in each case anyway.  But that might be another option,
specify a bunch of lists you're interested about in the rule, and the
matching folders they should move to.

> > 4. humans: these are after the mailing lists, because i want to keep
> > personal messages from humans (not from cronjobs) in separate folders
> > only when they come directly, not through a mailing list
> >
> > Problem is, i have like 200 filters, and when i define a new one, it's a
> > chore to move it up to its category.

I really do stand what i said before.  If you have this many rules, you
should probably consider using procmail, with a maildir backend. 
Evolution works quite fine with this kind of setup, and it lets the
filtering happen in the background without evolution running, and a lot
lot more flexibility and managability.

Without much work we could probably implement a filter rule that just
ran messages through procmail rather than doing the filtering ourselves.

The filter code was designed for 'the average Joe, and then a fair bit',
not every conceivable mail usage pattern imaginable.

> > Not to mention it's impossible to validate anything, the list is
> > unmaintainable, and overall the filters management is horrendous once
> > you have more than like 100 filters (wich happens very easy these days).

I think any gui solution will meet this same problem.  It might take
more filter rules, but it will happen.  The windows 'tcp' setup window
is really fine if you're configuring 2 machines, but after 10 it gets
rather tiresome ...  The windows explorer's expanding tree is fine if
you're managing 100 directories, but hit 1000 and it isn't so easy to
use.

> > If i were able to specify the category when i create a filter, it would
> > be much easier. Then it's only a matter to tweak the order inside a
> > category.
> > Of course, the order of the categories themselves has to be modifiable.

Well, if it was a tree it would be explictly assigned.  I guess even if
the gui isn't a tree it would be stored the same way anyway.

I think there's some bug about improving the filter/vfolder gui, but i
think its looking at some stuff nobody cares about terribly.