GNOME Bugzilla – Bug 323940
Eliminate the option to not filter new messages in INBOX, or improve the UI
Last modified: 2021-05-19 12:28:03 UTC
Description of the bug: You have to manually enable filtering for an email account for filters. There's a per-account toggle in the Receiving Options tab of the Account Editor, labelled "Apply filters to new messages in INBOX on this server" I believe: (i) that Evolution has historically done for performance reasons (to avoid having to fetch the messages themselves, for filters requiring this), and that this is unlikely to change. (ii) that many users of filters get bitten by this; filtering appears not to work, and someone has to direct them to this toggle, which they interpret as a "Make Evolution actually work please" button, rather than a useful feature. Proposed fix (a): the "make filters just work" approach Eliminate this option; make it always do the necessary work if filters exists that require it, and not do the necessary work if filters do not require it. Proposed fix (b): the "workaround dialog" approach: Assuming we can't simply remove this option, or make it on by default, when creating a new filter that acts on an account for which the toggle is not enabled, show a dialog like this: +-----------------------------------------------------+ | You need to enable filtering on the "$ACCOUNT_NAME" | | account for this filter to take effect. | | | | [ ] Don't show this warning in future | | [Close] [Enable Filtering] | +-----------------------------------------------------+ that would avoid the user having to locate the magic "make it work please" toggle and make it clear that they are potentially increasing Evolution's network traffic via their selections.
Text in proposed fix (a) above should read "not do the _unnecessary_ work". I have a preference for approach (a). Is there any reason not to always apply the filters? (changing bug title accordingly)
Hey Dave, Theres a problem with the approach (suggested fix a) - what if the user has multiple accounts, and all enabled, while configuring filters. It is quite cumbersome to determine which account should actually have its filtering enabled. So do we just enabled filtering for both the accounts(basically, all enabled accounts)??
proposed fix a: what do you propose being done here? the filtering code already tries to only fetch the bare minimum amount of info they need in order to filter the message, but this isn't enough - it can still a huge impact on performance. proposed fix b: cannot necessarily be done, most users are going to create "generic filters" and not use the "source account" filter criteria, and so how could we possibly know which account the rule is meant to apply to? can't.
Would it be a reasonable compromise to enable the option by default for the _first_ account created (to cover the main use case that I think this bug is trying to address), and disable it by default for additional accounts?
Bumping version to a stable release.
Dave: Could you comment on comment 4?
(In reply to comment #4) > Would it be a reasonable compromise to enable the option by default for the > _first_ account created (to cover the main use case that I think this bug is > trying to address), and disable it by default for additional accounts? FWIW I use server-side filtering now. How about showing all accounts in a list view, with a toggle per-account? +-----------------------------------------------------+ | You need to enable filtering on an account | | for filtering to take effect. | | | | Account Enable Filtering | | jdoe@example.com [X] | | jdoe@gmail.com [X] | | tiresomehipster24@foo.com [ ] | | | | [Close] | +-----------------------------------------------------+
I have actually been bitten by having the filters apply to IMAP accounts, when I subscribed with a read-only use case. The UI proposed in comment 7 looks good to me, although I would still mention somewhere that it is applying to INBOX, to clarify the behavior when people have server-side filters that make them appear on other folders.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new bug report ticket at https://gitlab.gnome.org/GNOME/evolution/-/issues/ Thank you for your understanding and your help.