Hello Maurice, Maurice Snellen wrote (in <mid:[EMAIL PROTECTED]>):
>>> 2) It should be possible to create a purely organizational container >>> level (sub)filter where processing of filters further down the list >>> occurs automatically if none of the subfilters yielded an action. >> If I have understood correctly what you want to do I would also oppose >> to this wish because I think there are ways of doing what you want. They >> way that things are now that processing of a filter depends _only_ on the >> previous filters triggering or not and on the "continue processing" >> status of previous filters is the correct way of doing things. Making >> the processing of a filter depend on the triggering or not of filters in >> a lower hierarchy would break the whole purpose of the hierarchy >> structure. > While I don't support Boris' suggestion to solve this problem with > yet another checkbox (I agree with you that this would needlessly > complicate things), It might be more complicate than a container only filter - but also more powerfull. > As a result, there is no set of criteria (short of adding all > subfilter-criteria to the parent) that allows me to group them. Well, you can add all subfilter-criteria to the parent. > A solution based on parameters and/or colorgroups feels to me like > dragging something in there that doesn't belong. So what? It's a workable solution, I can't see the problem. And according to (mid:[EMAIL PROTECTED]) parameters does belong to the topic :-). > Having to do something to the messages (colour group) or using > a parameter that gets checked in a completely unrelated filter(tree) > sounds like making things more complex than they should be. I agree with you, that it /could/ be easier ... > Moreover: the only reason why a colourgroup or parameter is > necessary is to avoid an unwanted situation that would not have > existed if we had 'container-only' parent filters. I strongly disagree here. I think colorgroups hasn't to do anything with making it possible to create a container filter. I hope that parameters can be used one day in templates and might give a few people a greate improvement. And at least, the unwanted situation is, that sub-filter is used for "container filter", but they aren't coded to fulfill that function. Params give you the possiblity, to use sub-filter for container filter - which is not a bad thing at all. > The fact that the only way to get filters further in the list > processed if an earlier filter has an 'all messages' criterium is to > set 'continue processing' on it which then introduces the problem > that messages already handled by earlier subfilters might get > re-handled by later filters. Solving this by using additional > actions to every subfilter of the earlier 'all messages' filter as > well as having to complicate the later parents in my opinion > needlessly complicates matters, requires additional work for each > new filter and is also error-prone because if you forget to add the > additional actions to a newly created filter, thing might get broken > again and you'll be bughunting in your own filters. The problem wouldn't exist, if you won't abuse sub-filter to container filter - or if you do so - why not set (logical) correct conditions (and not a simply "catch all"). -- Regards, Boris Anders, http://www.batboard.de ________________________________________________________ Current beta is 3.0.2.7 Rush | 'Using TBBETA' information: http://www.silverstones.com/thebat/TBUDLInfo.html IMPORTANT: To register as a Beta tester, use this link first - http://www.ritlabs.com/en/partners/testers/
