Make obvious that "Junk mail log" is only for the "adaptive junk mail control" ("Trust junk mail headers set by:" should be consistent in UI and log location/access)

VERIFIED FIXED in Thunderbird 14.0

Status

Thunderbird
Account Manager
VERIFIED FIXED
12 years ago
5 years ago

People

(Reporter: Worcester12345, Assigned: aceman)

Tracking

(Blocks: 1 bug, {polish, uiwanted, ux-discovery})

Trunk
Thunderbird 14.0
polish, uiwanted, ux-discovery
Bug Flags:
blocking-thunderbird3 -
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060112 Firefox/1.5
Build Identifier: version 1.5 (20060111)

I have Spam Assassin running on the server. 

While the filter seems to work, though not completely; this bug is about where the logging of this activity goes. 

It is logged under "Tools: Message Filters: Filter Log", which is not where this function is set up and configured. 

Shouldn't it be logged with the junk mail log?



Reproducible: Always

Steps to Reproduce:
1. Receive mail with Spam Assassin headers.
2. Message gets filtered into "Junk" folder.
3. Log of moved message goes into message filter log, not junk mail log.

Actual Results:  
see steps to reproduce

Expected Results:  
Mail should get logged in junk mail log.

This should be a fairly easy fix and reduce confusion for users as the log of the function should go WITH the function. The code already exists, it just needs to point to a different log.
(Reporter)

Updated

12 years ago
Keywords: mail3, mail6
(Reporter)

Updated

12 years ago
Version: unspecified → 1.5

Comment 1

12 years ago
these are implemented by message filters, which know nothing about the junk mail log, so this is not easily fixable - I'd recomment wontfix.
(Reporter)

Comment 2

