179637 - Provide undo for mark as Junk / non-Junk

Status: RESOLVED INVALID

(MailNews Core :: Filters, enhancement)

Description

[Quinn Yost (mythdraug)]

Earlier today I was teaching the filter by shoving months of old e'mail at it. 
I would enter a folder, select all messages, mark all messages as Junk or Not
Junk (depending on the folder), then process all selected messages.

For one folder, I accidentally selected Junk when I intended Not Junk.  I
corrected my selection and processed all messages.  They all were determined to
be Junk.  I marked all as Not Junk, and reprocessed.  Again all were marked as Junk.

I have repeated this two or thee times (on the same folder) now with the same
result each time.

Comment 1

[Quinn Yost (mythdraug)]

Oops:  Using build 2002111104 Win32.   .sea.exe installer

Comment 2

[NorthMan]

Is there still the javascript issue with the .sea.exe installer?

Comment 3

[Zibi Braniecki [:zbraniecki][:gandalf]]

No.

Comment 4

[Ray Trent]

Attachment: The zombie spam from hell

Perhaps more importantly, accidental marking of an email as *non* junk can
really screw things up.

I'm not 100% sure that this is the cause, but I've been getting emails like the
attachment ~1/day over the last 2 weeks, and I've marked each one as junk. 

They keep getting misclassified, in spite of all having really obvious tag
words, such as "greatdeals", "greatoffrs", and even "MillionOrbLoad4".

The only explanation I can think of for why these keep getting through is that
I must have accidentally unmarked one of them in the past. 

Having the big "junk" button also act to *untrain* an email if it's already
marked as junk is a *terrible* user interface. I see no reason why this
functionality needs a giant toolbar button at all. 

But, if it has to stay there, then by definition this usage is rare (otherwise
the junk filter is crap), so a warning dialog seems very warranted.

As for accidental junking of "ham", that seems like a serious potential
dataloss to me... but I'm not sure what to do about it. If we implemented bug
181534, then using the 3 level ham/spam/uncertain mechanism to pop up the
warning might be a possible solution.

Comment 5

[:aceman]

This also happens to me. I accidentally marked a message from a mailinglist as
junk and now it happens that all messages from that list are marked as junk. I
deleted the training.dat file and retrained from scratch (as I kept all spam
messages till now).

Comment 6

[Ben Bucksch (:BenB)]

Attachment: Warn users about this bug

If this bug exists, it's pretty fatal IMHO. It's all too easy to hit the wrong
row in the thread pane or to hit the Junk button the wrong time, e.g. when a
message is already marked as Junk. We should warn users to be very careful when
marking junk mail. This patch adds such a warning to the junk mail info dialog
(displayed when junk mail functions are used the first time). (The patch also
removes branding and tells users to regularily check for messages wrongly
marked as spam.)

Comment 7

[Ben Bucksch (:BenB)]

-> major. potential for data loss or at least making the feature much less
useful. no known workaround.

Comment 8

[Vladislav Duma]

If this is really a bug, it is perhaps possible to work this around by providing
the user a possibility to "roll back" the current filter training session?

Or perhaps there's a possibility to warn user about possibly incorrect junk
setting (e. g. if the current changes make too many of previously non-junk mail
recognised as junk--and vice versa?)

Comment 9

[Vladislav Duma]

Just another idea: it's perhaps possible to apply changes to the filters only
AFTER the mail session (and perhaps provide the button "commit filter changes"
for immediate application)? Then users who _notice_ incorrect change need only
to restore the correct marking before exiting mail application.

Comment 10

[Scott MacGregor]

if you mark a message as junk and then mark it as NOT JUNK, the tokens from the
message are removed (or at least the occurrence count is removed) from the junk
training set and then added to the not junk training set. Effectively making
things a no-op.

Comment 11

[Ben Bucksch (:BenB)]

mscott, how then comes the effects the original report describes?

I think Undo should directly undo the effects, including junk tokens and msg
move. Currently, it doesn't. Maybe even be smart and make hitting Junk twice in
a row undo the first hit.

Comment 12

[Dan Mosedale (:dmosedale, :dmose)]

Note that the original bug was reported against the Bayesian algorithm. 
Thunderbird has already moved over to the Chi-separating algorithm, and Mozilla
will soon too.  So the original bug can probably be marked invalid.

Comment 13

[:aceman]

comment 10: but that just shifts the issue. What if I don't want the message to
be in the 'not junk' training set? I don't want it to be in any set. There
should be a clean undo as comment 11 said.

Comment 14

[[e-mail]]

Comment on attachment 126976 [details] [diff] [review]
Warn users about this bug

Assuming that it's still relevant, I don't like the wording, perhaps it should
be along the lines of "Initially &brandShortName; relies on your accurate
identification of junk mail. Accidental misidentification of mail will increase
the time it takes to train &brandShortName; to automatically identify junk
mail." ...assuming you can think of a good synonym for misidentification...
also note the example branding.

Comment 15

[Wayne Mery (:wsmwk)]

attachment 126976 [details] [diff] [review] is still unfinished

Comment 16

[Ben Bucksch (:BenB)]

Summary was changed from
Accidental marking as Junk may affect decisions about future messages
to
Provide undo for mark as Junk / non-Junk
(Just to make sure that the meaning is the same)

Comment 17

[Dan Mosedale (:dmosedale, :dmose)]

Assigning bugs that I'm not actively working on back to nobody; use
SearchForThis as a search term if you want to delete all related bugmail at
once.

Comment 18

[Ronald Killmer]

(In reply to comment #12)
> Note that the original bug was reported against the Bayesian algorithm. 
> Thunderbird has already moved over to the Chi-separating algorithm, and Mozilla
> will soon too.  So the original bug can probably be marked invalid.

Based on this comment this bug should be closed as now being Invalid since the filter code in core has migrated for both Tb and Sm.

Comment 19

[Ronald Killmer]

This bug has not drawn any comments in reply to Comment #18 in the past 3 months.

I am closing the Bug as invalid due to the code migration mitigating the original issue.