On Saturday, November 20, 2004 at 12:32 Mau [M] wrote: >> 1) Filters should 'collect' all actions-to-be-taken and perform only >> the last move on multiple moves.
M> because it would reduce the possibilities of what you can do with M> filters right now. Would you care to elaborate on this? Why would that be true? Can you give an example of a structure of filters and subfilters with actions that would be hampered by this? >> 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. M> If I have understood correctly what you want to do I would also oppose M> to this wish because I think there are ways of doing what you want. They M> way that things are now that processing of a filter depends _only_ on the M> previous filters triggering or not and on the "continue processing" M> status of previous filters is the correct way of doing things. Making M> the processing of a filter depend on the triggering or not of filters in M> a lower hierarchy would break the whole purpose of the hierarchy M> 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), I fail to see why introducing a 'container-only' filter would seriously break the purpose of the hierarchy. True, the advantage of the hierarchy is that instead of having to go through one long list of filters where a group of filters might be partially checking for the same criteria, one can now define the criteria that a group of filters share at a higher level and thus avoid unnecessary processing of filters that would not have matched anyway. I had expected though, that besides being able to group filters because of common criteria, I would also be able to easily group filters that belong together on organizational grounds in a single container. For instance, I have a lot of TB! lists, not all of which are run on the same listserver. As a result, there is no set of criteria (short of adding all subfilter-criteria to the parent) that allows me to group them. The purpose of the 'container-only' parent filter is purely for usability to keep filters more organized: all filters pertaining to lists go in one container. A solution based on parameters and/or colorgroups feels to me like dragging something in there that doesn't belong. 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. The need to group filters for the purpose of usability and organizing of filters is in my opinion reason enough to make it possible. 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. 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. -- Greetings, Maurice Windows XP 5.1 Build 2600 Service Pack 2 The Bat! v3.0.2.7; Bayes Filter Plugin v1.5.6; AJS v0.6; MyMacros 1.11a; ________________________________________________________ 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/
