RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1025807 - Improve auto-selection of messages grouped by threads
Summary: Improve auto-selection of messages grouped by threads
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: evolution
Version: 6.5
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: beta
: 6.4
Assignee: Matthew Barnes
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On: 809542 883010
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-01 16:02 UTC by Jiri Koten
Modified: 2017-12-05 13:05 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 809542
Environment:
Last Closed: 2017-12-05 13:05:02 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 621839 0 None None None Never

Description Jiri Koten 2013-11-01 16:02:33 UTC 
+++ This bug was initially created as a clone of Bug #809542 +++

Description of problem:
When auto-moving within message list, move to "most preferred" or "least preferred unread". Auto moving within messages happens pretty often when e.g. user switches to the folder from another folder or when she clears search filter.

Version-Release number of selected component (if applicable):
evolution-2.28.3-24.el6.x86_64

How reproducible:
often

Steps to Reproduce:
1. move to the folder from another folder OR apply a search filter and clear it again
2.
3.
  
Actual results:
evolution moves in folders lists to one of following:
  * the top of message list (in my case, to the oldest - least 
    interesting - actually)
  * somewhere randomly among unread messages

Expected results:
evolution moves in message list so that "least preferred" unread message is visible - in my case of sorting by date, it's the oldest unread message

if the above is not possible, then it should move to "most preferred" message - in my case, the newest one aka the bottom of the list.

Additional info:

--- Additional comment from Milan Crha on 2012-04-04 07:32:25 EDT ---

I looked briefly in the code and the rule for selecting a message when moving to a folder looks close to this:
a) if previously selected message exists, select it
b) if it doesn't exist or is not saved (like when multiple messages were
   selected when leaving the folder), then pick message with the same uid from
   the previous folder (usually doesn't apply)
c) then pick first message in the list

That's only a rough view from the code, though.

Current evolution, the 3.4.0, uses different approach, it picks unread message, if it cannot restore previously selected message. It's part of 2.30 too, according to:
https://bugzilla.gnome.org/show_bug.cgi?id=621839

Thus patches available.

--- Additional comment from Milan Crha on 2013-05-09 14:37:12 EDT ---

Upstream patch part of 2.32.3, thus depend on the rebase bug.

--- Additional comment from errata-xmlrpc on 2013-10-31 09:27:12 EDT ---

Bug report changed from ON_QA to VERIFIED status by the Errata System: 
Advisory RHSA-2013:15040-05: 
Changed by: Jiri Koten (jkoten)
http://errata.devel.redhat.com/advisory/15040

When switching folders, evolution shows the last selected message if it still exists else shows the oldest unread message in the folder or else the newest read message.
Comment 1 Jiri Koten 2013-11-01 16:18:17 UTC 
(In reply to Jiri Koten from comment #0)
> When switching folders, evolution shows the last selected message if it
> still exists else shows the oldest unread message in the folder or else the
> newest read message.

Unfortunately this is not true if the messages are grouped by threads. In that case the msg list just jumps to the begging of the list. The oldest unread msg shows in the msg preview, but is not visible in the msg list.

I'm using Sort by Date (Ascending) and group by threads in my Inbox.

Reproducer:

1) Unselect a msg in the msg list, hold Ctrl and Click the msg.
2) Switch to different folder.
3) Go back to your previous folder.

evolution-2.32.3-30.el6
Comment 2 Jiri Koten 2013-11-13 16:21:22 UTC 
Same thing happens when I Collapse All Threads and the selected msg is not the first in the thread, then the msg list jumps to the top. I would expect that the first msg (the one at the top) in the thread is selected.

Reproducer:

1) View > Expand All Threads
2) Select a msg inside a thread, e.g. at the bottom of the thread
3) View > Collapse All Threads
Comment 4 Red Hat Bugzilla Rules Engine 2017-12-05 13:05:02 UTC 
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
Note You need to log in before you can comment on or make changes to this bug.