[Spambayes] [ spambayes-Feature Requests-680629 ] Outlook plugin: Delete as spam marks as read

[SourceForge.net]

Feature Requests item #680629, was opened at 2003-02-04 20:30
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=498106&aid=680629&group_id=61702

Category: Outlook
Group: None
Status: Open
Priority: 1
Submitted By: Tony Meyer (anadelonbrin)
Assigned to: Mark Hammond (mhammond)
Summary: Outlook plugin: Delete as spam marks as read

Initial Comment:
Personally I think it would be nice if the "delete as 
spam" button marked the mail item as read.  Note that 
I'm not saying that mail that is filtered as spam should 
be marked as read - it shouldn't (by default).

If others agree, this would be a nice addition.  Perhaps 
as an option in the prefs.

----------------------------------------------------------------------

>Comment By: Tim Stone (timstone4)
Date: 2003-02-26 09:45

Message:
Logged In: YES 
user_id=645698

This is an interesting thread.  I think it should move to the main list.  
Pop3proxy has a very similar configuration function, which manages 
options into bayescustomize.ini (by default).  This is another area that 
we should solve the problem once...

----------------------------------------------------------------------

Comment By: Piers Haken (piersh)
Date: 2003-02-07 05:38

Message:
Logged In: YES 
user_id=10551

i don't care if you do this or not (since spambayes catches all 
my spam ;-) ), but please don't mark any automatically-
filtered spam as 'read' - it would be a pain to check for FPs if 
you did. thx.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2003-02-07 05:05

Message:
Logged In: YES 
user_id=14198

Fair enough :)

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2003-02-07 03:09

Message:
Logged In: YES 
user_id=113328

I'd like the "Mark as read" option. Most unsures and false 
negatives which are spam, I can identify by subject, and 
hence I don't open (and I don't use the preview pane).

But it's not crucial - Ctrl-Q does a very quick "Mark as read" 
anyway...

----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2003-02-04 21:17

Message:
Logged In: YES 
user_id=552329

Agreed that it is not necessary.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2003-02-04 21:11

Message:
Logged In: YES 
user_id=14198

Yep, I see that makring as read could be useful in that they
have been reviewed, but then I would expect Outlook's normal
mechanism to still work and mark it read.  I have my preview
pane mark as read after 2 seconds :)

Re the INI file - my problem is that the GUI needs to modify
these options, and I don't see how it is trivial to keep the
fairly "free-form" INI file format supported by
configparser, while only writing out certain elements and
not others and also keeping comments etc intact.

I'll make a deal - help me with the options problem, and I
will give you 5 free option <wink>.  Let's take it to email...

----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2003-02-04 20:56

Message:
Logged In: YES 
user_id=552329

My reasoning was that if the user manually selects to delete 
it as spam, then it is as good as read.  Those that are moving 
via the filter have not been read.  Personally I still wade 
through the filtered spam to check it for false positives, and 
mark the messages as read as I go (so that the 'unread' 
display is the number of messages I haven't checked).  If I 
choose delete as spam, I then have to go to the spam folder 
and mark it as read.

In any case, no big deal if you disagree, it was just a 
thought :)

Re: the ini file: looking at the ini, it doesn't seem to have 
anything that couldn't be in the GUI.  Most of it would 
probably fit in the "advanced" dialog.  It would probably be 
good if the ini was only for 'beta' options - anything that is for 
public use should be in the GUI.  And if a 'beta' option moves 
to 'public', then it doesn't matter (much) if it breaks, because 
those using beta options should be upgrading anyway.

Moving the existing settings (most of which should be 
exposed I think) would mean breaking existing code, but 
maybe just this once?  Maybe this discussion should move 
to the list?  (maybe I should have posted this there originally?)

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2003-02-04 20:41

Message:
Logged In: YES 
user_id=14198

I'm not too sure this should happen unless the filter also
marks the items as read - otherwise you still end up with
many spam in the spam folder unread, and only the ones you
move manually marked as read.

I'm also kinda stuck about what to do with "options". 
Currently, options managed by the GUI are in a pickle, while
other options are in the .ini file.  I don't object to
having new, outlook specific options in the INI file, but I
do object to all our existing code breaking should we decide
later to move this option into the GUI.

----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2003-02-04 20:31

Message:
Logged In: YES 
user_id=552329

And who else to decide on this, but Mark :)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=498106&aid=680629&group_id=61702