Hello Maurice,
Maurice Snellen wrote (in <mid:[EMAIL PROTECTED]>):
>>> Is there a but here or have I constructed my filters wrongly?
>> Can't see a "logical error".
> Actually, in total there are really a whole lot of filters there,
> and it proved that I did make an error in the logic.
So there is/was no bug in NFS?
> 1) Filters should 'collect' all actions-to-be-taken and perform only
> the last move on multiple moves.
Don't know, but I think 9Val would have a lot of work to fulfill this
wish, because I think this is a design problem/wish. Further more the
advantages seem to be small - means only someone one with a simalar
filtering and a lot of message would profit from it. And at last, if
your second wish would be fulfilled you could avoid the duplicate in
changing filter system.
So I can see the sense of this wish, but wouldn't support it.
> 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.
Yes, this is a nice wish. I have the same problem like you. A filter
as container filter (with "all messages" condition) can make problems.
So a container filter would be nice.
But I think there are workarounds - I use the first one and in
this moment I think there is a second one.
Imagine:
Filter A <- container filter
Filter A1 <- condition: From Maurice
Filter A2 <- condition: From Boris
Filter B
Filter B1
Filter B2
First, I set the condition of A to "all message" - but this brought
troubles, because then Filter B will never touched. Also the solution
"continue filtering" isn't that good, because then changes from A, A1
and A2 could undo by B, B1 or B2.
The first solution is: Set the condition of A not to "all messages"
but "Conditions A1 or Conditions A2". In this example, condition of
filter a should be "From Maurice OR From Boris".
The disadvantage of this solution: For every change/addition in a
Subfilter condition must be done in container filter too. But: It
works, at least for me. :-).
The second solution (which is not yet tested) is, to introduce a
"control filter":
Filter A <- container filter
Filter A1
Filter A2
Filter A3 <- control filter
Filter B
Filter B1
Filter B2
In this case, in Filter A [X] continue filtering must be checked.
Filter A3 has condition "All messages" and action "set user param".
Filter B has condition "user param is".
E.g. A message receive, and is catched by Filter A (because "all
messages"). If A1 or A2 matched, A3 doesn't and the param is emtpy -
as a result of this Filter B doesn't match and therefor not undo
actions of A, A1 or A2. But if A1 and A2 doesn't match, A3 matches and
set the param (e.g.) Continue to 1. And because param Continue is 1
Filter B matches.
I don't know if there is a logical error in my idea, but I try this
immediately after send this message. The advantage would be clear: You
don't have to modify container filter if subfilter changes but only
create once one more subfilter.
Of course, if we had a container filter, it would be best and easiest
:-).
--
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/
