GNOME Bugzilla – Bug 794121
Ability to customize Junk/Not-Junk button handling
Last modified: 2021-05-19 11:44:59 UTC
As discussed in the last few comments of #793296 it would be good to make the actions behind the Junk/Not-Junk buttons customizable by the user. The actions behind the customization option could be [a subset of] the actions already available to incoming and outgoing message filtering (i.e. CTRL-Y). That would allow various forms of action to happen on the marking of a Junk message (i.e. pressing the Junk button) such as moving/copying to a folder , forwarding to somewhere else, setting a status, score or label, or piping to an external program, etc. Currently there are 2 sets of filters defined for Incoming and Outgoing messages. I would propose that two more categories be added, Junk, Not-Junk which are run on messages where the Junk and Non-Junk buttons are pressed. So probably in Edit->Preferences->Mail Preferences->Junk tab there could be a list of checkboxes for supported junk handling methods: Bogofilter, Spamassassin, custom. The first two are only active and selectable (i.e. not greyed out) if their respective plugin is installed. Custom is always selectable (i.e. not greyed out). When selecting Custom there would be two buttons available called "Junk Actions" and "Not-Junk Actions". When each of these are pressed a dialog similar to the incoming/outgoing filtering appears which allows one to create a list of actions similar to the Add Rule dialog for incoming/outgoing filters. The dialog would differ in that there would be no matching criteria, just the action specification (i.e. what's below the "Then" in the current filtering Add Rule dialog). When more than one spam handling option is selected all options are processed. That is if one selected all of Bogofilter, Spamassassin and Custom, a message on which the Junk button is pressed would be given to bogofilter, then spamassassin and then processed through the actions defined for the Custom Junk Actions. Similar of course for the Not Junk button. Final disposition of the message is as it is currently -- put into the Junk vFolder. A possible additional enhancement would be a filter action to suppress Junk vFolder filing for people who don't like that vFolder but frankly that is pretty low on my importance list.
(Let's make it clickable: bug #793296.) Thanks for a bug report. I'd not make it possible to choose more than one junk filtering option enabled, that would add unnecessary complexity to the equation. At least from my point of view. What we are looking for here is really an additional processing of Junk/Not-Junk buttons, when user presses them from the GUI, not when the regular spam detection software classifies certain message as Junk or Not-Junk. It makes things simpler and can mean that functionality itself will be for the evolution only, not for Camel/evolution-data-server. I'd go with the simplified filter dialog, as you suggested (only the Then part), and this "filter" will be executed after the Junk/Not-Junk current processing is done. It can have some consequences with certain providers, like when real Junk folder is set, then marking Junk in Inbox will move the message to the Junk folder and similarly marking Not-Junk in the Junk folder can move the message (back) to the Inbox. Thus it can be tricky in certain situations/with certain settings, but I think it's still doable. The settings for the "filters" should go where you said, in Edit->Preferences->Mail Preferences->Junk tab. Maybe something like: [x] Execute [these actions] when selected messages are marked as Junk [x] Execute [these actions] when selected messages are marked as Not Junk where that "[these actions]" will be buttons, which will open the dialog to edit the respective filter.
(In reply to Milan Crha from comment #1) > (Let's make it clickable: bug #793296.) Yeah. I forgot bugzilla needs the "bug" keyword, and no editing. :-( > Thanks for a bug report. I'd not make it possible to choose more than one > junk filtering option enabled, that would add unnecessary complexity to the > equation. At least from my point of view. Fair enough. > What we are looking for here is really an additional processing of > Junk/Not-Junk buttons, when user presses them from the GUI, not when the > regular spam detection software classifies certain message as Junk or > Not-Junk. Agreed. > I'd go with the simplified filter dialog, as you suggested (only the Then > part), and this "filter" will be executed after the Junk/Not-Junk current > processing is done. It can have some consequences with certain providers, > like when real Junk folder is set, then marking Junk in Inbox will move the > message to the Junk folder and similarly marking Not-Junk in the Junk folder > can move the message (back) to the Inbox. I think that's fine since the Junk vFolder is only virtual and the Junk button can still move a message to a different real folder. In the case of moving to a folder for server processing, the message will likely only live there until the next poll of those folders by the server, upon which it processes the messages and then removes them (in my implementation at least). > The settings for the "filters" should go where you said, in > Edit->Preferences->Mail Preferences->Junk tab. Maybe something like: > > [x] Execute [these actions] when selected messages are marked as Junk > [x] Execute [these actions] when selected messages are marked as Not Junk Seems reasonable. > where that "[these actions]" will be buttons, which will open the dialog to > edit the respective filter. Cool. I like it. :-)
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 enhancement request ticket at https://gitlab.gnome.org/GNOME/evolution/-/issues/ Thank you for your understanding and your help.