Eheka Pytyvõha

Emboyke pytyvõha apovai. Ndorojeruremo’ãi ehenói térã eñe’ẽmondóvo pumbyrýpe ha emoherakuãvo marandu nemba’etéva. Emombe’u tembiapo imarãkuaáva ko “Marandu iñañáva” rupive.

Kuaave

Behavior of "Stop Filter Execution" filter action

  • 1 Mbohovái
  • 3 oguereko ko apañuãi
  • 22 Hecha
  • Mbohovái ipaháva crpack

more options

What is the intended behavior of the "Stop Filter Execution" filter action? I cannot find any recent documentation on that issue. When part of manually run filters, is "Stop Filter Execution" designed to stop all remaining filters for all messages if the filter that contains it matches once? That appears to be the behavior for me. When included in the first filter of several filters, only the first filter matches and the log only indicates instances of matching of the first filter, although several other subsequent filters should match for several messages that do not match the first filter.

I appreciate the functionality of Thunderbird's filters, but am trying to find a solution for implementing more complex boolean logic for moving messages from my Inbox using manually run filters. I have several filters set up for categorizing messages, but I would like to implement the filters such that they are not applied to starred messages. Currently, I have logic in most of the filters to not match a starred message by using the "Match all of the following" option, however this prevents use of OR logic in the filter and leads to an increased number of filters. I would like to set up the filters such that a first filter matches starred messages and prevents the remaining filters from being run only for those messages which match the first filter.

It may be that the behavior that I am seeing is a bug specific to my installation, but I'd like to get confirmation on the expected behavior and see if others have encountered this issue. I am working under the assumption that the behavior of "Stop Filter Execution" should stop subsequent filter processing only for messages on which a containing filter matches as indicated in the old post at https://groups.google.com/forum/#!topic/mozilla.feedback.thunderbird.prerelease/rUXaQ0NdZvM, but that assumption may be wrong.

Any help or suggestions are appreciated.

What is the intended behavior of the "Stop Filter Execution" filter action? I cannot find any recent documentation on that issue. When part of manually run filters, is "Stop Filter Execution" designed to stop all remaining filters for all messages if the filter that contains it matches once? That appears to be the behavior for me. When included in the first filter of several filters, only the first filter matches and the log only indicates instances of matching of the first filter, although several other subsequent filters should match for several messages that do not match the first filter. I appreciate the functionality of Thunderbird's filters, but am trying to find a solution for implementing more complex boolean logic for moving messages from my Inbox using manually run filters. I have several filters set up for categorizing messages, but I would like to implement the filters such that they are not applied to starred messages. Currently, I have logic in most of the filters to not match a starred message by using the "Match all of the following" option, however this prevents use of OR logic in the filter and leads to an increased number of filters. I would like to set up the filters such that a first filter matches starred messages and prevents the remaining filters from being run only for those messages which match the first filter. It may be that the behavior that I am seeing is a bug specific to my installation, but I'd like to get confirmation on the expected behavior and see if others have encountered this issue. I am working under the assumption that the behavior of "Stop Filter Execution" should stop subsequent filter processing only for messages on which a containing filter matches as indicated in the old post at https://groups.google.com/forum/#!topic/mozilla.feedback.thunderbird.prerelease/rUXaQ0NdZvM, but that assumption may be wrong. Any help or suggestions are appreciated.

Ñemoĩporã poravopyre

Ok, it looks like this is a documented bug, for example at https://bugzilla.mozilla.org/show_bug.cgi?id=552936. I should have searched bug reports before posting here. I'll track things with the bug reports. Thanks.

Emoñe’ẽ ko mbohavái ejeregua reheve 👍 0

Opaite Mbohovái (1)

more options

Ñemoĩporã poravopyre

Ok, it looks like this is a documented bug, for example at https://bugzilla.mozilla.org/show_bug.cgi?id=552936. I should have searched bug reports before posting here. I'll track things with the bug reports. Thanks.