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.