Open Bug 191283 Opened 22 years ago Updated 9 years ago

Implement command to ignore remaining unread threads

Categories

(SeaMonkey :: MailNews: Message Display, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: smjg, Unassigned)

References

(Blocks 1 open bug)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2) Gecko/20021126
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2) Gecko/20021126

After I have caught up on the watched threads in a newsgroup and then picked
some threads to read, I like to ignore the threads that are left, so that the
list isn't cluttered with all the old threads that I wasn't incited to read.

At the moment I tend to go through after reading and hold K down until it's
finished.  However, fixing bug 112833 would make it easier to do this, and even
easier would it be if an "Ignore Remaining Threads" command were implemented
(see below for details).

Reproducible: Always

Steps to Reproduce:



Expected Results:  
The way I would design the Ignore Remaining Threads command is to ignore threads
in the current newsgroup matching _all_ of these criteria:
- whose headers have actually been downloaded (so that one doesn't miss new
threads that were started while looking through currently downloaded headers)
- aren't watched
- aren't flagged or downloaded for offline reading
- have unread messages in them
Summary: command to ignore remaining unread threads → Implement command to ignore remaining unread threads
OS: MacOS X → All
Hardware: Macintosh → All
Blocks: 236849
Product: Browser → Seamonkey
Assignee: sspitzer → mail
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
Still no obvious sign of such a feature, but at least now bug 112833 has been
dealt with life is a little easier.
any news reader that does something like this that can be looked at as model?
What about "Mark Newsgroup Read" in the right-click menu for the newsgroup (in the left pane of the 3-pane window)?
You tell me: What has "Mark Newsgroup Read" to do with this RFE?
(In reply to comment #5)
> You tell me: What has "Mark Newsgroup Read" to do with this RFE?
> 

Easy: if you do, then after new unread messages arrive afterwards, "Next unread" will find only them, and not whatever was unread before; similarly for the "Unread Messages" view of the messages list.
That has nothing whatsoever to do with ignoring threads.  Ignoring is a feature whereby you tell the newsreader not to show you any more messages from the thread, either new or old.  Marking a newsgroup read merely marks the already-downloaded message headers as read; it does nothing to remove the clutter of new messages being posted on the same old threads.
Resetting A+QA to defaults: takers welcome!
QA Contact: laurel
QA Contact: search
Assignee: mail → nobody
QA Contact: search → message-display
this looks like a case for an extension to me, not for a core feature.
(In reply to Jan from comment #9)
+ 1
You need to log in before you can comment on or make changes to this bug.