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 223897 - Deleting email in threaded reorders emails
Deleting email in threaded reorders emails
Status: RESOLVED DUPLICATE of bug 203737
Product: GAL
Classification: Deprecated
Component: ETable
evolution-1-0-branch
Other other
: Normal normal
: ---
Assigned To: Chris Lahey
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2002-04-26 02:43 UTC by foskey
Modified: 2002-04-26 16:26 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description foskey 2002-04-26 02:43:46 UTC
Description of Problem:

When you delete a message in the middle of a thread it causes the thread to
be resequenced. The email will jump into logical date order and put unread
emails above where you are now in the thread..  This means that the 'n'
next command will not follow the thread and you will jump back to it later.
 This leaves the reader confused.

Deleting a thread is worse.  Delete a large thread over a number of days. 
You will suddenly get resorted into the middle of the list and the
deletions start acting on things you did not expect due to the changed
position in the mailing area.

Steps to reproduce the problem:
1. Grab a large unread thread, with multiple paths.  Read the first few
records.
2. Read the delete an email on the tree.  you advance to the next email,
this email will reorder to the 'correct' slot according to sort order.
3. Emails that were now after this email and now moved above.

Actual Results:

Unread email above where the user is, when reading from the top of the list.

Expected Results:

Unread emails stay below the current email.

How often does this happen? 

Always.

Additional Information:

If I delete the head of a threaded list a similar thing happens.

I suggest ordering the email when selecting it or refreshing it explicitly
but not when you are moving through it and deleting messages.

This makes things hard to find on big lists (5000 + messages) because
things jump all over the place leaving me confused.
Comment 1 Jeffrey Stedfast 2002-04-26 02:47:44 UTC
yea, this is a problem that has plagued us for a while. I think it
depends on ETable being "fixed" to not re-sort when things change.

Comment 2 Gerardo Marin 2002-04-26 16:26:07 UTC

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