Re: Bug: Order of actions in NFS
Boris Anders, [BA] wrote: But in some cases the order [of actions] is very important: I agree. Just as filters are matching is done in the order of the filter list, actions should be carried out in the order they appear. It is a difference between copy the message and delete it and delete it and then (try to) copy it. Yup. Deleting the message would make you unable to copy it. So if you wish to copy the message and then delete it, the filter actions should be copy message delete message So I think the best solution is, that TheBat! do its action like they are listed in NFS: flag message copy message park message means, that the copies are flagged, but not parked. I disagree. All three should be done since the message is still available for all three actions to be carried out. I'd certainly want all three to be done if I set them up to be done as such. If this will be realized, it would be good, if TheBat! check (before saving the filter) if there are actions after delete message and move message and remind the user that these action will never be done: Suppose the actions are setup as: delete message run external program play sound Are you saying the latter two actions shouldn't be carried out? I disagree again. Another solution would be, that TheBat! move these action at the end of the list. This would solve bugs like: mid:[EMAIL PROTECTED] and mid:[EMAIL PROTECTED] These bugs are simply bugs that need to be fixed. They aren't symptoms of filter actions needing to be nullified or preventing from occurring because of a prior action. Crippling filter action sequences is a bad way of fixing the problem. The NFS works the same as MDaemon's filtering system. The filter rule interface is in a sentence type fashion. I've attached a capture of one of them. The actions are carried out as they're described in the filter rule. The rule itself, makes it seem to the user that the actions will be carried out in the sequence described. All actions are applied if they can be. Deleting, will delete the message and thus prevent any other actions being carried out on the message. However, other actions can be triggered in so long as it has nothing to do with the direct manipulation of the message that has already been deleted. -- Allie Martin [List Moderator and fellow end-user] · My PGP-Keys: http://key.ac-martin.com · The Bat! v2.12.00 /·\ WinXP Pro (Service Pack 2) . Some minds should be cultivated, others plowed under... attachment: rule.png pgpVJabkcX6mX.pgp Description: PGP signature Current beta is 2.13 'Lucky' Beta/6 | '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/
Re: Bug: Order of actions in NFS
Hello Allie, Wednesday, August 18, 2004, 21:39 you wrote at mid:[EMAIL PROTECTED] So I think the best solution is, that TheBat! do its action like they are listed in NFS: flag message copy message park message means, that the copies are flagged, but not parked. I disagree. All three should be done since the message is still available for all three actions to be carried out. I'd certainly want all three to be done if I set them up to be done as such. Well, all three are carried out to the original message. The original message is flagged, and parked. But the copie isn't parked, because at the moment, the coppy was created, the orginal message wasn't parked. If this will be realized, it would be good, if TheBat! check (before saving the filter) if there are actions after delete message and move message and remind the user that these action will never be done: delete message run external program play sound Are you saying the latter two actions shouldn't be carried out? I disagree again. Yes, with the my first suggestion, maybe the second is better: Another solution would be, that TheBat! move these action at the end of the list. So TheBat! would sort: run external program play sound delete message mid:[EMAIL PROTECTED] mid:[EMAIL PROTECTED] These bugs are simply bugs that need to be fixed. And how? They aren't symptoms of filter actions needing to be nullified or preventing from occurring because of a prior action. I disagree! The filter is: delete message read message If you run that filter, the message disappear (deleted) and appear again, because its marked as read. There are two possibilitys (which i can imagine) to solve this: Sort read message delete message and do it in that sequence or ignore the filter options after move or delete message (with a warning, so the user know what has happend) Crippling filter action sequences is a bad way of fixing the problem. The problems are made by design - so correct the design, the problems will disappear. The NFS works the same as MDaemon's filtering system. The actions are carried out as they're described in the filter rule. The rule itself, makes it seem to the user that the actions will be carried out in the sequence described. Then the first sentence is wrong: NFS don't go in the sequence but random - in NFS it doesn't matter if you select delete message copy message or copy message delete message Or miss I something? -- Regards, Boris Anders, http://www.batboard.de Current beta is 2.13 'Lucky' Beta/6 | '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/
Re: Bug: Order of actions in NFS
Boris Anders, [BA] wrote: I disagree. All three should be done since the message is still available for all three actions to be carried out. I'd certainly want all three to be done if I set them up to be done as such. Well, all three are carried out to the original message. The original message is flagged, and parked. Yes. But the copie isn't parked, .. because the copy is generated prior to the next action being carried out. If you wish the copy to be parked as well, then use the sequence flag message park message copy message to.. In this way you can alter the message prior to copying/moving it to a new location. delete message run external program play sound Are you saying the latter two actions shouldn't be carried out? I disagree again. Yes, with the my first suggestion, maybe the second is better: Ok, let's see. Another solution would be, that TheBat! move these action at the end of the list. So TheBat! would sort: run external program play sound delete message That would be presumptuous and could lead to problems. I haven't thought it through but I'd not wish the actions to be rearranged to carry out what TB! *assumes* the user meant. These bugs are simply bugs that need to be fixed. And how? Actions should always be carried out in the sequence shown. Actions cannot be carried out on messages that have been deleted or moved to another location so all other message specific actions should be specified prior to deletions/moving. Actions after deletions/moving of messages will be carried out only if they are actions that do not need to be applied to the message itself, for example, running an external program or playing a sound. They aren't symptoms of filter actions needing to be nullified or preventing from occurring because of a prior action. I disagree! The filter is: delete message read message If you run that filter, the message disappear (deleted) and appear again, because its marked as read. The problem is that a message that has been deleted cannot be acted on again. That's all. It's a nonsense sort of sequence and the bug lies there. There are two possibilitys (which i can imagine) to solve this: Sort read message delete message The user should make this the sequence, yes. It beats me why one would wish to do that anyway. The problems are made by design - so correct the design, the problems will disappear. A good help file will help here. We know that filtering and how it's carried out depends on the order of the filters. We can't get past that. This is the nature of filtering. The same goes for actions. They're carried out in sequence. In MDaemon, if the filter sequence is to: delete message copy message to folder The message is simply deleted and no copying is performed. To have the message copied and deleted, I have to make the sequence: copy message delete message The NFS works the same as MDaemon's filtering system. The actions are carried out as they're described in the filter rule. The rule itself, makes it seem to the user that the actions will be carried out in the sequence described. Then the first sentence is wrong: NFS don't go in the sequence but random This *is* the buggy behaviour I'm referring to. Or I should really be saying that IMO, this is buggy. Actions should be carried out in the sequence described. This is the only way one can accurately predict what will happen when the filter is applied. I don't see how it can function as you describe where actions are applied randomly and yet carry out complex actions as this. flag message copy message to delete message The above filter should flag the message, then create a copy and place it in a specified folder and then delete the original. If that doesn't occur in sequence then unflagged messages may be copied to the specified folder or no message could be copied because the original is deleted before anything can be done with it. -- Allie Martin [List Moderator and fellow end-user] · My PGP-Keys: http://key.ac-martin.com · The Bat! v2.13 Lucky Beta/1 /·\ WinXP Pro (Service Pack 2) . A pessimist is never disappointed. pgpyFx43G5sUO.pgp Description: PGP signature Current beta is 2.13 'Lucky' Beta/6 | '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/
Re[2]: Bug: Order of actions in NFS
Hello Allie, Wednesday, August 18, 2004, 2:39:43 PM, you wrote: AM interface is in a sentence type fashion. I've attached a capture of AM one of them. Question is when will we be able to see such a simple description, rather than the odd copy and paste version we have now. :) -- Stuartmailto:[EMAIL PROTECTED] Using The Bat! v2.13 Lucky Beta/6 on Windows 98 4.10 Build A Current beta is 2.13 'Lucky' Beta/6 | '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/
Re: Bug: Order of actions in NFS
Stuart Cuddy, [SC] wrote: AM interface is in a sentence type fashion. I've attached a capture of AM one of them. Question is when will we be able to see such a simple description, rather than the odd copy and paste version we have now. :) In the capture, what you're seeing is the front end view of the filter. When we copy the filter in TB!, we're copying the 'filter source'. The same filter copied from filter.dat in MDaemon would be ,- / \ | [Rule010] | RuleName=TBUDL | Enable=Yes | ThisRuleCondition=All | ProcessQueue=LOCAL | Condition01=REPLY-TO|contains|AND|tbudl@| | Action01=copy to dir|M:\MDaemon\Users\ac-martin.com\imap\TBUDL.IMAP\ | Action02=delete| | Action03=stop processing| `- Seems similar to TB! doesn't it? :) -- Allie Martin [List Moderator and fellow end-user] · My PGP-Keys: http://key.ac-martin.com · The Bat! v2.13 Lucky Beta/1 /·\ WinXP Pro (Service Pack 2) . Fact is solidified opinion pgpFNaCGPWO9M.pgp Description: PGP signature Current beta is 2.13 'Lucky' Beta/6 | '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/
