Open Bug 352428 Opened 18 years ago Updated 2 years ago

Junk Mail Controls clumsily split between Preferences and Account Settings

Categories

(Thunderbird :: Preferences, enhancement)

enhancement

Tracking

(Not tracked)

People

(Reporter: bugzilla, Unassigned)

References

(Blocks 3 open bugs)

Details

Thunderbird version 3 alpha 1 20060912; Mac OS X 10.3.9

 The junk mail controls which were formerly available in one place in 1.5.x ( Tools -> Junk Mail Controls) have been split in the version 3 alphas between Tools -> Account Settings -> Junk Settings (per-account) and Thunderbird -> Preferences -> Privacy -> Junk (global). I found the split very confusing when I first encountered it and find it clumsy to use the split Junk Mail Control UI.

 I suggest that if the global junk preference tab is seen as desirable it should be handled in the same way as global return receipt prefs, i.e. visible in the Account Settings (per-account) dialog and able to be set on a per-account basis.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
I agree that this split is confusing and have seen several bugs and ng questions related to this. (Lack of documentation on this is, of course, as always, adds another level of confusion..)

see bug 376885, and other I may add ..
Blocks: 376885
Blocks: 232486
Blocks: 401070
Depends on: 323159
(In reply to comment #0)
>  I suggest that if the global junk preference tab is seen as desirable it
> should be handled in the same way as global return receipt prefs, i.e. visible
> in the Account Settings (per-account) dialog and able to be set on a
> per-account basis.

This doesn't really apply.  Return Receipts sets up a global set of behaviors and allows overriding per-account.  The global junk settings aren't overridable; they define how the junk interface works, which presumably should be the same for all accounts.

Several of the per-account junk settings could be extended to being global and overridable: Do Not Junk Known Recipients, in particular seems more likely to be a global setting, to me; and the junk folder selection could be as well.
(I have a global junk folder shared by my POP accounts; but I don't want to store my IMAP junk there.)

However, Enable Junk Controls needs to be per-account only; Trust Junk Headers needs to be per-account only.

"Automatically delete junk older than _N_" is tricky because it's an attribute of the folder (at least, it appears to be).  What if two accounts share a Junk folder, but one has N set to 7 and the other has it set to 10, or one has it turned on and the other has it turned off?
OS: Mac OS X → All
Hardware: Macintosh → All
No longer depends on: 323159
The junk mail logging is also misplaced. See Bug 323159 – "Trust junk mail headers set by:" should be consistent in UI and log location/access, which was just unmarked from blocking on this one.
(In reply to comment #3)
> This doesn't really apply.  Return Receipts sets up a global set of behaviors
> and allows overriding per-account.  The global junk settings aren't
> overridable; they define how the junk interface works, which presumably should
> be the same for all accounts.

 It's the presumption that the three preferences

  [] When I mark messages as junk:
  [] Mark messages determined to be Junk as read
  [] Enable Junk filter logging

should be strictly global that I'm questioning.

 Previously all of the junk settings were per-account, and I think there is a good case for having the last two per-account settable (and, perhaps, the first one too).

 So, if it's seen to be beneficial to have global defaults for some junk prefs, like the three that have been separated into the Preferences in 3.0a1, then I think that they should /also/ appear in Account Settings as per-account over-rideable settings (just like return receipts).

 Of course, the simplest thing to do would be to go back to per-account settings for all junk prefs, settable in one place only (Account Settings).
Flags: blocking1.8.1.18?
Flags: blocking1.8.1.18?
Assignee: mscott → nobody
Component: Mail Window Front End → Preferences
QA Contact: front-end → preferences
I commented in bug 232486 comment #5 that the current setup of split junk controls is pretty useless because changing the perceived "global" junk settings (which are in fact only a "default settings" template for new accounts) will NOT change the per-account junk settings.

Clearly, there should be a per-account option to "use global settings" for junk, as we currently have for return receipts (as proposed in comment #5).

Of course, this would also require that /all/ junk settings are included in the global setup, and it's hard to understand why we currently can set "Do not mark junk if sender is in ... Adressbooks" only on a per-account basis, although the addressbook isn't per account and I imagine use cases for this as a per-account setting will be pretty rare.

In bug 232486 comment #5 I also explored some ways of overriding per-account settings from the global settings on request.
Blocks: junktracker
In my opinion, junk settings should be considerably simplify because I think most of the users simply don't use these options. Some examples:
- is it really needed to be able to specify one folder for the message mark as spam by the filter (in the account preferences) and eventually another for the spam marked manually (in the options panel)???
- Who cares about an option like "do you want to mark junk as read"?...
- Who receive spam from his contacts and would like to filter it???
- Who will only trust spamassassin for an account but not for another?

So I think that all the interesting options should be moved to the option panel, and the account parameters should just allow to enable/disable spam filter for the account and specify spam folder (for imap account).
In bug 551827 I'll mitigate this a bit by creating a link from the Account settings -> Junk settings to the global Junk preferences so that at least the global prefs are findable.
Depends on: 551827
In looking at history, Bug 257990 - Integrate Junk Mail settings into "Options" and "Account Settings" introduced at least of some these separations. You need to understand the issues reported there before moving forward this.

If indeed it should move forward. The bar needs to be pretty high before you undo a decision that was made earlier, like returning to per-account settings. Personally I would prefer per-account settings, but that does not mean I would support a change.

A few years back I introduced "inherited folder properties" (see http://mxr.mozilla.org/comm-central/source/mailnews/base/public/nsIMsgFolder.idl#794) that was supposed to provide backend support for properties that could be set either globally, per server (which is equivalent to per account) or per folder, inheriting from the parent. As a backend feature it works just fine, but everyone always hated any user interface suggestions on how to show that inheritance, so I don't think this was implemented anywhere other than what I did.

Junk was one place it was implemented though, so you can specify whether junk processing is done to folders either globally, per-server, or per folder using the the inherited string property "dobayes.mailnews@mozilla.org#junk".

Still, we can argue back and forth about whether a feature should be set globally or per server, but without a decent user interface that makes inheritance clear I'm afraid you are just churning the interface. If we had a good UI though for inherited features, it would me quite powerful

You can see the user interface that I proposed, along with some additional discussion, at http://mesquilla.com/2009/11/06/inherited-folder-properties-revisited/
(In reply to jwq from comment #0)

  I suggest that if the global junk preference tab is seen as desirable it
> should be handled in the same way as global return receipt prefs, i.e.
> visible in the Account Settings (per-account) dialog 

this is currently available

Is the rest rolled in bug 482617?
Blocks: 1144812
See Also: → 422728

Possible to have this on the radar for the next big release?

Flags: needinfo?(alessandro)

Sounds good, thanks for the ping.

Flags: needinfo?(alessandro)
See Also: → 505530
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.