12 years ago
(In reply to comment #1)
> these are implemented by message filters, which know nothing about the junk
> mail log, so this is not easily fixable - I'd recomment wontfix.
> 

Then the interface to turn it on or off should also go under message filters. 
Summary: "Trust junk mail headers set by:" should be logged in Junk Mail Log, not message filter log → "Trust junk mail headers set by:" should be consistent in UI and log location/access
(Reporter)

Comment 3

11 years ago
(In reply to comment #2)
> (In reply to comment #1)
> > these are implemented by message filters, which know nothing about the junk
> > mail log, so this is not easily fixable - I'd recomment wontfix.
> > 
> 
> Then the interface to turn it on or off should also go under message filters. 
> 

Should I open a new bug to move this interface, or just leave this one open for now?

Comment 4

11 years ago
again, the filters interface knows nothing about the junk mail interfaces or code. You can't simply "move" anything to change it.
(Reporter)

Comment 5

11 years ago
(In reply to comment #4)
> again, the filters interface knows nothing about the junk mail interfaces or
> code. You can't simply "move" anything to change it.
> 

Then why is the activity getting logged in the message filters log? Can't these two overlapping functions be combined somehow so it is easier to find the logged information or why it is getting moved to junk folder? Sometimes it is the junk mail controls, sometimes the filter?

Comment 6

11 years ago
those trust headers are implemented by the junk mail controls creating filters using the public filters interface. That's why they show up in the filter log; they're real filters.
(Reporter)

Comment 7

11 years ago
Perhaps it would be easier to log both activities to the same log file, and have it set up in columns so it is easier to determine what actions were caused by what filter. The way it is now is not clear at all. Thanks for your time.
(Reporter)

Comment 8

11 years ago
When clearing my log files (which maybe should be one file), there are some inconsistencies. For message filters, I get into the log file, then "clear log", then "close", then hit the X. For junk mail, I "clear log", then "close", then "OK". 

These interfaces should really be made more similar, or even into one interface since both functions overlap so much.
(Reporter)

Updated

11 years ago
Depends on: 257990
(Reporter)

Comment 9

11 years ago
(In reply to comment #1)
> these are implemented by message filters, which know nothing about the junk
> mail log, so this is not easily fixable - I'd recomment wontfix.
> 

I am thinking that it would make more sense to have one junk mail log to describe what goes into the junk mail folder. Then, that log can have a line in it saying whether it came from the junk mail filters or the trust headers. It is very confusing having junk mail generated from two different means. Actually, the process itself is easy to understand, but not by looking at the logs.
(Reporter)

Comment 10

11 years ago
(In reply to comment #4)
> again, the filters interface knows nothing about the junk mail interfaces or
> code. You can't simply "move" anything to change it.
> 



(In reply to comment #6)
> those trust headers are implemented by the junk mail controls creating filters
> using the public filters interface. That's why they show up in the filter log;
> they're real filters.
> 

Then, apparently, they DO know about each other.


In 2.0 beta version, it now has the settings under account info, and the log under options. This really needs to get better organized with all the junk controls, settings, and log files accessible from one place.

Comment 11

11 years ago
the junk mail code knows how to create mail filters. The mail filters know nothing about the junk mail code.
(Reporter)

Comment 12

11 years ago
(In reply to comment #11)
> the junk mail code knows how to create mail filters. The mail filters know
> nothing about the junk mail code.
> 

In any event, this bug is still open and as much an inconvenience as ever. If fixing it so the filters know about the junk mail code, all the better.
QA Contact: front-end
(Reporter)

Updated

10 years ago
Flags: blocking-thunderbird3?
not dependent on bug 257990
Severity: normal → minor
No longer depends on: 257990
(Reporter)

Updated

10 years ago
Version: 1.5 → 2.0
(Reporter)

Updated

10 years ago
Version: 2.0 → Trunk
no way this should be a TB3 blocker.

additionally, per the architecture and david's comments, it seems to me this bug is invalid, at best sev=enh. perhaps someone else will have better insight than me.
Assignee: mscott → nobody
Severity: minor → enhancement
Component: Mail Window Front End → Account Manager
OS: Windows XP → All
QA Contact: front-end → account-manager
Hardware: PC → All
Version: Trunk → unspecified

Comment 15

9 years ago
Perhaps we should just modify the junk mail log dialog text a bit, to make it clear that it's only about the adaptive junk mail actions. 

Something like "Log of *adaptive* junk mail control activity."
(In reply to comment #15)
> Perhaps we should just modify the junk mail log dialog text a bit, to make it
> clear that it's only about the adaptive junk mail actions. 
> 
> Something like "Log of *adaptive* junk mail control activity."

That should eliminate some confusion. 

And the current wording of the checkbox is
  Enable junk filtering logging
which should be more like
  Enable adaptive junk logging

Personally, I think bug 397197 / the account+junk panel is far more to blame for misleading people about what "Trust" is about - it depicts no distinction between filtering+spamasassin, and junk processing.  IMO this panel has no organization.
(Reporter)

Comment 17

9 years ago
In any event, these controls are all similar and confusing and interchangeable to most people. The intent of this bug is to provide a clear interface to all of these controls in one place hopefully. Thanks for your time.
(Reporter)

Updated

9 years ago
Flags: wanted-thunderbird3?
(Reporter)

Updated

9 years ago
Blocks: 352428
(Reporter)

Updated

9 years ago
Blocks: 232486
Flags: blocking-thunderbird3? → blocking-thunderbird3-
(Reporter)

Updated

9 years ago
Blocks: 448716
Severity: enhancement → normal
Version: unspecified → Trunk

Comment 18

9 years ago
Please don't add unrelated bugs as blocking. What could be done here is improve the wording, the rest is wontfix per technical limitations as discussed above.
No longer blocks: 232486, 352428, 448716

Comment 19

8 years ago
Reporter - Are you still able to duplicate this behavior with current builds of the release (2.x) builds and / or the 3.x Beta / pre-release builds?
(Reporter)

Comment 20

8 years ago
(In reply to comment #19)
> Reporter - Are you still able to duplicate this behavior with current builds of
> the release (2.x) builds and / or the 3.x Beta / pre-release builds?

Yes.
Blocks: 531787
(Reporter)

Comment 21

6 years ago
(In reply to comment #1)
> these are implemented by message filters, which know nothing about the junk
> mail log, so this is not easily fixable - I'd recomment wontfix.

(In reply to comment #11)
> the junk mail code knows how to create mail filters. The mail filters know
> nothing about the junk mail code.

(In reply to comment #15)
> Perhaps we should just modify the junk mail log dialog text a bit, to make
> it clear that it's only about the adaptive junk mail actions. 
> 
> Something like "Log of *adaptive* junk mail control activity."


I think it is getting closer now. Thank you for the changes so far.
(Assignee)

Comment 22

5 years ago
Created attachment 611965 [details] [diff] [review]
patch, fix wording
Assignee: nobody → acelists
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #611965 - Flags: ui-review?(bwinton)
(Assignee)

Comment 23

5 years ago
The wording can surely be fixed easily. Patch attached.
Flags: wanted-thunderbird3?
Keywords: polish, uiwanted, ux-discovery
Summary: "Trust junk mail headers set by:" should be consistent in UI and log location/access → Make obvious that "Junk mail log" is only for the "adaptive junk mail control" ("Trust junk mail headers set by:" should be consistent in UI and log location/access)
Comment on attachment 611965 [details] [diff] [review]
patch, fix wording

Wording seems good as per bug comments.  ui-r=me.

(I am a little worried that the extra words will make it more confusing for normal users, but I think this feature is seldom-used enough for it to not be a huge problem.)

Later,
Blake.
Attachment #611965 - Flags: ui-review?(bwinton) → ui-review+
(Assignee)

Updated

5 years ago
Attachment #611965 - Flags: review?(mconley)
Comment on attachment 611965 [details] [diff] [review]
patch, fix wording

Review of attachment 611965 [details] [diff] [review]:
-----------------------------------------------------------------

Code looks good.  Another awesome aceman patch!

-Mike
Attachment #611965 - Flags: review?(mconley) → review+
(Assignee)

Updated

5 years ago
Keywords: checkin-needed
http://hg.mozilla.org/comm-central/rev/1a3c7ece1ff5
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Flags: in-testsuite-
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 14.0
(Reporter)

Comment 27

5 years ago
Thank you.
(Assignee)

Comment 28

5 years ago
Thanks, I take that as verification the problem is fixed in TB14 that was already released.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.