Last Comment Bug 323159 - 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)
: Make obvious that "Junk mail log" is only for the "adaptive junk mail control...
Status: VERIFIED FIXED
: polish, uiwanted, ux-discovery
Product: Thunderbird
Classification: Client Software
Component: Account Manager (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: Thunderbird 14.0
Assigned To: :aceman
:
Mentors:
Depends on:
Blocks: junktracker
  Show dependency treegraph
 
Reported: 2006-01-12 07:21 PST by Worcester12345
Modified: 2012-08-13 11:48 PDT (History)
9 users (show)
standard8: blocking‑thunderbird3-
ryanvm: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
patch, fix wording (7.02 KB, patch)
2012-04-03 13:48 PDT, :aceman
mconley: review+
bwinton: ui‑review+
Details | Diff | Review

Description Worcester12345 2006-01-12 07:21:32 PST
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.
Comment 1 David :Bienvenu 2006-01-12 14:25:08 PST
these are implemented by message filters, which know nothing about the junk mail log, so this is not easily fixable - I'd recomment wontfix.
Comment 2 Worcester12345 2006-01-12 15:34:10 PST
(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. 
Comment 3 Worcester12345 2006-03-08 08:42:52 PST
(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 David :Bienvenu 2006-03-08 08:47:23 PST
again, the filters interface knows nothing about the junk mail interfaces or code. You can't simply "move" anything to change it.
Comment 5 Worcester12345 2006-03-08 10:27:23 PST
(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 David :Bienvenu 2006-03-08 10:50:48 PST
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.
Comment 7 Worcester12345 2006-03-09 13:45:31 PST
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.
Comment 8 Worcester12345 2006-03-15 08:32:17 PST
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.
Comment 9 Worcester12345 2006-05-22 14:36:34 PDT
(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.
Comment 10 Worcester12345 2006-10-04 11:55:18 PDT
(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 David :Bienvenu 2006-10-04 12:02:25 PDT
the junk mail code knows how to create mail filters. The mail filters know nothing about the junk mail code.
Comment 12 Worcester12345 2006-10-04 12:16:18 PDT
(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.
Comment 13 Wayne Mery (:wsmwk, use Needinfo for questions) 2007-09-22 14:08:53 PDT
not dependent on bug 257990
Comment 14 Wayne Mery (:wsmwk, use Needinfo for questions) 2008-02-01 04:49:54 PST
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.
Comment 15 Magnus Melin 2008-02-01 10:09:55 PST
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."
Comment 16 Wayne Mery (:wsmwk, use Needinfo for questions) 2008-02-01 11:46:37 PST
(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.
Comment 17 Worcester12345 2008-02-01 12:36:36 PST
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.
Comment 18 Magnus Melin 2008-08-20 14:17:11 PDT
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.
Comment 19 John L. Galt 2009-10-26 19:55:33 PDT
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?
Comment 20 Worcester12345 2009-11-09 07:14:17 PST
(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.
Comment 21 Worcester12345 2011-05-11 08:55:07 PDT
(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.
Comment 22 :aceman 2012-04-03 13:48:25 PDT
Created attachment 611965 [details] [diff] [review]
patch, fix wording
Comment 23 :aceman 2012-04-03 13:50:38 PDT
The wording can surely be fixed easily. Patch attached.
Comment 24 Blake Winton (:bwinton) (:☕️) 2012-04-17 11:14:01 PDT
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.
Comment 25 Mike Conley (:mconley) - (needinfo me!) 2012-04-18 12:02:56 PDT
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
Comment 26 Ryan VanderMeulen [:RyanVM] 2012-04-18 16:02:17 PDT
http://hg.mozilla.org/comm-central/rev/1a3c7ece1ff5
Comment 27 Worcester12345 2012-08-08 09:11:22 PDT
Thank you.
Comment 28 :aceman 2012-08-13 11:48:17 PDT
Thanks, I take that as verification the problem is fixed in TB14 that was already released.

Note You need to log in before you can comment on or make changes to this bug.