After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 260902 - Threads w/ date sorting should be by newest article, not oldest
Threads w/ date sorting should be by newest article, not oldest
Status: RESOLVED DUPLICATE of bug 203206
Product: evolution
Classification: Applications
Component: Mailer
pre-1.5 (obsolete)
Other All
: Normal minor
: Future
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2004-06-29 19:46 UTC by Lars Clausen
Modified: 2005-02-10 12:54 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Lars Clausen 2004-06-29 19:46:11 UTC
Please fill in this template when reporting a bug, unless you know what you
are doing.
Description of Problem:

When viewing mails in Threaded mode sorted by date, Evolution sorts the
threads by date of the first mail in the thread.  That means that
long-running threads or threads that are resurrected after a long time are
hard to find -- I often find myself scrolling through my entire mailbox to
find that one unread mail that just came in.  If they were sorted by
'thread with newest mail in it first' order, you'd be able to see all
activity up in the top.

In particular this is a problem because there's no way to sort by
read/unread, AFAICS.

Steps to reproduce the problem:
1. Get a lot of mail in long-time threads.
2. Click on 'Date' to get the list sorted by date.
3. 

Actual Results:
Threads are sorted by first date, leaving new messages arbitrarily far down
the mailbox.

Expected Results:
The threads with new messages should be at the top, easy to find.

How often does this happen? 
Always.

Additional Information:
Gnus does its threading this way, and I really, really prefer that.
Comment 1 André Klapper 2005-02-10 12:54:41 UTC

*** This bug has been marked as a duplicate of 203206 ***