Closed Bug 193294 Opened 22 years ago Closed 15 years ago

Change function of Junk button (automatically move mails while marking)

Categories

(SeaMonkey :: MailNews: Message Display, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: jon.roland, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030210
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030210

Present function of the Junk button is redundant, as messages can be set as junk
in the Junk column. But what is needed is a single button that will move
messages set as junk from the Inbox folder to the Junk folder, and messages
unset as junk from the Junk folder to the Inbox. In other words, the user would
check the messages set as junk in the Inbox, set or unset them as he wishes,
then check the Junk folder, unsetting any messages mistakenly moved there, and
then hit the Junk button to move the set messages to the Junk folder and the
unset messages to the Inbox folder in a single operation.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Replying to messages is also possible via the context menu, but some people
still prefer the "Reply" button, so I think the Junk button has a right to exist
(you can make it disappear in the preferences).

But I could imagine that a modifier key ("Ctrl" or similar) being pressed while
klicking the Junk button could trigger the action requested in this RFE: moving
the mail to trash/Junk folder when marking as Junk and moving to Inbox (with
applying of the sorting rules??) when un-marking.

Actually, I like the idea.
-> NEW 
so others can decide if this gets implemented.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 98 → All
Hardware: PC → All
Summary: Change function of Junk button → Change function of Junk button (automatically move mails while marking)
I totally agree that we do need this funcionality! Currently its a real hassle
moving junk & non-junk mail back and forth from/to the inbox / junk folder. My
suggestion is to change the behaviour:

- when mail is unchecked as junk (in the junk folder) move it automatically back
to the inbox.
1) when mail is checked as junk automatically move it into the junk folder.
2) Note that for multi-homed (same imap account used on different computers)
mail accounts that the junk algoritm should also "learn" from the contents of
the junk folder.
3) Optionally we could choose to either do the auto-move of junk / non-junk when
closing the mail client or when "compacting" folders (anybody else any
suggestions for this).
4) Another suggestion is that junk identified mail maybe shouldn't be moved
immidiately to the junk-folder but maybe it should first be marked as junk in
the inbox and moved into the junk folder when step 3) is performed.


I do think this has priority as I heard a lot of people (non computer-experts)
complain that the current junk filter implementation is simply too much of a
hassle and people simply don't understand how it works. I suggest implemantation
for 1.4alpha.
Flags: blocking1.4a+
arnova, as long as you are not a member of drivers@mozilla.org, you are not
allowed to set blocking1.4a+ !
You may request it by setting blocking1.4a? if you want drivers to consider this
bug. But I'm not sure you know what this "blocking" field means: it is for
really nasty things drivers would delay a release for. And I don't think drivers
would delay 1.4a for an enhancement...
-> Clearing that field for now. You may still set it to "?".
Flags: blocking1.4a+
Currently the only big missing left is the feature that automatically moves mail
unmarked as junk back into the inbox.
Flags: blocking1.4?
Why fiddle with the junk functionality separately?

Junk classification should be fully integrated into the Filter mechanism. I'd
like to have a rule in the Filters, that says if "Junk", then do ...

I'd then like to see the Junk button classify the mail and run a list of filter
rules that include a reference to Junk. The same for unclassifying from Junk.

The benefits are twofold:
First I can have certain filters have apply before or after the junk filter in
incoming mail
Second I can have a fully configurable set of options for junk filtering

The very best would be some framework, that allows to have multiple different
Junk/Spam classifiers to be included in the filter work. Also allow actions that
include typical functions such as reporting to an spam authority (such as
Vipul's razor and others) - "spam" and "no spam".
mozilla1.4 shipped. unsetting blocking1.4 request.
Flags: blocking1.4?
Now that we have in 1.4 the option in the Junk Mail Controls window, "When I
manually mark messages as junk:", we could use an option "When I manually unmark
messages as junk: Move to Inbox & apply Inbox filters".

However, I still prefer my original idea of modifying the function of the
button, because immediately moving messages as they are marked can be done in
error, especially with the Junk mark field following the Subject field as it
does now. I would prefer to do all the marking and unmarking, leaving the
messages in place until I have a chance to look them over, then moving all of
them, both ways, with a single manual action.

While we are on the subject, we might consider how we might interface Mozilla to
virus checkers so that incoming messages containing viruses could be diverted
either to the Junk folder or to a special Virus folder. I am using the junk
filter now to divert many virus-containing messages, based on what it can do,
but scanning for viruses would be a useful enhancement, using third party products.
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Assignee: mail → nobody
QA Contact: esther → message-display
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
WORKSFORME
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.